I've found that the guardrails of a strong, expressive type system are amazing for LLMs, especially if you don't use the top-of-the-line models but stick to the cheaper options. Agents need feedback to do their magic, and the type system is great for that.

But on the other hand, the compile time of Rust is really counterproductive. On large, established projects, most prompts I write now spend more time compiling on my machine than they spend outputting tokens. In a way this is great because the tokens are the expensive part, but it does mean that when faster LLMs will come, they will not meaningfully improve iteration speed for me.

I wonder how much of the compile time of Rust is inherent to the type system. There might be room for a language with slower runtime speed (GC?), but as good of a type system as Rust, so long as compile times are much faster. Switching languages has never been easier, anyone have any suggestions? IMO hard requirements are algebraic types and error handling based on them.

It's the Python guys whom I totally don't understand - it's all fun and dandy until you try to maintain and cleanup a legacy codebase of tens of millions lines of code in any dynamic language :)

With or without AI - doesn't matter. Only at that point you gain understanding of the limitations both of LLMs and of dynamic languages.

edit: Forgot about "Nightmare" difficulty - try enjoying dynamic languages and LLMs when your legacy codebase is earning tens of thousands $ per second.

I have prompted a LOT of Go in the past few months. While LLMs do indeed know Go very well, the amount of over-abstraction I'm seeing is awful. It's not at all indicative of code that I'd write myself. The whole point of Go is to have a language that is immediately approachable by juniors. And I've tried to keep my code in that lane. The reason I won't prompt Rust at all, is that I know it'll output working code... that I likely will not understand. (that's not the LLM's fault)

I don't write Rust & have no horse in this race but my intuition on this is you have 3 scenarios:

1. Humans writing code: here the usability, readability, accessibility of the language matters - strictness can be a hurdle depending on how a language is designed, so ultimately it's a trade-off.

2. Humans reviewing AI-authored code: here the requirements of (1) still apply to the code reviewer

3. Autonomous agents writing code: above requirements no longer apply so having a strictly-defined language with tight guardrails is the primary consideration.

I think most people are operating workflows in category (2), but it seems uncontroversial to say Rust is more suited to category (3) than python or golang. Typescript, Haskell, Elm, Ocaml could be considerations but you'll find Rust hard to beat here. Certainly neither python nor golang are in the running at all.

None of the other languages are as strict as rust is. With eager clippy and cargo lints and software design as close to the type system as possible, LLMs have tight guard rails to land on point.

There is some truth for all three.

1. Python has a lot of training data

2. Go runs with the philosophy of one same way to do stuff even further than Python. It’s also typed

3. Rust’s type system and strict compiler is what helps keep AI on guardrails

Well, Rust is great for Fearless AI-driven development.

Yeah, but only the Rust guys are right. ;-)

Exactly my point. Everyone says agents are “best” at their language. Which probably translates to agents generate equally well for all programming languages. So, why would you not pick the programming language that gets you the best (fastest, least memory) end product?

Never met a person who said python is the best except the python-cult. Legacy language that should be gone, it’s a scripting language that got known by data scientists as a replacement of R because they are not developers, they wanted something hacky and dirty to do things quickly, it was never meant for serious programming, something you can see in the dependency hell, indentation, syntax, performance, etc, and then you see people are trying to use it in UI or even robotics, what are you doing?! Maybe before llm it was an easy hacky way, now it should die for good.

Just needed a different name for it. What should it have been called? `#[component]` is not reachable from the client. We went with `#[shard]` to make it clear that it is different (callable from the client).

It’s not a rust thing. Custom markup is usually implemented in rust frameworks using macros. If mixing macros and logic becomes a problem, we can change how the macros are implemented.

Of course there is. I consider there to be very little overlap. Axum is the router. You can do anything with it. API, web, whatever. Topcoat is a heavy layer on top focused on views.

Honestly I was surprised Topcoat wasn't building on top of Axum's routing.

Phoenix, HTMX, Data Star are all big sources of inspiration. Both HTMX and Data Star have built in support too.

The standard is more like Sinatra than Rails.

Topcoat is very cool though, and there’s a few others in this space too, like Loco. So maybe we’ll see folks move to something more batteries included.

This is pretty easy to understand if you have a cursory understanding of Rust and HTML.

I won't get into the HTML part (I think it's obvious), but the

  $(|_e| count.increment())

pretty simply

it’s like react.js in the early days but worse somehow

I come from Java, I disagree.

The majority of rust's ugliness is the fact that it's handling a different problem than Java does. Java relies heavily on a GC to simplify. Rust does not.

I think the only thing that I find ugly in rust is that memory leaks are considered memory safe. [1]

That, unfortunately, means that you can't 100% rely on the language to not leak memory. Though, it's possible to leak memory in Java as well (Use `Deflate` incorrectly and you'll quickly find a hard to catch memory leak).

[1] https://brson.github.io/rust-anthology/1/memory-leaks-are-me...

I thought the same thing. I started working full time in Rust back in March and the first few weeks I thought “this is ridiculous, it’s so ugly and hard to read”. My background is in C++ for game development (10y) followed by CTO of a web startup (JS/Python/TypeScript), so I know ugly code!

You absolutely do get used to it and I really like the built in formatters. I would write everything in Rust going forward if I could, it really is a different way of thinking about how to write code. I don’t agree it’s the right tool for every job though.

Just like any other language, you can get used to it. There are ways to hide the uglyness and i am not sure if this is a good thing. (i will always hate macros!)

I haven't tried to the web app part but I've tried Toasty. The API seemed to be a little simpler and nicer to use than SeaORM for me. Here are a few things I liked in Toasty:

- In SQLite UUIDs are default stored as compact blobs instead of inefficient varchar/text (SeaORM)

- Timestamps were easier via jiff instead of chrono (SeaORM)

- Model structs use the actual name of the $table instead of being named like $tablemodule.(Model|ActiveModel) (SeaORM) they are just $Table. This makes writing libraries a little simpler that need to use entity struct's from two separate modules/crates otherwise you get a name collision on Model/ActiveModel and need to do alias imports.

- There's an API to fetch related data to a query similar to Django ORM. IIRC this is missing from SeaORM

- The query expression language doesn't cover as much of SQL as SeaORM but seems to be enough for most web apps.

- I didn't like how the migration system works. I would skip that part of the library

I have tried it. It feels pretty good to use, but you have to keep in mind that it's very early software. They currently break the API every other week, and it's still missing a lot of fundamental features. I have made a few basic web apps with it, and on v0.8.1 it was still missing a lot of reactivity which meant you had to use Javascript to bridge the gap.

We’re using it to build our web app (https://uncook.xyz) and while it’s a slight departure from my team’s NodeJS background it’s been pretty cool to work with

Luckily there's a lot of people who write prototype code, toy projects, and other "non-production" code that can experiment with a new project like this

I'd rather honestly than false confidence, there's something admirable about being this clear for sure

That is in reference to the entire software industry. I’m not confident that we’re we’ll be building apps at all in 10 years vs just AI integrations

Go use Java then.

> write it in C and ask an LLM to weed out the memory bugs?

because a non-determinist chain of reasoning is not the same as a fully deterministic algorithm. Its the best tool when a deterministic system is not feasable.

If you go that way, why not write LLVM Intermediate Representation? And if you know your server CPU anyway, why not write machine code?

I personally like Rust for web applications a lot because you can catch many bugs at compile time instead of during tests or runtime.

Why bother with asking an LLM to weed out the memory bugs when you can write it in Rust?

Why bother with rust when you can write it in C and ask an LLM to weed out the memory bugs?

Here is a idea, why not combine both? Have the advantage of Rust its build in checks and LLMs independent checks. Now you get both for a even more safe program.

Why bother with C when you can get an LLM to write it in Rust and not waste tokens on finding memory bugs