7 ms·

We're choosing Rust, and not Go, C++, or Node.js (Feb 2022)

4 points by matesz 4y ago

Comevius 4y ago
I'm betting that hiring is harder for Rust. The post gives Go 3/5 for stability, and Rust gets 5/5 for it's memory safety benefits. The post says that memory safety was the primary deciding factor. Hello? Go and Node.js are garbage collected. They are trivially memory safe. Rust's borrow checker is helpful, but it does not make memory safety trivial. The post concludes that Rust attracts more transgender people than other communities. Even if that's true, how is that going to help the business? It's not like they should be hiring based on gender. Although Rust + Electron works, Dart + Flutter would trivially beat this particular combination in developer convenience and productivity, and also user experience.
- tronono 4y ago
- deleted 4y ago
  [deleted]
- 3836293648 4y ago
  You missed the point about leaks. It's not a part of Rust's usual pitch, but they mention it here as a major point, given how they're a background service that can run for months on end
  - Comevius 4y ago
    Rust gives you freedom in designing a perfect long-running service, but if you are not doing it from scratch you will be relying on an async runtime like Tokio. Go's flawed memory model nonwithstanding this use case is simple enough to be able to avoid or recover from races and leaks with less work. When concurrency is important and you are not designing lock-free algorithms I would sooner go with Erlang or Elixir than Rust. If you are designing concurrent algorithms with liveness guarantees you are in the TLA+, fighting the C11 memory model, unsafe Rust territory.
phibz 4y ago
Why does synergy need nodejs and electron for configuration? This seems overkill for something so simple. Good luck with your rewrite but can we have a return to the simplicity of synergy 1?
hayley-patton 4y ago
> Code written in Node.js and Go could be made memory-safe with enough work, but they're both GC based, which inevitably leads to engineers easily missing memory safety issues, unconsciously relying on the language runtime to clean up after them. Which? You can't use-after-free or double-free if you can't free. > Interestingly, it turns out that using Rust is more energy efficient than C++ (in some cases) according to a study in 2017 by the University of Minho. It's about three times greener than Go, too. TypeScript is apparently far more energy-hungry (and we're not likely to use pure JavaScript). The third sentence should ring alarm bells in the head of the author, over what would be going on for a language which generates "similar enough" JS code to be slower than JS. I suspect it's not the language, moreso since the sole source of programs for that study was the Computer Language Benchmarks Game, which is hardly representative of typical code.
- FreeFull 4y ago
  I'm guessing they're conflating memory safety with not having memory leaks. Of course, Rust doesn't prevent memory leaks either, although they might be less likely? I'm not sure how often Node.js codebases keep around memory allocations that aren't actually needed any more.
  - hayley-patton 4y ago
    I suspect the most common example (IME) of leak in garbage collected systems (putting more and more things in a collection that you never use again) isn't notably harder with explicit or Rust memory management.
- igouy 4y ago
  > The third sentence should ring alarm bells in the head of the author… You seem to have excluded the first part of that sentence: "Not that it had anything to do with our decision making, but…" And "TypeScript is apparently far more energy-hungry" is probably intended to mean "far more energy-hungry" than C++ or Go. > … hardly representative of typical code… How did you measure "representative"?

4 points by matesz 4y ago

I'm betting that hiring is harder for Rust. The post gives Go 3/5 for stability, and Rust gets 5/5 for it's memory safety benefits. The post says that memory safety was the primary deciding factor. Hello? Go and Node.js are garbage collected. They are trivially memory safe. Rust's borrow checker is helpful, but it does not make memory safety trivial. The post concludes that Rust attracts more transgender people than other communities. Even if that's true, how is that going to help the business? It's not like they should be hiring based on gender. Although Rust + Electron works, Dart + Flutter would trivially beat this particular combination in developer convenience and productivity, and also user experience.

tronono 4y ago
deleted 4y ago
[deleted]
3836293648 4y ago
You missed the point about leaks. It's not a part of Rust's usual pitch, but they mention it here as a major point, given how they're a background service that can run for months on end
- Comevius 4y ago
  Rust gives you freedom in designing a perfect long-running service, but if you are not doing it from scratch you will be relying on an async runtime like Tokio. Go's flawed memory model nonwithstanding this use case is simple enough to be able to avoid or recover from races and leaks with less work. When concurrency is important and you are not designing lock-free algorithms I would sooner go with Erlang or Elixir than Rust. If you are designing concurrent algorithms with liveness guarantees you are in the TLA+, fighting the C11 memory model, unsafe Rust territory.

phibz 4y ago

Why does synergy need nodejs and electron for configuration? This seems overkill for something so simple. Good luck with your rewrite but can we have a return to the simplicity of synergy 1?

hayley-patton 4y ago

> Code written in Node.js and Go could be made memory-safe with enough work, but they're both GC based, which inevitably leads to engineers easily missing memory safety issues, unconsciously relying on the language runtime to clean up after them. Which? You can't use-after-free or double-free if you can't free. > Interestingly, it turns out that using Rust is more energy efficient than C++ (in some cases) according to a study in 2017 by the University of Minho. It's about three times greener than Go, too. TypeScript is apparently far more energy-hungry (and we're not likely to use pure JavaScript). The third sentence should ring alarm bells in the head of the author, over what would be going on for a language which generates "similar enough" JS code to be slower than JS. I suspect it's not the language, moreso since the sole source of programs for that study was the Computer Language Benchmarks Game, which is hardly representative of typical code.

FreeFull 4y ago
I'm guessing they're conflating memory safety with not having memory leaks. Of course, Rust doesn't prevent memory leaks either, although they might be less likely? I'm not sure how often Node.js codebases keep around memory allocations that aren't actually needed any more.
- hayley-patton 4y ago
  I suspect the most common example (IME) of leak in garbage collected systems (putting more and more things in a collection that you never use again) isn't notably harder with explicit or Rust memory management.
igouy 4y ago
> The third sentence should ring alarm bells in the head of the author… You seem to have excluded the first part of that sentence: "Not that it had anything to do with our decision making, but…" And "TypeScript is apparently far more energy-hungry" is probably intended to mean "far more energy-hungry" than C++ or Go. > … hardly representative of typical code… How did you measure "representative"?