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.
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
No, a class-based OO language where you need to spend effort crafting build targets by hand or use an IDE to define how to build is not anything close to what I'm talking about. If you think that it's "Rust with GC", I think you're misunderstanding what actually appeals to most people about Rust.
I'd also argue that "runs on all OS" is true, but "is easy to develop without extra work in a cross-platform way" is not. I've never cloned a Rust project and had trouble building out of the box on Linux, but I'd estimate maybe one out of 20 C# projects I clone from Github build for me out of the box with `dotnet build`; the rest either require me manually tweaking the build configs to avoid stuff like hardcoded Windows-style paths or link to system dependencies that don't exist on Linux. I imagine you might argue that this is a property of how people use the language rather than the language itself, but that doesn't really matter from the standpoint of whether it's worth it for developers who don't use Windows to spend any time trying to invest in the ecosystem.
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.
> Why isn't the game industry moving to it then?
The most obvious answer is that requires official support from the platform manufacturers.
> Why isn't the game industry moving to it then? Bc it just cannot compete at volubility with C++, among other things.
I have no opinion regarding rust suitability as a game language, but your answer doesn't sound right.
The actual reason is much simpler. The industry is built on a handful of game engines. Those engines are extended or scripted in C++ or C#. Thus the vast, vast majority of the work force will only have experience with those languages and the entirety of game studios' tooling is built around those. The end.
> The actual reason is much simpler. The industry is built on a handful of game engines
This is a strong reason, but then why in other areas they consider it over C++ for greenfield but it hardly happens in games?
Because retooling and relearning development pipelines (on any level/most teams) for games is a horrifically expensive and time-consuming affair... which are resources not spent on developing any one of the potentially dozen or so games. It's just priorities, alas.
Why isn't the game industry moving to rust?
Someone in that industry can perhaps speak to it, but I have two cents of perspective...
I have helped a young person with gamedev interests try to learn rust (on Windows). They've learned some rust, but the graphics+Windows libraries and primitives to work with are not very good nor straightforward, even with AI assistance. Besides weakness in the gaming/rendering domain, there seemed to be some very real versioning/dependency hell that also didn't help.
It's massively easier to make progress on even just a 2D game with something like GDScript-based Godot (or Unity or...).
It seems like you're comparing "start from scratch in rust" to "start with an existing game engine in some other language". That's not really a fair comparison. there are popular game engines in rust (although i think they're mostly smaller/more niche then something like unity or godot), bevy comes to mind.
I work in gamedev. Here is a simple answer: proprietary gaming platforms have no plans to support Rust.
I don't think "volubility" means what you think it means. The usual meaning of "voluble" is "talkative" (gesprächig if your username is accurate). I'm not quite sure what you're going for here or in an earlier comment, but suspect it's something more like "ergonomic", i.e. the language being easy/natural to write and not getting in your way.
> I don't think "volubility"
Indeed I got it wrong bc I translated from spanish and it seems to be a false friend. The word I meant is "malleable".
> 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.
thanks for the pointer, I will check them out
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.