[switchbak]

Backend logic is not necessarily straightforward, that depends completely on your domain.

Each request uses a single thread? In the stuff I'm working on we often orchestrate asynchronous operations across many different systems, that alone would involve a lot of parallelism and concurrency. We lean heavily into functional code with immutable data, but we're not writing a systems level program.

If you're doing much beyond simple crud, I imagine you're going to want a lot of what you're describing fairly quickly.

[ozzythecat]

> If you're doing much beyond simple crud, I imagine you're going to want a lot of what you're describing fairly quickly.

There are different models for asynchronous execution across different systems. Even then, Rust isn’t a silver bullet.

A request can be scoped to a single thread, and then messages can passed across systems (queues, pubsub, etc), stored to a database, etc etc.

Not having concurrency within a single process doesn’t mean someone is doing simple CRUD, unless you’ve mistaken Facebook.com, Twitter, and Amazon retail website to all be simple CRUD applications.

Rust seems like a solution for your very specific use case, or it’s better suited for C++ and systems programming scenarios.

The borrow checker is a pain in the ass to use. Presenting Rust as silver bullet and ignoring its cost is misguided and near sighted at best. It’s not just Rust but saying <X> is the perfect solution is generally wrong. Every thing has a cost.

[switchbak]

I'm not advocating for Rust (not the OP), and I would say Rust is never a silver bullet any time. It might make sense in context for a given problem and team, but there's a lot to go into such a decision.

I'm saying that once you go beyond simple needs, you're going to want to orchestrate async in a fairly sophisticated fashion. That might be in a Node-style architecture, old-school Java with real threads (probably pooled), new-school Java (ie: project Loom), Go, etc.

"How often are folks writing server side code where they need to pass objects across thread boundaries" - In the JVM land this is very common. Also true in many other environments as well (Erlang, Go, etc). The fact that it isn't true in your tooling of choice doesn't make it universal.

"Back end logic is usually straightforward. Each request uses a single thread" - Again, both of those statements don't ring true to me. Yes, they do in some environments, but certainly not all. Especially the last statement hasn't been true in the stacks I use for over a decade now.

Keep in mind I was also talking about parallelism here, some folks want to do some compute in addition to gluing together API calls.

"Not having concurrency within a single process doesn’t mean someone is doing simple CRUD, unless you’ve mistaken Facebook.com, Twitter, and Amazon retail website to all be simple CRUD applications.". - You're suggesting that none of those systems support orchestration of concurrent calls? Please explain in detail.

"Rust seems like a solution for your very specific use case" - It doesn't actually. Our problems are not system level issues (as I mentioned), and doing manual memory management is an overhead we'd gladly let a GC handle, same with the borrow checker. We don't use Rust, I didn't advocate using Rust. I was responding to your comment about backend code being single threaded and straightforward.

"Presenting Rust as silver bullet and ignoring its cost" - Who did that exactly? - And who said "<X> is the perfect solution"?

Your tendency to create strawman arguments is a bit much.

[Edited for elaboration on not using Rust, not proposing to use Rust]