Funny, the Python guys say Python is the best general-purpose language for AI and the Go guys say Go is the best general-purpose language for AI etc etc
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.
But you can speed things up a lot by organizing your project into separate crates (which are compiled in parallel) and tweaking compiler flags. I speed up a large project by 7x this way.
Also, if you’re using fat LTO in release builds, switch to thin. It’s almost as fast at runtime and much much faster to compile.
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.
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.
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
The things that look great are LiveView and getting rid of boilerplate for client-side reactivity
That's why I created SnapFire FSR (https://www.snapfirers.com), but many examples, to allow frontend devs to develop in their favorite framework (or mixture of). Write Tera templates, Web Components if you don't want to bring in frameworks like I tend to. Don't need to pay massive switching costs which, even with, AI not fun.
I found it much better to create and maintain web apps near the markup and language they originated from. You won't find me writing straight Rust for Web Apps unless I need to anymore.
I'm going to continue to work on this and switch all my leptos and svelte sites over.
I've built apps recently in swift, rust, zig, node with HTML UI (not electron) for MacOS and I care less about the code as the AI agent does a perfect job in all of them, even if I don't see much difference in the results (except HTML which is pretty but weird)
Asked the same question to AI and she told me Swift is the best choice for MacOS apps just because it doesn't need C bridges between their kits/libraries and that in itself is an optimization gain
Of course Swift in Linux is not the best option, probably the last, in Microsoft probably .NET I don't know, haven't used MS products in twenty years
The point is, language selection is best decided on platform optimization, not on personal preference. I guess AI killed language wars?
I'd personally like my ORMs (if I'm going to use them) to be closer and more explicit about the queries that I'm writing. ORMs tend to add a lot of complexity for very little benefit. SQLx is much closer to my cup of tea than Toasty.
Underlying DBs have different characteristics, so trying to make an abstraction layer for multiple dbs (including no-sql in the docs) means you are going to run into limitations and abstraction leaks that are hard to square. Correctly using the likes of Dynamodb is very different from correctly using postgres, for example.
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.
Better leave Rust for when any kind of automatic resource management isn't acceptable, either due technical or social reasons.
Also here is another point, AI agentic programming is basically using automatic resource management infrastructure.
When you are no longer at the steering wheel, if the taxi has manual or automatic is irrelevant to reach the destination.
What the heck is this.
I won't get into the HTML part (I think it's obvious), but the
$(|_e| count.increment())
pretty simply
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...
- 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
Hell yeah, been saying this more than 2 years already
As honest as it is I can't risk using this anywhere near production if this is the attitude.
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.
There is OCaml which compiles very fast in debug mode.
Since it's going to be mostly cargo check and incremental builds, I don't think it matters in practice.
The big difference to Rust is the availability of interpreters, REPL, which can equally load compiled code, and full blown AOT for release builds.
Rust's problem isn't type system, rather lack of tools.
@dataclass @final class CaseA[T]:
field: T
type MyEnum[T] = CaseA[T] | CaseB
Typed dicts (with the latest PEPs) are an improvement over any other language besides TypeScript. Yes, in TS, certainly `Partial` / `Pick` / `Omit` and intersection types make modeling the web API swamp easier, and that's one place TS is superior to anything else.
Python does have the Type Manipulation PEP 827 [1] out to give it similar powers to TS, but I feel that's unlikely to be implemented soon / as-is.
Having an effect system for exceptions would be nice indeed. That's actually something I'm looking into (having an "allowed exceptions" annotation for functions and then checking it at test-time via failure injection and possibly in type checkers).
I realized all the Rust code produced meant squat if it couldnt be audited well afterwards.
The question is where the "enough confidence" border lies - and in the worse case the only way to do some reliable investigatios would be printf debugging or its alikes.
Your legacy codebase generates ~300 billion a year?
[dead]
There aren’t many comparative benchmarks, and obviously the design of such a benchmark is difficult, but, e.g. https://arxiv.org/abs/2508.09101
In this benchmark, models can correctly solve Rust problems 61% on first pass — A far cry from other languages such as C# (88%) or Elixir (97%, no static typing whatsoever).
Having to tweak code and compile more often makes things slower, but strict compilers also help you find bugs faster and navigate the codebase. I think the two effects balance out and leave you with safer code in the end. And that's not counting the performance benefits of a compiled language.
Doing that enables a bunch of performance tricks like starting to steam the page before data i loaded and concurrently render components.
If you have to split your page into many small components, a separate view file for each becomes tedious.
Even though macros can do this, it's not intuitive to expect this kind of JSX soup in rust. It's difficult to reason about than a function call. Something like flutter where widgets are ordinary function calls is far better.
Plus the macros add to the compile time tax.
This is another exhibit that rust is full of web programmers from React JS world (the above is exactly like JSX), all about aesthetics than practicality and predictability these days, pulling what should be a system language into incompatible directions.
Long live zig for trying engineering directions rust couldn't. But we need a rust killer with memory safety which gatekeeps web programmers and slop peddlers.
Start a thread with an infinite loop, you've just leaked some memory.
The language just can't prevent you.
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.
[deleted]
It is not. But rust's borrow checker has its costs. It forces awkward implementations. Either suffer the horrible life time syntax, or pay the price of clone everywhere.
If you use C and run LLMs over it once in a while, I think it will get you most of the way.
I personally like Rust for web applications a lot because you can catch many bugs at compile time instead of during tests or runtime.
Nah, C is good enough for me.
> catch many bugs at compile time...
Rust borrow checker is too dumb that you catch many non-bugs as well...I don't like that.
Mmm..LLMs also generates false positives. But at least you can reason with it...
Because fuck borrow checker..(and the horrible syntax)
Add to that the horror of life time annotations, you really have a mess at your hands. I have seen projects litter clone everywhere just to sidestep this mess.
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.
Thus, the agent needs to iterate less.
I mean, I didn't meant to run the LLM every compile cycle. May be just before a release or something..