4 ms·

Lots of tortured logic in this post. 1. You shouldn't pick a programming language the team doesn't know. That's common sense, not an argument against Rust. 2.

Lots of tortured logic in this post. 1. You shouldn't pick a programming language the team doesn't know. That's common sense, not an argument against Rust. 2. Rust ranks lower on the most used languages list because it's newer than Java, Python, C, and all of the others higher on the list. 3. You don't need to use async Rust. If you do, I disagree that it's as hard as this is implying, but I would agree that it's not as easy as writing sync code. 4. Rust projects don't decay like this is saying. Rust has editions and you can stay on an older edition until you're ready to port it forward. My experience with jumping to a new Rust edition has been easy across all projects so far. It's funny that they argue that adding new features to the language leads to unmanageable complexity, because the very next topic argues that the standard library doesn't have enough features. 5. If you want a batteries-included standard library I agree that you should pick Python or Go instead. Most of the blog is an ad for the author's book. I was hoping this post had some substance but I think they chose the title first to attract clicks for the book ad and then tried really hard to find some content for the article second.

traderj0e 6mo ago
For the use cases the author is alluding to, you do need to use async. Non-cooperative threaded multitasking isn't a real choice for backends, and Rust doesn't have virtual threads. Before Java got virtual threads in Project Loom, people were typically using some promises equivalent even though it mangled the heck out of all your code, cause they didn't want to be doing blocking stuff with a thread pool. That was a big motivator for Go and Kotlin coroutines, and why Rust and Python put so much effort into adding event loops after the fact.
- jen20 6mo ago
  > why Rust and Python put so much effort into adding event loops after the fact. Perhaps Python, but Rust went the other way - it had all that stuff built and it was removed.
  - traderj0e 6mo ago
    Er yeah technically the event loop isn't part of Rust, just the async/await syntax. But it's implied that you're going to use some event loop with it.
    - tracker1 6mo ago
      No, it's implied that you're going to use some sort of async runtime with it... said runtime can be simple real threads, a thread pool or virtual threads and there are implementations for all of them. And even then, it's super easy to start a new real thread in rust, around any async runtime.
      - jen20 6mo ago
        While true, this isn’t what I’m talking about: Rust had _built in_ green threads at one point, the same as Go [1]. [1]: https://rust-lang.github.io/rfcs/0230-remove-runtime.html https://rust-lang.github.io/rfcs/0230-remove-runtime.html
    - jen20 6mo ago
      True now, but there was a time when async/await was _not_ part of Rust, and a runtime was.
- tracker1 6mo ago
  For that matter, even if you do use async, if you're writing a service based app (such as web services), IMO, you'd probably just want to center on tokio and axum, then stick to the tokio ecosystem. The main reason it's not a blessed standard library thing, is that Rust can scale down into embedded systems usage, and you aren't going to use something like Tokio there... that doesn't mean you shouldn't just use what everyone else does at a higher level application. Also, in regards to OP's reference to changes to Rust, it's not changes/additions or bug fixes that should be a concern, it's the number of breaking changes. For a contemporary counter example, look at how much C# has changed since the .Net Core fork started out... They're on version 11 now (skipped v4), and that doesn't count the library sub-version shifts along the way. And a lot of critical banking infrastructure is written in and running on it (as well as Java). Your money is literally relying on it.
  - SkiFire13 6mo ago
    > And a lot of critical banking infrastructure is written in and running on it How much of that critical infrastructure runs on .NET Framework as opposed to the latest .NET Core though?
    - moomin 6mo ago
      IME: less than you’d think. I know one major C# project that’s only half completed its migration and that huge (both in terms of what’s been achieved and what still needs doing). There’s another that keeps it for the front end because it runs on >10,000 client machines. All the others, big or small, have migrated with small carve-outs for stuff .NET Core doesn’t and probably never will support.
    - tracker1 6mo ago
      From recent experience I'd put it slightly higher on the old framework, but plenty of new dev on v5+ and I think sticking on framework is worse at this point. Though I would say that breaking changes since Core 3 have been pretty limited. V5 unified .net under the new core as the path forward for framework users as well.
- ViewTrick1002 6mo ago
  Rust had that, but decided it wasn’t a good enough fit. Which was the motivation to keep exploring and land on the current async implementation which scales from embedded to servers with minimal overhead. History: This RFC proposes to remove the runtime system that is currently part of the standard library, which currently allows the standard library to support both native and green threading. https://github.com/rust-lang/rfcs/blob/master/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/master/text/0230-remo...
  - sysguest 6mo ago
    well rust async is 'still evolving' right now it's better than being stuck, but it's not '100% polished' right now (though some crates do make the experience somewhat more polished: especially dtolnay's crates)
    - ViewTrick1002 6mo ago
      Agree. There's stuff missing, and there are problems which likely are "multiple Phd theses" level to solve cohesively. Either in Rust or a successor language when the problem space has been explored. For me the most annoying part are the footguns async Rust introduces, which Rust generally is blessedly empty of compared to e.g. Go or other languages. Like for example, cancellation safety, dealing with "long running" futures, cleanly terminating a program, deadlocks at a distance [1] and others I'm forgetting now. [1]: https://rfd.shared.oxide.computer/rfd/0609 https://rfd.shared.oxide.computer/rfd/0609
      - deleted 6mo ago
        [deleted]
- andriy_koval 6mo ago
  > Before Java got virtual threads in Project Loom, people were typically using some promises equivalent even though it mangled the heck out of all your code I think majority Java code is just sequential blocking code, and it works just fine.
- fulafel 6mo ago
  This take on native threads sounds overly pessimistic. 99% of backends do fine with the nr of native threads you can easily run in a single process at least on Linux. Not sure what the practical limit is now but 10k used to be no problem many years ago. (eg 100k threads in 2002: https://lkml.iu.edu/hypermail/linux/kernel/0209.2/1153.html https://lkml.iu.edu/hypermail/linux/kernel/0209.2/1153.html .. where the 32-bit 4 GB limit seemed to be the main obstacle)
  - traderj0e 6mo ago
    I believe it's fine when you're tuning it. Nowadays people are more likely to have multiple services waiting on each other to handle a user request, each running in containers on random hardware. Even if it's "monolithic," it's probably not really cause they're waiting on external APIs. They don't want to think about tuning for thread pools too.
    - deleted 6mo ago
      [deleted]
    - fulafel 6mo ago
      I can believe some people have implemented misconfigured thread pools, being worse off than with no thread pool at all. But this not an argument that justifies a "multitasking isn't a real choice for backends" position. (Then there's bugs that happen in both asyncio and threaded programs, that stem from various queuing problems in the system, manifesting as work getting backed up in the concurrency layer. You end up needing backpressure in both worlds, thread pool limits are the wrong layer to do it.)
pointlessone 6mo ago
> 3. You don't need to use async Rust. Technically correct, but… Want to build a web app, every more or less popular framework is async. Want to make a web request? High change of async. Database? Very likely async, too. A huge fraction of crates are async. Right now crates.io says there are "54172 reverse dependencies of tokio”. And the page that lists them struggles mightily to load. And that’s only direct dependencies of tokio, no indirect ones, no dependencies on other runtimes, no generic dependents.
- andriy_koval 6mo ago
  > Want to build a web app, every more or less popular framework is async. I think its the same as Java, Tomcat has some async threadpool inside, they just hide it from you, and your favorite rust framework doesn't, you need manually move your sync logic to Tokio spawn_blocking
  - traderj0e 6mo ago
    Java is different. Tomcat's thread pool is the older way. A lot of newer stuff was using something promises-related instead with an event loop. But then recently Java added virtual threads which should obviate the need for that, similar to Go. Rust considered virtual threads but chose against that because it requires a more abstracted runtime like Java and Go have. Great preso on this https://www.youtube.com/watch?v=lJ3NC-R3gSI https://www.youtube.com/watch?v=lJ3NC-R3gSI All the "async" stuff is super poorly named. They mean cooperative multitasking, or I guess "async within a single kernel thread." Yeah multiple kernel threads are asynchronous but "async" doesn't mean that :S
- bryanlarsen 6mo ago
  And all the popular ones include a synchronous interface you can use instead of the async one. If if they don't, you can wrap your calls in spawn_blocking. You might complain about it pulling in tokio, but that's a very different complaint than having to learn/use async.
  - simon_void 6mo ago
tialaramex 6mo ago
> You shouldn't pick a programming language the team doesn't know. That's common sense, not an argument against Rust. Actually if your team doesn't know any suitable languages it could make sense to pick Rust because they will cause far fewer accidental fires in Rust. (Safe) Rust is much more forgiving of "I didn't know that's how computers work" than a language like C or C++ yet it's as close to the metal as they are which may matter for your application. If you're hiring programmers they probably already know some suitable languages which should strongly influence your choice, but if the team's main expertise is not programming they may take to Rust much easier than you'd expect.
nextaccountic 6mo ago
> 5. If you want a batteries-included standard library I agree that you should pick Python or Go instead. But then you should be warned that, among the various http clients Python has in their stdlib, none should be used. Or the many datetime libs in the Python stdlib, they should not be used. LLMs know this by the way and will reach for actual best practices
lenkite 6mo ago
> 3. You don't need to use async Rust. This is like saying you don't need to use a Smartphone. Technically, correct, but then you need to live like a caveman.
- worik 6mo ago
  I do a lot of real-time audio programming in Rust because it is so expressive and the compiler so helpful But I disagree. I do not use asyc/await for my asynchronous programming in Rust if I get the choice. I have used it extensively in other languages, and when I've had to in Rust, but there are many problems The paradigm itself is not suited to hard real-time programming. An explicit event loop is unbeatable in that case The model does not fit properly in the Rust memory model, and quite often you find yourself using pretzel logic and "magic incantations" to get around that It is synchronous in style, and a footgun as CPU bound operations can block it. The threading support in Rust is superb and for the vast majority of cases a perfect fit Async/await in Rust is a very impressive technical achievement, I am very impressed by how much gets done so efficiently and how well the runtime perform

traderj0e 6mo ago

For the use cases the author is alluding to, you do need to use async. Non-cooperative threaded multitasking isn't a real choice for backends, and Rust doesn't have virtual threads. Before Java got virtual threads in Project Loom, people were typically using some promises equivalent even though it mangled the heck out of all your code, cause they didn't want to be doing blocking stuff with a thread pool. That was a big motivator for Go and Kotlin coroutines, and why Rust and Python put so much effort into adding event loops after the fact.

jen20 6mo ago
> why Rust and Python put so much effort into adding event loops after the fact. Perhaps Python, but Rust went the other way - it had all that stuff built and it was removed.
- traderj0e 6mo ago
  Er yeah technically the event loop isn't part of Rust, just the async/await syntax. But it's implied that you're going to use some event loop with it.
  - tracker1 6mo ago
    No, it's implied that you're going to use some sort of async runtime with it... said runtime can be simple real threads, a thread pool or virtual threads and there are implementations for all of them. And even then, it's super easy to start a new real thread in rust, around any async runtime.
    - jen20 6mo ago
      While true, this isn’t what I’m talking about: Rust had _built in_ green threads at one point, the same as Go [1]. [1]: https://rust-lang.github.io/rfcs/0230-remove-runtime.html https://rust-lang.github.io/rfcs/0230-remove-runtime.html
  - jen20 6mo ago
    True now, but there was a time when async/await was _not_ part of Rust, and a runtime was.
tracker1 6mo ago
For that matter, even if you do use async, if you're writing a service based app (such as web services), IMO, you'd probably just want to center on tokio and axum, then stick to the tokio ecosystem. The main reason it's not a blessed standard library thing, is that Rust can scale down into embedded systems usage, and you aren't going to use something like Tokio there... that doesn't mean you shouldn't just use what everyone else does at a higher level application. Also, in regards to OP's reference to changes to Rust, it's not changes/additions or bug fixes that should be a concern, it's the number of breaking changes. For a contemporary counter example, look at how much C# has changed since the .Net Core fork started out... They're on version 11 now (skipped v4), and that doesn't count the library sub-version shifts along the way. And a lot of critical banking infrastructure is written in and running on it (as well as Java). Your money is literally relying on it.
- SkiFire13 6mo ago
  > And a lot of critical banking infrastructure is written in and running on it How much of that critical infrastructure runs on .NET Framework as opposed to the latest .NET Core though?
  - moomin 6mo ago
    IME: less than you’d think. I know one major C# project that’s only half completed its migration and that huge (both in terms of what’s been achieved and what still needs doing). There’s another that keeps it for the front end because it runs on >10,000 client machines. All the others, big or small, have migrated with small carve-outs for stuff .NET Core doesn’t and probably never will support.
  - tracker1 6mo ago
    From recent experience I'd put it slightly higher on the old framework, but plenty of new dev on v5+ and I think sticking on framework is worse at this point. Though I would say that breaking changes since Core 3 have been pretty limited. V5 unified .net under the new core as the path forward for framework users as well.
ViewTrick1002 6mo ago
Rust had that, but decided it wasn’t a good enough fit. Which was the motivation to keep exploring and land on the current async implementation which scales from embedded to servers with minimal overhead. History: This RFC proposes to remove the runtime system that is currently part of the standard library, which currently allows the standard library to support both native and green threading. https://github.com/rust-lang/rfcs/blob/master/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/master/text/0230-remo...
- sysguest 6mo ago
  well rust async is 'still evolving' right now it's better than being stuck, but it's not '100% polished' right now (though some crates do make the experience somewhat more polished: especially dtolnay's crates)
  - ViewTrick1002 6mo ago
    Agree. There's stuff missing, and there are problems which likely are "multiple Phd theses" level to solve cohesively. Either in Rust or a successor language when the problem space has been explored. For me the most annoying part are the footguns async Rust introduces, which Rust generally is blessedly empty of compared to e.g. Go or other languages. Like for example, cancellation safety, dealing with "long running" futures, cleanly terminating a program, deadlocks at a distance [1] and others I'm forgetting now. [1]: https://rfd.shared.oxide.computer/rfd/0609 https://rfd.shared.oxide.computer/rfd/0609
    - deleted 6mo ago
      [deleted]
andriy_koval 6mo ago
> Before Java got virtual threads in Project Loom, people were typically using some promises equivalent even though it mangled the heck out of all your code I think majority Java code is just sequential blocking code, and it works just fine.
fulafel 6mo ago
This take on native threads sounds overly pessimistic. 99% of backends do fine with the nr of native threads you can easily run in a single process at least on Linux. Not sure what the practical limit is now but 10k used to be no problem many years ago. (eg 100k threads in 2002: https://lkml.iu.edu/hypermail/linux/kernel/0209.2/1153.html https://lkml.iu.edu/hypermail/linux/kernel/0209.2/1153.html .. where the 32-bit 4 GB limit seemed to be the main obstacle)
- traderj0e 6mo ago
  I believe it's fine when you're tuning it. Nowadays people are more likely to have multiple services waiting on each other to handle a user request, each running in containers on random hardware. Even if it's "monolithic," it's probably not really cause they're waiting on external APIs. They don't want to think about tuning for thread pools too.
  - deleted 6mo ago
    [deleted]
  - fulafel 6mo ago
    I can believe some people have implemented misconfigured thread pools, being worse off than with no thread pool at all. But this not an argument that justifies a "multitasking isn't a real choice for backends" position. (Then there's bugs that happen in both asyncio and threaded programs, that stem from various queuing problems in the system, manifesting as work getting backed up in the concurrency layer. You end up needing backpressure in both worlds, thread pool limits are the wrong layer to do it.)

pointlessone 6mo ago

> 3. You don't need to use async Rust. Technically correct, but… Want to build a web app, every more or less popular framework is async. Want to make a web request? High change of async. Database? Very likely async, too. A huge fraction of crates are async. Right now crates.io says there are "54172 reverse dependencies of tokio”. And the page that lists them struggles mightily to load. And that’s only direct dependencies of tokio, no indirect ones, no dependencies on other runtimes, no generic dependents.

andriy_koval 6mo ago
> Want to build a web app, every more or less popular framework is async. I think its the same as Java, Tomcat has some async threadpool inside, they just hide it from you, and your favorite rust framework doesn't, you need manually move your sync logic to Tokio spawn_blocking
- traderj0e 6mo ago
  Java is different. Tomcat's thread pool is the older way. A lot of newer stuff was using something promises-related instead with an event loop. But then recently Java added virtual threads which should obviate the need for that, similar to Go. Rust considered virtual threads but chose against that because it requires a more abstracted runtime like Java and Go have. Great preso on this https://www.youtube.com/watch?v=lJ3NC-R3gSI https://www.youtube.com/watch?v=lJ3NC-R3gSI All the "async" stuff is super poorly named. They mean cooperative multitasking, or I guess "async within a single kernel thread." Yeah multiple kernel threads are asynchronous but "async" doesn't mean that :S
bryanlarsen 6mo ago
And all the popular ones include a synchronous interface you can use instead of the async one. If if they don't, you can wrap your calls in spawn_blocking. You might complain about it pulling in tokio, but that's a very different complaint than having to learn/use async.
- simon_void 6mo ago

tialaramex 6mo ago

> You shouldn't pick a programming language the team doesn't know. That's common sense, not an argument against Rust. Actually if your team doesn't know any suitable languages it could make sense to pick Rust because they will cause far fewer accidental fires in Rust. (Safe) Rust is much more forgiving of "I didn't know that's how computers work" than a language like C or C++ yet it's as close to the metal as they are which may matter for your application. If you're hiring programmers they probably already know some suitable languages which should strongly influence your choice, but if the team's main expertise is not programming they may take to Rust much easier than you'd expect.

nextaccountic 6mo ago

> 5. If you want a batteries-included standard library I agree that you should pick Python or Go instead. But then you should be warned that, among the various http clients Python has in their stdlib, none should be used. Or the many datetime libs in the Python stdlib, they should not be used. LLMs know this by the way and will reach for actual best practices

lenkite 6mo ago

> 3. You don't need to use async Rust. This is like saying you don't need to use a Smartphone. Technically, correct, but then you need to live like a caveman.

worik 6mo ago
I do a lot of real-time audio programming in Rust because it is so expressive and the compiler so helpful But I disagree. I do not use asyc/await for my asynchronous programming in Rust if I get the choice. I have used it extensively in other languages, and when I've had to in Rust, but there are many problems The paradigm itself is not suited to hard real-time programming. An explicit event loop is unbeatable in that case The model does not fit properly in the Rust memory model, and quite often you find yourself using pretzel logic and "magic incantations" to get around that It is synchronous in style, and a footgun as CPU bound operations can block it. The threading support in Rust is superb and for the vast majority of cases a perfect fit Async/await in Rust is a very impressive technical achievement, I am very impressed by how much gets done so efficiently and how well the runtime perform