| ▲ | simpaticoder 4 days ago | |||||||||||||||||||||||||
>reduced maintenance long-tail I'd like to hear more about that. I'm also curious what makes Rust particularly suited to "API-first" backends. My understanding of the language is that it's concurrency primitives are excellent but difficult to learn and it's gc-less runtime. | ||||||||||||||||||||||||||
| ▲ | echelon 4 days ago | parent [-] | |||||||||||||||||||||||||
> it's concurrency primitives are excellent but difficult to learn They're actually incredibly easy to learn if your software paradigm is the request-response flow. The borrow checker might kill your productivity if you're writing large, connected, multi-threaded data structures, but that simply isn't the nature of 90% of services. If you want to keep around global state (db connectors, in-memory caches, etc.) Arc<Mutex<T>> is a simple recipe that works for most shared objects. It's dead simple. You can think of Rust with Axum/Actix as a drop-in replacement for Go or Python/Flask. With the added benefits of (1) no GC / bare metal performance, (2) much lower defect rate as a consequence of the language ergonomics, (3) run it and forget it - no GC tuning, very simple scaling. Rust has effectively made writing with the performance of C++ feel like writing Ruby, but with unparalleled low defect rates and safety on account of the type system. | ||||||||||||||||||||||||||
| ||||||||||||||||||||||||||