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

https://symless.com/synergy-blog/we-are-choosing-rust-and-heres-why

by matesz • 4 years ago

4 24 4 years ago

Comevius2• 4 years 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.

3836293648• 4 years 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

Comevius2• 4 years 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• 4 years 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-patton6• 4 years 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• 4 years 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-patton6• 4 years 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.

igouy11• 4 years 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"?

hayley-patton6• 4 years ago

You seem to have excluded the first part of that sentence:

Sure, but they shouldn't repeat misinformation, regardless of if they used it for decision-making or not.

How did you measure "representative"?

Generally, I can't, but the CLBG solutions often rely on FFI, unsafe code, and hand-written SIMD intrinsics, which I don't use very much, and I am not aware of anyone who would for application programming.

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

Related Stories