> Rust is the best general-purpose language for the new world of AI-driven development.
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
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.
Compile times in Rust are partly the amount of analysis that occurs, partly that it uses LLVM which is optimized for creating fast code at runtime but not necessarily fast-compiling code, and partly the fact that the Rust compiler is inefficient and does the same work twice or recompiles things it doesn’t need to.
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.
Even incremental builds can be slow depending on eg. what macros you use. For example, i had bad surprises with askama which is a delight in most cases, but really makes compilation slower as you add more templates. On a project with ~20 templates, incremental build in debug mode now takes ~40s on a very fast machine.
I love python for some stuff, but i definitely would not say it has an expressive type system. Enums are a second-class citizen, and typed dicts are definitely not as convenient as i would like. And to my knowledge, type checkers don't support proper exception catching rules; rust also has no guarantee that a function won't panic, but usage of Result type makes it less of a problem (because panic is more or less exclusively for unrecoverable invariant violations), and there's ecosystem tools to make sure you don't ever panic.
If by enums you mean sum-type ADTs (like in Rust), then Python is certainly quite expressive - it has union types, which can represent polymorphic variants - those are slightly more expressive than pure Rust-style ADTs since you can arbitrarily subset or extend the enum cases.
@dataclass @final class CaseA[T]:
field: T
type MyEnum[T] = CaseA[T] | CaseB
This also gets exhaustiveness checking in `match` statements (depending on the type checker). Overall, enums have a similar style to Scala and Java >=21 (mixing OO + ADT). I guess syntactically it can be slightly verbose depending on the exact situation...
I wouldn't call them second class, but yeah, not a lot of existing libraries use this style.
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).
Auditing Rust is much easier and faster than either Go or Python. They both contain a lot of footguns that are not always immediately apparent from visible code. Rust is much more explicit.
This is assuming equal familiarity with all languages but I presume this comment is more referring to talent pools & experience. A good engineer can traverse & review many languages but most are quite restricted in the scope of what they can easily read - they miss a footgun or two in python but they're not grokking any of the rust whatsoever.
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.
Unless you're doing something really dynamic, I don't really understand this position and would like to learn more. for most cases gradual typing is a great option that can be done incrementally in Python (two things even cheap agents are really good at).
You can't forbid people doing something "really dynamic". And in a sufficiently big system, over long period of time, this stuff will accumulate - 100%. Then you'll get to a point where answering questions like "is this piece of code still alive" with enough confidence is almost impossible.
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.
It sounds like your app is using a lot of dynamic techniques like meta-programming? If so, that makes a lot of sense. Most of the apps I've seen use very little use of meta-programming and friends and incremental typing worked rather well.
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.
Do you have any substantial sound metrics and study? I can think of many ways for a Rust program to not remove all fears that it will not do what I intended, doubly so for a vibe-coded Rust program.
You‘ll notice a lot of "I found"s and "my hunch"s and similar in the comments.
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).
First pass is not that important today. All coding agents run until they get it right or hit a limit.
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.
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.
Some absolutely great work, but I don't know why you would come up with a new term for a server component (shard). Why not just use the obvious client/server annotations so you don't have to define a novel term for new users?
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 used to write Leptos, but abandoned it. I hoped the experience would get better, it took a lot of memory just for the language server to validate especially. Web apps become too cumbersome to maintain in bigger distributed teams where we want fast feedback. I think writing web apps in straight rust will always be niche. There's not many frontend devs who write React or Vue who want to write straight Rust just because of safety or performance.
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.
It's interesting to see that they let you mix markup with logic directly in rust, but I have worries about maintainability. I remember the bad old days of PHP where you'd mix markup with logic directly, even when doing OOP with classes and it really made things more difficult long term.
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.
Yes, I saw that's it's via macros, but my point is that it reminded me of some web development practices from a much earlier era, and why we moved towards doing templates and separating app logic from presentation
The trend has been to move back to this style in general (see most modern JS frameworks). The main point is less about combining code and view, but breaking up the page into many small components and pushing data loading down into where it is needed vs up front.
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.
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.
Topcoat needs an Inertia like React integration + Stylex (type safe CSS) on the frontend imo if you want make it as agent friendly as possible. HTMX, Tailwind etc. are still ok but folks who switch to Rust now do this mostly for easier and safer automation. So if you want to grow the framework better think about React.
In times of AI the language doesn't matter, not even if the dev can read it or not, what matters is the result, speed, optimization, interoperability, UI/UX adaptability to user expectations
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.
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())
part is a rust closure. |_e| is the argument to the closure, which has a leading underscore because it's unused. I imagine it's some context about the event (thus the e).
The rest is the body of the closure. It increments the count.
GP is pointing out this introduces this kind of special DSL syntax with HTML tags into a procedural/functional language like rust?
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.
One of the main designers of this has a lot of flutter projects and no JSX projects on their github so I have no idea what you're on about. They also have a YouTube channel dedicated to their C++ voxel game engine https://www.youtube.com/channel/UCDye5hFy14hdQGohhqpY6LQ
Honestly Rust is an ugly looking language, I mean it's probably okay if you're coming from C or C++ but if you're coming from say Java, it's horrendous.
but then again that probably does not matter at all.
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).
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
Do you have feedback on what you don’t like re: the migration system? It is inspired by drizzle. Is it something we missed or just not a fan of that style entirely?
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
> 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.
>because a non-determinist chain of reasoning is not the same as a fully deterministic algorithm.
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.
99% of code only needs to know 'static and 'a, maybe 'b when you take two references and return one but that's pretty rare. You only get into complex lifetimes if you write the kind of code that belongs in a library.
Reuse is bad / NIHS is good and it's hard to reach token metrics using accepted engineering practices. That leads to the point of having the LLM invent a new specialized job security chip architecture for your IR just to run CRUD app.
I don't get the complaints about the horrible syntax. The syntax is fine... Which is weird cause I only get complains from c/c++ folk, and that set of languages have objectively AWFUL syntax
Rust's syntax is horrible not because of the braces. But due to the type system information the code has to carry. And the type system, unlike something like Haskell, is not always smart enough to infer the types from the context. Which cause even more noise in the form of type hints!
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.
So actually the answer to your question is that Rust provides excellent guardrails against memory safety issues, and in some cases, for code correctness as well, by allowing more behavior to be encoded in types. One of those guardrails is borrow checker.
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.
> Rust is the best general-purpose language for the new world of AI-driven development.
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
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.
Compile times in Rust are partly the amount of analysis that occurs, partly that it uses LLVM which is optimized for creating fast code at runtime but not necessarily fast-compiling code, and partly the fact that the Rust compiler is inefficient and does the same work twice or recompiles things it doesn’t need to.
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.
> 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.
There is OCaml which compiles very fast in debug mode.
> But on the other hand, the compile time of Rust is really counterproductive.
Since it's going to be mostly cargo check and incremental builds, I don't think it matters in practice.
Even incremental builds can be slow depending on eg. what macros you use. For example, i had bad surprises with askama which is a delight in most cases, but really makes compilation slower as you add more templates. On a project with ~20 templates, incremental build in debug mode now takes ~40s on a very fast machine.
OCaml, Haskell, F#, Standard ML.
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.
Python has a strong, expressive static type system with a very fast type checker (Pyrefly).
I love python for some stuff, but i definitely would not say it has an expressive type system. Enums are a second-class citizen, and typed dicts are definitely not as convenient as i would like. And to my knowledge, type checkers don't support proper exception catching rules; rust also has no guarantee that a function won't panic, but usage of Result type makes it less of a problem (because panic is more or less exclusively for unrecoverable invariant violations), and there's ecosystem tools to make sure you don't ever panic.
If by enums you mean sum-type ADTs (like in Rust), then Python is certainly quite expressive - it has union types, which can represent polymorphic variants - those are slightly more expressive than pure Rust-style ADTs since you can arbitrarily subset or extend the enum cases.
This also gets exhaustiveness checking in `match` statements (depending on the type checker). Overall, enums have a similar style to Scala and Java >=21 (mixing OO + ADT). I guess syntactically it can be slightly verbose depending on the exact situation... I wouldn't call them second class, but yeah, not a lot of existing libraries use this style.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).
[1]: https://peps.python.org/pep-0827/
Can your team read and audit Rust code as fluently as Go or Python?
I realized all the Rust code produced meant squat if it couldnt be audited well afterwards.
Auditing Rust is much easier and faster than either Go or Python. They both contain a lot of footguns that are not always immediately apparent from visible code. Rust is much more explicit.
This is assuming equal familiarity with all languages but I presume this comment is more referring to talent pools & experience. A good engineer can traverse & review many languages but most are quite restricted in the scope of what they can easily read - they miss a footgun or two in python but they're not grokking any of the rust whatsoever.
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.
Unless you're doing something really dynamic, I don't really understand this position and would like to learn more. for most cases gradual typing is a great option that can be done incrementally in Python (two things even cheap agents are really good at).
You can't forbid people doing something "really dynamic". And in a sufficiently big system, over long period of time, this stuff will accumulate - 100%. Then you'll get to a point where answering questions like "is this piece of code still alive" with enough confidence is almost impossible.
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.
It sounds like your app is using a lot of dynamic techniques like meta-programming? If so, that makes a lot of sense. Most of the apps I've seen use very little use of meta-programming and friends and incremental typing worked rather well.
> your legacy codebase is earning tens of thousands $ per second.
Your legacy codebase generates ~300 billion a year?
Okay - not earning, but processing. Adjust the figure a bit for varying traffic patterns during week and seasonality, and it'll be kinda like that.
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.
Do you have any substantial sound metrics and study? I can think of many ways for a Rust program to not remove all fears that it will not do what I intended, doubly so for a vibe-coded Rust program.
You‘ll notice a lot of "I found"s and "my hunch"s and similar in the comments.
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).
First pass is not that important today. All coding agents run until they get it right or hit a limit.
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.
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?
assembler?
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.
Some absolutely great work, but I don't know why you would come up with a new term for a server component (shard). Why not just use the obvious client/server annotations so you don't have to define a novel term for new users?
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 really like the direction Topcoat is going in as a Rails developer. Although it is just a bit itchy to my eyes, it is not acid-level, though.
The things that look great are LiveView and getting rid of boilerplate for client-side reactivity
I used to write Leptos, but abandoned it. I hoped the experience would get better, it took a lot of memory just for the language server to validate especially. Web apps become too cumbersome to maintain in bigger distributed teams where we want fast feedback. I think writing web apps in straight rust will always be niche. There's not many frontend devs who write React or Vue who want to write straight Rust just because of safety or performance.
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.
It's interesting to see that they let you mix markup with logic directly in rust, but I have worries about maintainability. I remember the bad old days of PHP where you'd mix markup with logic directly, even when doing OOP with classes and it really made things more difficult long term.
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.
Yes, I saw that's it's via macros, but my point is that it reminded me of some web development practices from a much earlier era, and why we moved towards doing templates and separating app logic from presentation
The trend has been to move back to this style in general (see most modern JS frameworks). The main point is less about combining code and view, but breaking up the page into many small components and pushing data loading down into where it is needed vs up front.
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.
I bet with AI we will complicate existing apps because it is now easier to develop.
Hopefully there is still space for Axum to exist too! I like this directionally, but I've really enjoyed my time with Axum.
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.
Topcoat needs an Inertia like React integration + Stylex (type safe CSS) on the frontend imo if you want make it as agent friendly as possible. HTMX, Tailwind etc. are still ok but folks who switch to Rust now do this mostly for easier and safer automation. So if you want to grow the framework better think about React.
Sounds a lot like Liveview in Phoenix.
Phoenix, HTMX, Data Star are all big sources of inspiration. Both HTMX and Data Star have built in support too.
In times of AI the language doesn't matter, not even if the dev can read it or not, what matters is the result, speed, optimization, interoperability, UI/UX adaptability to user expectations
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?
Funny, I was working with Claude and Astra today ideating on how Loco and topcoat could be integrated for the ultimate modern rails alternative stack
My main critique would be that I dislike the ORM.
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.
Is there a batteries included Rails for Rust that people go to other than this Topcoat? What is the standard when building a web-app in rust?
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.
Loco is probably what the parent is asking for :). It paints itself as Rust-on-Rails.
Cool, thanks!
Compiled languages with automatic resource management are much more ergonomic for distributed systems, and have faster compilers.
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.
`<button @click=$(|_e| count.increment())>"increment"</button>`
What the heck is this.
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
part is a rust closure. |_e| is the argument to the closure, which has a leading underscore because it's unused. I imagine it's some context about the event (thus the e). The rest is the body of the closure. It increments the count.pretty simply
GP is pointing out this introduces this kind of special DSL syntax with HTML tags into a procedural/functional language like rust?
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.
One of the main designers of this has a lot of flutter projects and no JSX projects on their github so I have no idea what you're on about. They also have a YouTube channel dedicated to their C++ voxel game engine https://www.youtube.com/channel/UCDye5hFy14hdQGohhqpY6LQ
It's a bad design regardless, borrowing from JSX playbook.
it’s like react.js in the early days but worse somehow
Honestly Rust is an ugly looking language, I mean it's probably okay if you're coming from C or C++ but if you're coming from say Java, it's horrendous. but then again that probably does not matter at all.
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...
> you can't 100% rely on the language to not leak memory
Start a thread with an infinite loop, you've just leaked some memory.
The language just can't prevent you.
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.
The built-in formatter drives me insane it's always choosing or not choosing to line break in places that make zero semantic sense.
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!)
Has anyone here tried it?
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
Do you have feedback on what you don’t like re: the migration system? It is inspired by drizzle. Is it something we missed or just not a fan of that style entirely?
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.
I used it in the early days, and it seems it's still the same. Thank you.
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
cute app
> Rust is the best general-purpose language for the new world of AI-driven development.
Hell yeah, been saying this more than 2 years already
> Look, I don’t know where we are going.
As honest as it is I can't risk using this anywhere near production if this is the attitude.
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.
Why bother with rust when you can write it in C and ask an LLM to weed out the memory bugs?
> 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.
>because a non-determinist chain of reasoning is not the same as a fully deterministic algorithm.
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.
99% of code only needs to know 'static and 'a, maybe 'b when you take two references and return one but that's pretty rare. You only get into complex lifetimes if you write the kind of code that belongs in a library.
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.
>If you go that way, why not write LLVM Intermediate Representation? And if you know your server arch anyway, why not write machine code?
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...
Reuse is bad / NIHS is good and it's hard to reach token metrics using accepted engineering practices. That leads to the point of having the LLM invent a new specialized job security chip architecture for your IR just to run CRUD app.
Soon we're gonna need a way to catch bugs at prompt time
Why bother with asking an LLM to weed out the memory bugs when you can write it in Rust?
> when you can write it in Rust..
Because fuck borrow checker..(and the horrible syntax)
I don't get the complaints about the horrible syntax. The syntax is fine... Which is weird cause I only get complains from c/c++ folk, and that set of languages have objectively AWFUL syntax
Rust's syntax is horrible not because of the braces. But due to the type system information the code has to carry. And the type system, unlike something like Haskell, is not always smart enough to infer the types from the context. Which cause even more noise in the form of type hints!
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.
It’s subjective. Some folks think lisps are it, others basic. Folks need to accept that we do not need global alignment on what good syntax means.
So actually the answer to your question is that Rust provides excellent guardrails against memory safety issues, and in some cases, for code correctness as well, by allowing more behavior to be encoded in types. One of those guardrails is borrow checker.
Thus, the agent needs to iterate less.
>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..
As if C was any better than rust. So much clutter. So hard to grok with all the macros. I'd rather read rust than C.
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.
That is the worst of both worlds. You are paying for rust borrow checked forcing awkward designs, and you are paying for tokens.
Why bother with C when you can get an LLM to write it in Rust and not waste tokens on finding memory bugs