4 ms·

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

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.

varjag 1mo ago
Calculate ackermann(4,4), make no mistakes.
bigfishrunning 1mo ago
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)
- edukite 1mo ago
  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.
  - bigfishrunning 1mo ago
    I do think rust works there (as you clearly know), i just like Go's ergonomics for that exact task better, that's all.
- bryanlarsen 1mo ago
  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.
  - germandiago 1mo ago
    > 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...
- vablings 1mo ago
  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
  - germandiago 1mo ago
    > 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.
    - mrec 1mo ago
      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.
- larme 1mo ago
  GPU programming?
  - bigfishrunning 1mo ago
    Yeah, you're still stuck with DSL's there, but not for lack of trying https://github.com/NVlabs/cuda-oxide https://github.com/NVlabs/cuda-oxide
  - the__alchemist 1mo ago
    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.
    - larme 1mo ago
      thanks for the pointer, I will check them out
mgaunard 1mo ago
All those applications area sensitive to asynchronous programming.
- okanat 1mo ago
  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.
jdcasale 1mo ago
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.
- m00dy 1mo ago
  yeah, locks are expensive.
- the__alchemist 1mo ago
  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: - Dedicated hardware via DMA, multiple cores/MCUs etc - Thread pools (e.g rayon) - GPU - SIMD - Atomics - Interrupts and their ISRs - Event loops - std::sync Thread and MPSC (My Std rust default for not blocking the GUI etc)
  - surajrmal 1mo ago
    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).
- germandiago 1mo ago
  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).
Verdex 1mo ago
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.
- saghm 1mo ago
  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).
  - Surac 1mo ago
    a rust with gc is already available. it is called c# and runs on all os nowerdays
    - saghm 1mo ago
      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.
mook 1mo ago
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.
- ogoffart 1mo ago
  Slint ?
- the__alchemist 1mo ago
  EGUI. Note: You ask different people, and they will all have their favorite tool kits. GPUI is very promising but new. There are a pile of others people will vouch for like Druid, Tauri (Electron-like but faster?) Slint (As the sibling poster pointed out), Iced, Qt bindings etc. I am not sure about native Windows etc bindings: I recognize that OS-native things like that are the most performant, but for me it's worth it to make my programs cross-platform and not worry about OS-specific things. Note: EGUI is an immediate mode GUI, which isn't for all applications. But it has never limited me, and have written some complex UIs with integrated 3D etc.
- okanat 1mo ago
  > 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? If your goal is "delivering applications to only well-sighted people who can handle non-native and buggy UI", yes iced, EGUI, gpui exist. But as you can guess they are years behind Qt where you have quite the professional toolkit and properly implemented accessibility features (with a lot of bugs and horrible API because Qt). The only foolproof way of having truly professional software is still the same: have N different, very-well integrated UI implementations (like Adobe does, $$$ in developer or agent fees) or use a Web browser aka Electron. With Rust you can use Win32 or WinUI3. Both are provided by Microsoft-developed crate windows-rs.

varjag 1mo ago

Calculate ackermann(4,4), make no mistakes.

bigfishrunning 1mo ago

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)

edukite 1mo ago
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.
- bigfishrunning 1mo ago
  I do think rust works there (as you clearly know), i just like Go's ergonomics for that exact task better, that's all.
bryanlarsen 1mo ago
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.
- germandiago 1mo ago
  > 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...
vablings 1mo ago
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
- germandiago 1mo ago
  > 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.
  - mrec 1mo ago
    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.
larme 1mo ago
GPU programming?
- bigfishrunning 1mo ago
  Yeah, you're still stuck with DSL's there, but not for lack of trying https://github.com/NVlabs/cuda-oxide https://github.com/NVlabs/cuda-oxide
- the__alchemist 1mo ago
  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.
  - larme 1mo ago
    thanks for the pointer, I will check them out

mgaunard 1mo ago

All those applications area sensitive to asynchronous programming.

okanat 1mo ago
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.

jdcasale 1mo ago

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.

m00dy 1mo ago
yeah, locks are expensive.
the__alchemist 1mo ago
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: - Dedicated hardware via DMA, multiple cores/MCUs etc - Thread pools (e.g rayon) - GPU - SIMD - Atomics - Interrupts and their ISRs - Event loops - std::sync Thread and MPSC (My Std rust default for not blocking the GUI etc)
- surajrmal 1mo ago
  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).
germandiago 1mo ago
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).

Verdex 1mo ago

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.

saghm 1mo ago
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).
- Surac 1mo ago
  a rust with gc is already available. it is called c# and runs on all os nowerdays
  - saghm 1mo ago
    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.

mook 1mo ago

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.

ogoffart 1mo ago
Slint ?
the__alchemist 1mo ago
EGUI. Note: You ask different people, and they will all have their favorite tool kits. GPUI is very promising but new. There are a pile of others people will vouch for like Druid, Tauri (Electron-like but faster?) Slint (As the sibling poster pointed out), Iced, Qt bindings etc. I am not sure about native Windows etc bindings: I recognize that OS-native things like that are the most performant, but for me it's worth it to make my programs cross-platform and not worry about OS-specific things. Note: EGUI is an immediate mode GUI, which isn't for all applications. But it has never limited me, and have written some complex UIs with integrated 3D etc.
okanat 1mo ago
> 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? If your goal is "delivering applications to only well-sighted people who can handle non-native and buggy UI", yes iced, EGUI, gpui exist. But as you can guess they are years behind Qt where you have quite the professional toolkit and properly implemented accessibility features (with a lot of bugs and horrible API because Qt). The only foolproof way of having truly professional software is still the same: have N different, very-well integrated UI implementations (like Adobe does, $$$ in developer or agent fees) or use a Web browser aka Electron. With Rust you can use Win32 or WinUI3. Both are provided by Microsoft-developed crate windows-rs.