30 ms·

We're choosing Rust, and not Go, C++, or Node.js

18 points by lukastyrychtr 5y ago

IshKebab 5y ago
> 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. That "study" has a lot to answer for!
axiosgunnar 5y ago
Why wasn't Java considered?
- bajsejohannes 5y ago
  I don't know, but it does seem self-contradictory to say it wasn't considered, because there's an implicit consideration in that, even if it's short lived. SNOBOL4 on the other hand, was probably not considered at all.
- cesaref 5y ago
  Why wasn't .net considered? The whole article is very weird, and there is little to learn from it. Wind on till they've actually made the port, and have run it for some time and then there will be some interesting lessons learnt, gazing into my crystal ball it will be somethong like 'turned out to be harder and take longer than we thought, but the result is good'
  - axiosgunnar 5y ago
    They have one short sentence plonked in there saying "Java was not considered". They didn't give a reason why. They didn't mention .net anywhere.
    - EdwardDiego 5y ago
      But that's the point. Why was it only Rust and Go when memory safety is a big deal and also can the author please show me on the doll where the bad Java hurt him?
- bullen 5y ago
  Because it would be the best choice and it's old. You cannot sell C/Java. Computers are now reaching the maturity lightbulbs had when they artificially limited the burn time to 1000 hours. Personally I going back to C and JavaSE/J2ME on Rasperry 4/Pico.
- wrnr 5y ago
  I would like to apologise on behest of the Rust community, we are not all like this. Java would have been a fine choice.
- koufatz 5y ago
  Java or Kotlin seems actually a very good compromise. Very good performance and also actually in the top of the list of the energy efficient languages. Plus you can find a lot of more devs using JVM tech stack.
- EdwardDiego 5y ago
  Obviously the well known habit of JVM applications to leak memory. /s (Although being fair, I've met some Java libs that leak memory (looking at you, Couchbase), usually via poor usage of byte buffers. But Rust doesn't let you use unsafe code constructs, so it'll be fine. I guess I need another /s now.)
bigmek123 5y ago
They are citing the "rust is more green than go" article debunked by Russ Cox: https://twitter.com/_rsc/status/1496352325157457922 https://twitter.com/_rsc/status/1496352325157457922, also the excel comparison table they are showing is _extremely_ biased towards Rust - training for Rust 3/5 and Go 4/5? Dev time: Rust 2/5, Go 3/5? Really?
- rob74 5y ago
  No idea why you're getting downvoted, but I agree that Russ Cox' criticism of the AWS article is justified, amongst others because of the 2017 (!) Portuguese study it cites - a scientific study that ranks the "energy efficiency" of programming languages based on Computer Language Benchmark Games - really? I mean, how about looking at some real world applications instead?
  - igouy 5y ago
    What explanation is given in that 2017 paper for selecting programs from the benchmarks game? ---- Meanwhile we can do better than "every C program is a valid C++ program, so C++ can’t lose" defensiveness. Look at the data tables published with that 2017 paper: https://sites.google.com/view/energy-efficiency-languages/results https://sites.google.com/view/energy-efficiency-languages/re... There's an order of magnitude difference between the times of the selected C and C++ programs, for one thing — regex-redux. That is enough to explain all of the difference between the C and C++ time measurements shown in "Table 4. Normalized global results". (Seems like an outlier which could have been excluded.)
rob74 5y ago
Er... > 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 And here I was (maybe naively) thinking that a garbage collector ensures memory safety? Unless they mean memory leaks (of the kind where memory is allocated and can't be freed by the GC, but is also not used?!). But that should be relatively easy to catch with a profiler? Maybe some more explanation would have been in order here... More generally, glad to see Go got 80% compared to Rust's 90% - just hoping they weighed their priorities correctly, otherwise who knows, with such a small difference Go might have come out on top...
- cillian64 5y ago
  GC protects you against use-after-free memory safety issues but doesn’t help with concurrency issues, i.e. one thread reading from a shared structure at the same time as another writing to it.
- nkozyra 5y ago
  I wonder how much work they estimated it would take to make Go as "memory safe" as Rust. I feel like the body of the post could have been "we just want to use Rust, ok??!"
  - EdwardDiego 5y ago
    Yeah, I feel like you could just rephrase Jim Jefferie's classic comment on gun control[0] and replace this entire blog post with "fuck off, I like Rust". [0]https://youtu.be/0rR9IaXH1M0?t=107 https://youtu.be/0rR9IaXH1M0?t=107
- MaulingMonkey 5y ago
  I agree that leaking memory usually gets its own category, rather than being shoveled under the "memory safety". That said, I'll play a bit of devil's advocate: You can still have use-after-free bugs in a GCed language. A trivial example is calling methods on a closed/disposed/??? socket, file, or other handle. They don't result in the arbitrary memory corruption I'd typically consider a "real" memory safety issue, but they do result in bugs. In some cases, debug allocators and tools like address sanitizer can even surface such mistakes more quickly than similar code in a GCed languages. (Of course, in other cases, mistakes with non-GC memory cause bugs that are an absolute nightmare to repro and debug.) More troubling is native interop, which I'd assume something like Synergy will definitely need to do plenty of to capture/forward keyboard/mouse input, bypassing the traditional window focus reliant input stack that the language may pre-provide safe bindings for. Failure to pin, or unpinning too early during an asyncronous operation, can cause your GC-allocated memory to shift around during GC compaction when native code was expecting it to remain in one place. The GC can also potentially outright reap GC-allocated objects that native code was using. I remember reading of nasty heisenbugs from Ruby C extensions forgetting to use RB_GC_GUARD to ensure VALUEs remain on the stack, where the GC can find them, when scanning for GC roots that keep objects alive - as an example. Well, you can write similar bugs in non-GCed languages, but GCed languages aren't immune from these concerns. I've even bluescreened fairly modern Windows, with C# code, by sufficiently misusing SlimDX! EDIT: links to the aforementioned reading: http://timetobleed.com/the-broken-promises-of-mrireeyarv/ http://timetobleed.com/the-broken-promises-of-mrireeyarv/ https://news.ycombinator.com/item?id=2730286 https://news.ycombinator.com/item?id=2730286
mohanmcgeek 5y ago
The title itself is inviting a language flamewar and the body of the article is extremely dubious
- deleted 5y ago
  [deleted]
rob74 5y ago
Also: > But, existing Rust developers of course have a different view. "I find rust far easier than C++ to work with." I bet it's far easier than C++ - then again, almost every programming language on this planet is far easier than C++...
alophawen 5y ago
The article is laid out in a way that seem to only justify Rust as their choice. Some points is plain out silly, like the spreadsheet with fully made up numbers such as Stability Rust 5/5 Stability Go 3/5 The Recruitment points is even more biased, given the reality where you probably will find close to 50x more applicants familiar with Go versus Rust.
- thraxil 5y ago
  Yeah, I'm willing to give Rust the edge on stability and correctness, but I'd probably put Go at more like 4/5. It's certainly possible to make Go programs that crash, but it's also really easy to make them incredibly stable. I don't think they're wrong for picking Rust. I really like Rust and it's probably a great fit for them. There's a good chance I'd have picked Rust for the same project. Based on their criteria, I'd probably see it as a bit more of a coin toss between Rust and Go though and I suspect they just picked the one they wanted. And that's totally fine.
breakfastduck 5y ago
Are they seriously using 'the rust community is the most friendly to trans people' as a genuine influence on making a decision? How is that even remotely verifiable?
- alophawen 5y ago
  That's not even the most controversial claim in that article.
  - breakfastduck 5y ago
    Not half! My favourite quote... > "The formula and weighting are somewhat arbitrary" You don't say... the entire bloody justification is!
- EdwardDiego 5y ago
  Someone tweeted about how people on a Rust subreddit were being mean about trans people, and other people said they were bad, and QED...?
mikecoles 5y ago
Backblaze providing HD stats can be useful. This company fanboying for a language is, well, strange.
deleted 5y ago
[deleted]
ainar-g 5y ago
Seeing 5 for Rust and 3 for Go in the Stability section is weird for me as an experienced Go developer. While null pointers and such to happen, most of them are caught in the QA phase. Most of the bugs I've encountered in production were either resource misuse bugs (some of which Rust could catch) or business logic / architecture bugs (which no programming language can ever solve). Also, I'm not sure if Rust has the same amount of tooling to diagnose these issues as Go, such as the built-in online profiler. But if it does, please correct me. Dev time getting a 3/5 in Go is also quite weird, considering both that Go is a simpler language as well as the fact that it compiles quickly, so whenever you have an issue changing the code to get more info and recompiling is literally a matter of seconds. Besides, most of my dev time isn't really spent in debugging; it's in the architecture. In making things be readable and work well together. And I'm not even sure what they mean by “Memory Safety”. Access outside of a slice's boundaries causes a runtime panic, not a memory corruption or a segfault as in C++.
- ekidd 5y ago
  > Seeing 5 for Rust and 3 for Go in the Stability section is weird for me as an experienced Go developer. While null pointers and such to happen, most of them are caught in the QA phase. As someone who writes a lot of production Rust code, I also find some of the ratings a bit surprising. Go is usually pretty stable in production, certainly better than 3/5. But at the same time, I am so over catching null-reference crashes in the "QA Phase." Subjectively, it just feels like shoddy craftwork, the equivalent of making wooden cabinets with doors that don't quite close correctly. We can do better than this, and we should. I have needed to debug major Go packages in production, including Hashicorp products and Pachyderm. And null-reference issues do come up, along with similar sloppiness about data types and invalid states. It's not super-common, but it does happen, and it's a lousy way to spend a weekend emergency. I'm really hoping that Go continues to evolve in this area. There's a lot that I like about Go, and there's some terrific software written in Go. > And I'm not even sure what they mean by “Memory Safety”. Access outside of a slice's boundaries causes a runtime panic, not a memory corruption or a segfault as in C++. I've spent some time fuzzing Rust code using the excellent 'cargo fuzz'. And this made me feel like Rust provides 3 major kinds of memory safety: 1. Bounds checks! This is ancient technology shared by many languages, and it's far less 'cool' than the borrow checker. Nonetheless, it seems to be the single biggest thing that turns serious attacks into controlled shutdowns. 2. Borrow-checking stuff: Use-after-free, etc. GCed languages all have solid solutions for this. Rust's only advantage here is that it provides similar safety without GC overhead (and the poor tail latency and memory usage of many GCed languages). 3. Easier concurrency. This is the one that's easiest to forget. Many GCed languages allow shared data structures to be mutated freely by multiple threads, even when doing so will corrupt data. This usually can't be turned into C-style code injection attacks, but it can cause major headaches. The only real safety advantage Rust has over GCed languages here is (3). Whether or not this matters depends on exactly how a given program uses threads.
jstx1 5y ago
Stuff like this somehow me less likely to consider Rust. Not because of the language itself but because of the cultish parts of the community.
- secondcoming 5y ago
  There is definitely some weirdness in the community but that wouldn't stop me from using the right tool for the job. Likewise if the community was 'toxic'.
AshamedCaptain 5y ago
This is the second Synergy rewrite after the first was a completely failed one (i.e. the rewrite was less stable and fuglier than their original C++ implementation). Somehow I don't think choosing a different fancy-language-of-this-week is going to help improve the chances of this new rewrite. I am a paying customer of Synergy and kindly ask them to focus on their existing software and to Please. Stop. Rewriting. Software. Every. Other. Day.
tonyedgecombe 5y ago
>A lot of the scoring is very subjective I suspect these decisions are far more emotional than most of us here would like to admit.
EdwardDiego 5y ago
When you say Rust is 5/5 stability, define stability, please... > Stability: How stable the Synergy 3 service is likely to be (i.e. memory safety, etc). Huh. So, memory safety. And of course, the ever relevant "etc." Well, he did say it was going to be a technical article, very glad I strapped myself in. > 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 Um. https://doc.rust-lang.org/nomicon/leaking.html https://doc.rust-lang.org/nomicon/leaking.html I wasn't aware that Go programs were known for leaking memory due to their dastardly GC. For shame GC languages that were explicitly designed to prevent a multitude of memory related bugs! For shame! ...has anyone told this gentleman about unsafe blocks?
qualudeheart 5y ago
I miss when c++ was more common. None of the competing languages are the same.

18 points by lukastyrychtr 5y ago

> 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. That "study" has a lot to answer for!

axiosgunnar 5y ago

Why wasn't Java considered?

bajsejohannes 5y ago
I don't know, but it does seem self-contradictory to say it wasn't considered, because there's an implicit consideration in that, even if it's short lived. SNOBOL4 on the other hand, was probably not considered at all.
cesaref 5y ago
Why wasn't .net considered? The whole article is very weird, and there is little to learn from it. Wind on till they've actually made the port, and have run it for some time and then there will be some interesting lessons learnt, gazing into my crystal ball it will be somethong like 'turned out to be harder and take longer than we thought, but the result is good'
- axiosgunnar 5y ago
  They have one short sentence plonked in there saying "Java was not considered". They didn't give a reason why. They didn't mention .net anywhere.
  - EdwardDiego 5y ago
    But that's the point. Why was it only Rust and Go when memory safety is a big deal and also can the author please show me on the doll where the bad Java hurt him?
bullen 5y ago
Because it would be the best choice and it's old. You cannot sell C/Java. Computers are now reaching the maturity lightbulbs had when they artificially limited the burn time to 1000 hours. Personally I going back to C and JavaSE/J2ME on Rasperry 4/Pico.
wrnr 5y ago
I would like to apologise on behest of the Rust community, we are not all like this. Java would have been a fine choice.
koufatz 5y ago
Java or Kotlin seems actually a very good compromise. Very good performance and also actually in the top of the list of the energy efficient languages. Plus you can find a lot of more devs using JVM tech stack.
EdwardDiego 5y ago
Obviously the well known habit of JVM applications to leak memory. /s (Although being fair, I've met some Java libs that leak memory (looking at you, Couchbase), usually via poor usage of byte buffers. But Rust doesn't let you use unsafe code constructs, so it'll be fine. I guess I need another /s now.)

bigmek123 5y ago

They are citing the "rust is more green than go" article debunked by Russ Cox: https://twitter.com/_rsc/status/1496352325157457922 https://twitter.com/_rsc/status/1496352325157457922, also the excel comparison table they are showing is _extremely_ biased towards Rust - training for Rust 3/5 and Go 4/5? Dev time: Rust 2/5, Go 3/5? Really?

rob74 5y ago
No idea why you're getting downvoted, but I agree that Russ Cox' criticism of the AWS article is justified, amongst others because of the 2017 (!) Portuguese study it cites - a scientific study that ranks the "energy efficiency" of programming languages based on Computer Language Benchmark Games - really? I mean, how about looking at some real world applications instead?
- igouy 5y ago
  What explanation is given in that 2017 paper for selecting programs from the benchmarks game? ---- Meanwhile we can do better than "every C program is a valid C++ program, so C++ can’t lose" defensiveness. Look at the data tables published with that 2017 paper: https://sites.google.com/view/energy-efficiency-languages/results https://sites.google.com/view/energy-efficiency-languages/re... There's an order of magnitude difference between the times of the selected C and C++ programs, for one thing — regex-redux. That is enough to explain all of the difference between the C and C++ time measurements shown in "Table 4. Normalized global results". (Seems like an outlier which could have been excluded.)

rob74 5y ago

Er... > 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 And here I was (maybe naively) thinking that a garbage collector ensures memory safety? Unless they mean memory leaks (of the kind where memory is allocated and can't be freed by the GC, but is also not used?!). But that should be relatively easy to catch with a profiler? Maybe some more explanation would have been in order here... More generally, glad to see Go got 80% compared to Rust's 90% - just hoping they weighed their priorities correctly, otherwise who knows, with such a small difference Go might have come out on top...

cillian64 5y ago
GC protects you against use-after-free memory safety issues but doesn’t help with concurrency issues, i.e. one thread reading from a shared structure at the same time as another writing to it.
nkozyra 5y ago
I wonder how much work they estimated it would take to make Go as "memory safe" as Rust. I feel like the body of the post could have been "we just want to use Rust, ok??!"
- EdwardDiego 5y ago
  Yeah, I feel like you could just rephrase Jim Jefferie's classic comment on gun control[0] and replace this entire blog post with "fuck off, I like Rust". [0]https://youtu.be/0rR9IaXH1M0?t=107 https://youtu.be/0rR9IaXH1M0?t=107
MaulingMonkey 5y ago
I agree that leaking memory usually gets its own category, rather than being shoveled under the "memory safety". That said, I'll play a bit of devil's advocate: You can still have use-after-free bugs in a GCed language. A trivial example is calling methods on a closed/disposed/??? socket, file, or other handle. They don't result in the arbitrary memory corruption I'd typically consider a "real" memory safety issue, but they do result in bugs. In some cases, debug allocators and tools like address sanitizer can even surface such mistakes more quickly than similar code in a GCed languages. (Of course, in other cases, mistakes with non-GC memory cause bugs that are an absolute nightmare to repro and debug.) More troubling is native interop, which I'd assume something like Synergy will definitely need to do plenty of to capture/forward keyboard/mouse input, bypassing the traditional window focus reliant input stack that the language may pre-provide safe bindings for. Failure to pin, or unpinning too early during an asyncronous operation, can cause your GC-allocated memory to shift around during GC compaction when native code was expecting it to remain in one place. The GC can also potentially outright reap GC-allocated objects that native code was using. I remember reading of nasty heisenbugs from Ruby C extensions forgetting to use RB_GC_GUARD to ensure VALUEs remain on the stack, where the GC can find them, when scanning for GC roots that keep objects alive - as an example. Well, you can write similar bugs in non-GCed languages, but GCed languages aren't immune from these concerns. I've even bluescreened fairly modern Windows, with C# code, by sufficiently misusing SlimDX! EDIT: links to the aforementioned reading: http://timetobleed.com/the-broken-promises-of-mrireeyarv/ http://timetobleed.com/the-broken-promises-of-mrireeyarv/ https://news.ycombinator.com/item?id=2730286 https://news.ycombinator.com/item?id=2730286

mohanmcgeek 5y ago

The title itself is inviting a language flamewar and the body of the article is extremely dubious

deleted 5y ago
[deleted]

rob74 5y ago

Also: > But, existing Rust developers of course have a different view. "I find rust far easier than C++ to work with." I bet it's far easier than C++ - then again, almost every programming language on this planet is far easier than C++...

alophawen 5y ago

The article is laid out in a way that seem to only justify Rust as their choice. Some points is plain out silly, like the spreadsheet with fully made up numbers such as Stability Rust 5/5 Stability Go 3/5 The Recruitment points is even more biased, given the reality where you probably will find close to 50x more applicants familiar with Go versus Rust.

thraxil 5y ago
Yeah, I'm willing to give Rust the edge on stability and correctness, but I'd probably put Go at more like 4/5. It's certainly possible to make Go programs that crash, but it's also really easy to make them incredibly stable. I don't think they're wrong for picking Rust. I really like Rust and it's probably a great fit for them. There's a good chance I'd have picked Rust for the same project. Based on their criteria, I'd probably see it as a bit more of a coin toss between Rust and Go though and I suspect they just picked the one they wanted. And that's totally fine.

breakfastduck 5y ago

Are they seriously using 'the rust community is the most friendly to trans people' as a genuine influence on making a decision? How is that even remotely verifiable?

alophawen 5y ago
That's not even the most controversial claim in that article.
- breakfastduck 5y ago
  Not half! My favourite quote... > "The formula and weighting are somewhat arbitrary" You don't say... the entire bloody justification is!
EdwardDiego 5y ago
Someone tweeted about how people on a Rust subreddit were being mean about trans people, and other people said they were bad, and QED...?

mikecoles 5y ago

Backblaze providing HD stats can be useful. This company fanboying for a language is, well, strange.

deleted 5y ago

[deleted]

ainar-g 5y ago

Seeing 5 for Rust and 3 for Go in the Stability section is weird for me as an experienced Go developer. While null pointers and such to happen, most of them are caught in the QA phase. Most of the bugs I've encountered in production were either resource misuse bugs (some of which Rust could catch) or business logic / architecture bugs (which no programming language can ever solve). Also, I'm not sure if Rust has the same amount of tooling to diagnose these issues as Go, such as the built-in online profiler. But if it does, please correct me. Dev time getting a 3/5 in Go is also quite weird, considering both that Go is a simpler language as well as the fact that it compiles quickly, so whenever you have an issue changing the code to get more info and recompiling is literally a matter of seconds. Besides, most of my dev time isn't really spent in debugging; it's in the architecture. In making things be readable and work well together. And I'm not even sure what they mean by “Memory Safety”. Access outside of a slice's boundaries causes a runtime panic, not a memory corruption or a segfault as in C++.

ekidd 5y ago
> Seeing 5 for Rust and 3 for Go in the Stability section is weird for me as an experienced Go developer. While null pointers and such to happen, most of them are caught in the QA phase. As someone who writes a lot of production Rust code, I also find some of the ratings a bit surprising. Go is usually pretty stable in production, certainly better than 3/5. But at the same time, I am so over catching null-reference crashes in the "QA Phase." Subjectively, it just feels like shoddy craftwork, the equivalent of making wooden cabinets with doors that don't quite close correctly. We can do better than this, and we should. I have needed to debug major Go packages in production, including Hashicorp products and Pachyderm. And null-reference issues do come up, along with similar sloppiness about data types and invalid states. It's not super-common, but it does happen, and it's a lousy way to spend a weekend emergency. I'm really hoping that Go continues to evolve in this area. There's a lot that I like about Go, and there's some terrific software written in Go. > And I'm not even sure what they mean by “Memory Safety”. Access outside of a slice's boundaries causes a runtime panic, not a memory corruption or a segfault as in C++. I've spent some time fuzzing Rust code using the excellent 'cargo fuzz'. And this made me feel like Rust provides 3 major kinds of memory safety: 1. Bounds checks! This is ancient technology shared by many languages, and it's far less 'cool' than the borrow checker. Nonetheless, it seems to be the single biggest thing that turns serious attacks into controlled shutdowns. 2. Borrow-checking stuff: Use-after-free, etc. GCed languages all have solid solutions for this. Rust's only advantage here is that it provides similar safety without GC overhead (and the poor tail latency and memory usage of many GCed languages). 3. Easier concurrency. This is the one that's easiest to forget. Many GCed languages allow shared data structures to be mutated freely by multiple threads, even when doing so will corrupt data. This usually can't be turned into C-style code injection attacks, but it can cause major headaches. The only real safety advantage Rust has over GCed languages here is (3). Whether or not this matters depends on exactly how a given program uses threads.

jstx1 5y ago

Stuff like this somehow me less likely to consider Rust. Not because of the language itself but because of the cultish parts of the community.

secondcoming 5y ago
There is definitely some weirdness in the community but that wouldn't stop me from using the right tool for the job. Likewise if the community was 'toxic'.

AshamedCaptain 5y ago

This is the second Synergy rewrite after the first was a completely failed one (i.e. the rewrite was less stable and fuglier than their original C++ implementation). Somehow I don't think choosing a different fancy-language-of-this-week is going to help improve the chances of this new rewrite. I am a paying customer of Synergy and kindly ask them to focus on their existing software and to Please. Stop. Rewriting. Software. Every. Other. Day.

tonyedgecombe 5y ago

>A lot of the scoring is very subjective I suspect these decisions are far more emotional than most of us here would like to admit.

EdwardDiego 5y ago

When you say Rust is 5/5 stability, define stability, please... > Stability: How stable the Synergy 3 service is likely to be (i.e. memory safety, etc). Huh. So, memory safety. And of course, the ever relevant "etc." Well, he did say it was going to be a technical article, very glad I strapped myself in. > 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 Um. https://doc.rust-lang.org/nomicon/leaking.html https://doc.rust-lang.org/nomicon/leaking.html I wasn't aware that Go programs were known for leaking memory due to their dastardly GC. For shame GC languages that were explicitly designed to prevent a multitude of memory related bugs! For shame! ...has anyone told this gentleman about unsafe blocks?

qualudeheart 5y ago

I miss when c++ was more common. None of the competing languages are the same.