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.

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

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.

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).

I hope I'm not discouraging you with what I'm writing. This looks to me like a cool project/idea. Unfortunately the landing page just immediately made me uninterested when I tried reading the text.

I think the reason for that is, the text to me feels immediately AI generated which evokes a feeling of "the human didn't care enough to do the easiest part, which is to describe their project themselves".