Comment by the__alchemist
21 hours ago
With certain rough edges like complex traits and Async aside, rust is an S-tier lang in several domains. Of interest:
- Embedded
- PC desktop applications
- Computationally-intense scientific programming. (Chem, structural bio etc)
- OSes, drivers etc
- High-performance tasks in general. CPU, GPU, etc.
It's not a memory-safety one-trick pony; it's a well-rounded lang which has learned from its predecessors.
Yeah I'd written some rust ~ 10 years ago when the language was very different and that led me to believe that it was a 'great within it's niche' sort of thing for a long time, but after spending the last couple of years with it as a daily driver I think it's a pretty great general-purpose language.
The one really common gotcha with rust is that when trying to write concurrent code, newbies tend to throw Arc<RwLock<T>> goo around everywhere, and they end up with the world's shittiest garbage collector.
jdcasale you are right that Arc<RwLock<T>> is a code smell but I would take that a bit further that locking immutable data is even more of a smell. The real bad guy in this case is the RwLock not Arc. For anything that you hydrated once and never mutate you do not need the RwLock. Arc just clones the pointer so it is safe to share for concurrent reads so something like Arc<T> is fine and if you need initialization locking then LazyLock<Arc<T>> lets you lock the initialization but then everything else is just a pointer copy.
I hit this recently while building a url unfurl social card renderer for a project which ended up being something like LazyLock<Arc<Database>>
Give me something like boost.multiindex for Rust, and maybe I could think of trying some experiments.
I think C++ is an excellent choice due to its volubility actually. Bc when I want safety, I mostly have it (but I have done a lot of C++, admittedly).
It is interesting to see the different patterns used due to different cases and tastes. For example, my concurrency patterns rarely use locks, and are instead usually one of:
Most of it comes down to avoiding shared data. Unfortunately it requires forethought to do that well. There are also many cases where you do want to share data for optimal performance as other options are ultimately too heavyweight.
Also worth noting that an event loop by itself doesn't give you serialization by itself, it can just allow you to gain concurrency without parallelism. You still need some form of serialization by way of something like actors (or async locks).
yeah, locks are expensive.
Yeah, I primarily use rust because it's got algebraic data types, pattern matching, and cargo.
If ocaml had a cargo like experience, then I would migrate there.
I've said for a while that the main reason Rust is so popular is that it has a lot of effort put into the developer experience, with the low-level safety honestly not being all that important to a large portion of the programmers who would be fine with a garbage collector. I used to think that maybe a "Rust with garbage collector" would come along, but at this point it honestly seems more likely that an optional garbage collector would be added to Rust (probably with just the primitives in std and leaving it up to libraries to provide a more full experience, like with async runtimes).
a rust with gc is already available. it is called c# and runs on all os nowerdays
1 reply →
All those applications area sensitive to asynchronous programming.
Rust's async can be very lightweight depending on the runtime implementation. tokio and embassy are both runtimes but former is a throughput-optimized heavily multi-threaded while latter is a simple cooperative multitasking for embedded. We use both at my day job. Even 64k flash and 16k ram is enough for embassy.
Oh, its good at doing desktop applications these days? Which GUI libraries are good these days? Some native win32 binding? Are there good equivalents for Qt?
I'm interested in getting back to native application development; the job is on Electron right now and it's… meh.
Slint ?
Honestly, the only domains that I think rust isn't suitable for are:
* rapid-prototyping, where javascript and python are still top-tier
* adding scriptability to existing programs, where lua and scheme (and python) are popular
* Server-side API implementation (rust is usable here, but I think Go fits the slot better)
Rapid prototyping is almost a meme at this point. If you are hand rolling code old school, you will waste more time shoehorning JavaScript and python semantics into rust code and end up with worse quality that takes more time rather than writing it from rust.
People did this a lot when rust was not as popular but there are plenty of very good rust programmers now who understand the language and can make programs that are significantly more performance for a marginal development cost.
Script ability can also be done in rust, Notably Zed (rust ide/vscode whatevers) is written in rust, and all the plugins are compiled to WASM, sandboxed and loaded.
Go is pretty nice for server-side API but if your application share types between boundries then rust is better
> Rapid prototyping is almost a meme at this point
> People did this a lot when rust was not as popular but there are plenty of very good rust programmers now who understand the language and can make programs that are significantly more performance for a marginal development cost.
Why isn't the game industry moving to it then? Bc it just cannot compete at volubility with C++, among other things. Yes, you can have skilled people, but the borrow checker is still there and that is an anti-change-me-fast fact of life. I think things like sending batches of info to the GPU in casted ways, alignment, etc. all go against safety naturally but this is fundamentally what needs to be done anyway when transfering data to the GPU, so adding a layer of safety for the sake of doing it to notice that your data-oriented pipeline has to suddenly change its shape would mean repeating work...
Namely, Rust is just not good at this. Rust is good if you can replicate a safe layer that is very reusable every time (when interacting with unsafe) or when you do not need unsafe at all or hardly, where you can take advantage of its safety fully.
Also, there are certain very tweaked data structures such as Boost.MultiIndex or linked lists with intrusive hooks and others that are not easy at all in Rust and they do have value in some situations. I had some of this in some telecommunication systems before.
9 replies →
> Script ability can also be done in rust, > Notably Zed ... the plugins are compiled to WASM, sandboxed and loaded.
It notably doesn't have any plugins relevant in this scripting context. It only has themes/language syntax/servers, nothing about actual editing
No, rapid development is essential when you're making games. It's not a "solved science", sure you can code something up and slap some programmer art on it then ship it but you very well know that won't be usable. You need to iterate on the gameplay and gamefeel a lot if you want something more than slop.
One way is sure the native language + embedded scripting language combo but that's got the trap of impedance mismatch i.e. you spend all your time making engine not game then it overruns. But in any case having a way to iterate fast is a hidden productivity superpower, look at how many game studios have Live++ licences on their webpage;)
Rust is great for rapid protoyping, IMO. Or, at least the subset of rapid prototyping that involves massive rewrites to try out different approaches. Rust has a saying "if it compiles, it works", the compiler really ensures that you don't miss something when doing that rewrite.
> Rust is great for rapid protoyping, IMO
If you have to iterate a lot the shape of your code... no, it is not any good at this...
My employer company go through JavaScript, Java, Golang and at the end landed on Rust for srver side and don't want to change anything. Everything is Rust now, regardless of traffic.
I don't know why you think it's only usable but this is your right.
I do think rust works there (as you clearly know), i just like Go's ergonomics for that exact task better, that's all.
GPU programming?
Rust is great for GPU programming, or at least for writing the Host (CPU) side without friction. WGPU or FFI-based Vulkan etc bindings for graphics. Cudarc + normal Cuda kernels for general purpose compute. I bring these up as they're easy-to-use and mature.
1 reply →
Yeah, you're still stuck with DSL's there, but not for lack of trying https://github.com/NVlabs/cuda-oxide
Calculate ackermann(4,4), make no mistakes.