6 ms·

> higher developer productivity Where have you been the past 5 years? Rust developers are insanely productive. Can we put this myth to rest already? Rust bein

by brink 2y ago

> higher developer productivity Where have you been the past 5 years? Rust developers are insanely productive. Can we put this myth to rest already? Rust being an "unproductive language" is thoroughly dis-proven.

hello_moto 2y ago
Rust is the silver bullet we all been waiting for?
- ramon156 2y ago
  No, that's the other end of the stick. Its en par with other languages
  - hello_moto 2y ago
    Well, put any language against Rust and Rustaceans would argue Rust is better than those languages so ... Silver bullet no?
    - chasd00 2y ago
      If the word “Rustaceans” is actually in common use then rust loses by default.
neonsunset 2y ago
There are domains where C# (and F#) productivity stems from similar reasons why writing a game in something that isn't Rust might be more productive without even sacrificing performance (or, at least, not to the drastic extent). I can give you an example: var number = 0; var delay = Task.Delay(1000); for (var i = 0; i < 10; i++) { Task.Run(() => { while (!delay.IsCompleted) { Interlocked.Increment(ref number); } }); } await delay; How would you write this idiomatically in Rust without using unsafe? To avoid misunderstanding, I think Rust is a great language and even if you are a C# developer who does not plan to actively use it, learning Rust is of great benefit still because it forces you to tackle the concepts that implicitly underpin C#/F# in an explicit way.
- pdimitar 2y ago
  > How would you write this idiomatically in Rust without using unsafe? Channels and selects. It's trivial.
  - neonsunset 2y ago
    Please post a snippet.
    - brink 2y ago
      use std::{ sync::{ Arc, atomic::{AtomicBool, AtomicUsize, Ordering}, }, time::Duration, }; fn main() { let num = Arc::new(AtomicUsize::new(0)); let finished = Arc::new(AtomicBool::new(false)); for _ in 0..10 { std::thread::spawn({ let num = num.clone(); let finished = finished.clone(); move || { while !finished.load(Ordering::SeqCst) { num.fetch_add(1, Ordering::SeqCst); } } }); } std::thread::sleep(Duration::from_millis(1000)); finished.store(true, Ordering::SeqCst); }
      - neonsunset 2y ago
        What if we want to avoid explicitly spawning threads and blocking the current one every time we do this? Task.Run does not create a new thread besides those that are already in the threadpool (which can auto-scale, sure, but you get the idea, assuming the use of Tokio here).
        brink 2y ago
        What you're asking for is thread parking. Use tokio for that, it's still trivial.
        neonsunset 2y ago
        I was implying that yes, while it is doable, it comes at 5x cognitive cost because of micromanagement it requires. This is somewhat doctored example but the "decision fatigue" that comes with writing Rust is very real. You write C# code, like in the example above, quickly without having to ponder on how you should approach it and move on to other parts of the application while in Rust there's a good chance you will be forced to deal with it in a much stricter way. It's less so of an issue in regular code but the moment you touch async - something that .NET's task and state machine abstractions solve on your behalf you will be forced to deal with by hand. This is, obviously, a tradeoff. There is no way for .NET to use async to implement bare metal cooperative multi-tasking, while it is very real and highly impressive ability of Rust. But you don't always need that, and C# offers an ability to compete with Rust and C++ in performance in critical paths when you need to sit down and optimize it unmatched by other languages of "similar" class (e.g. Java, Go). At the end of the day, both languages have domains they are strong at. C# suffers from design decisions that it cannot walk back and subpar developer culture (and poor program architecture preferences), Rust suffers from being abrasive in some scenarios and overly ceremonious in others. But other than that both provide excellent sets of tradeoffs. In 2025, we're spoiled with choice when it comes to performant memory-safe programming languages.
homebrewer 2y ago
Even when it's used by mediocre developers, which is probably more than 90% of us, myself very much included? All I've been seeing is Rust being used by very enthusiastic and/or talented developers, who will be productive in any language.
lmm 2y ago
> Rust developers are insanely productive. If your baseline is a language that is missing some features that were in standard ML, sure. If you were already using OCaml or F#, Rust doesn't make you any more productive. If you were already using Haskell or Scala, Rust's lack of HKT will actively slow you down.
legulere 2y ago
Longer compile times prolong iterative programming processes and having to take care of memory management through linear types adds restrictions on how you can express code and leads to additional mental burden. This can be part of a trade-off, where you get things in return (no runtime/gc), but your typical web app I don't see much advantages.

by brink 2y ago

hello_moto 2y ago

Rust is the silver bullet we all been waiting for?

ramon156 2y ago
No, that's the other end of the stick. Its en par with other languages
- hello_moto 2y ago
  Well, put any language against Rust and Rustaceans would argue Rust is better than those languages so ... Silver bullet no?
  - chasd00 2y ago
    If the word “Rustaceans” is actually in common use then rust loses by default.

neonsunset 2y ago

There are domains where C# (and F#) productivity stems from similar reasons why writing a game in something that isn't Rust might be more productive without even sacrificing performance (or, at least, not to the drastic extent). I can give you an example: var number = 0; var delay = Task.Delay(1000); for (var i = 0; i < 10; i++) { Task.Run(() => { while (!delay.IsCompleted) { Interlocked.Increment(ref number); } }); } await delay; How would you write this idiomatically in Rust without using unsafe? To avoid misunderstanding, I think Rust is a great language and even if you are a C# developer who does not plan to actively use it, learning Rust is of great benefit still because it forces you to tackle the concepts that implicitly underpin C#/F# in an explicit way.

pdimitar 2y ago
> How would you write this idiomatically in Rust without using unsafe? Channels and selects. It's trivial.
- neonsunset 2y ago
  Please post a snippet.
  - brink 2y ago
    use std::{ sync::{ Arc, atomic::{AtomicBool, AtomicUsize, Ordering}, }, time::Duration, }; fn main() { let num = Arc::new(AtomicUsize::new(0)); let finished = Arc::new(AtomicBool::new(false)); for _ in 0..10 { std::thread::spawn({ let num = num.clone(); let finished = finished.clone(); move || { while !finished.load(Ordering::SeqCst) { num.fetch_add(1, Ordering::SeqCst); } } }); } std::thread::sleep(Duration::from_millis(1000)); finished.store(true, Ordering::SeqCst); }
    - neonsunset 2y ago
      What if we want to avoid explicitly spawning threads and blocking the current one every time we do this? Task.Run does not create a new thread besides those that are already in the threadpool (which can auto-scale, sure, but you get the idea, assuming the use of Tokio here).
      - brink 2y ago
        What you're asking for is thread parking. Use tokio for that, it's still trivial.
        neonsunset 2y ago
        I was implying that yes, while it is doable, it comes at 5x cognitive cost because of micromanagement it requires. This is somewhat doctored example but the "decision fatigue" that comes with writing Rust is very real. You write C# code, like in the example above, quickly without having to ponder on how you should approach it and move on to other parts of the application while in Rust there's a good chance you will be forced to deal with it in a much stricter way. It's less so of an issue in regular code but the moment you touch async - something that .NET's task and state machine abstractions solve on your behalf you will be forced to deal with by hand. This is, obviously, a tradeoff. There is no way for .NET to use async to implement bare metal cooperative multi-tasking, while it is very real and highly impressive ability of Rust. But you don't always need that, and C# offers an ability to compete with Rust and C++ in performance in critical paths when you need to sit down and optimize it unmatched by other languages of "similar" class (e.g. Java, Go). At the end of the day, both languages have domains they are strong at. C# suffers from design decisions that it cannot walk back and subpar developer culture (and poor program architecture preferences), Rust suffers from being abrasive in some scenarios and overly ceremonious in others. But other than that both provide excellent sets of tradeoffs. In 2025, we're spoiled with choice when it comes to performant memory-safe programming languages.

homebrewer 2y ago

Even when it's used by mediocre developers, which is probably more than 90% of us, myself very much included? All I've been seeing is Rust being used by very enthusiastic and/or talented developers, who will be productive in any language.

lmm 2y ago

> Rust developers are insanely productive. If your baseline is a language that is missing some features that were in standard ML, sure. If you were already using OCaml or F#, Rust doesn't make you any more productive. If you were already using Haskell or Scala, Rust's lack of HKT will actively slow you down.

legulere 2y ago

Longer compile times prolong iterative programming processes and having to take care of memory management through linear types adds restrictions on how you can express code and leads to additional mental burden. This can be part of a trade-off, where you get things in return (no runtime/gc), but your typical web app I don't see much advantages.