> 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.
> 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.
Please quote the author's words which you say are misinformation — so we don't waste time guessing what you mean — and then explain what you think is wrong.
> … often rely on FFI, unsafe code, and hand-written SIMD intrinsics…
That wording seems to be copied from the current benchmarks game website but the author is talking about a 2017 study.
What you say has to be about what was used by that independent study 5 years ago, not about whatever the benchmarks game website shows today.
> TypeScript is apparently far more energy-hungry (and we're not likely to use pure JavaScript).
The implication, I believe, is that plain JavaScript is more energy efficient than TypeScript, which is what was reported in the paper. But this is a very odd observation, as TypeScript generates normal JavaScript code, which would be run on the same JavaScript implementation.
> That wording seems to be copied from the current benchmarks game website but the author is talking about a 2017 study.
I wrote that wording myself, so I guess I got lucky if it's the same as what's on the benchmarks game website. But that was my observation some years ago.
It seems pertinent for the state of CLBG in 2017 too:
> The implication, I believe, is that plain JavaScript is…
No, the author actually tells us the reason — "And, we could well have chosen JavaScript for our Node.js code, though we're not likely to do this due to TypeScript being much more convenient to work with by comparison."
Given the title is "We're choosing Rust, and not Go, C++, or Node.js" the plain reading was always that "TypeScript is apparently far more energy-hungry" than Rust, Go, C++.
> … the state of CLBG in 2017…
The author does not mention the benchmarks game.
What you say has to be about what was used by that independent study 5 years ago, not about whatever the benchmarks game website showed 5 years ago.
> What you say has to be about what was used by that independent study 5 years ago, not about whatever the benchmarks game website showed 5 years ago.
The study tested the benchmarks game programs. Page 2 of the paper [0] explicitly states "our case study to analyze the energy efficiency of software languages is based on the CLBG" and proceeds to describe the programs tested.
That could be relevant if the study tested every one of the programs shown on the benchmarks game website on some particular day. In other words if the set of programs tested by the study was identical to the set of programs shown on the benchmarks game website.
There is a list of benchmarks used; including the Mandelbrot and pidigits benchmarks I cite. They also claim "they gathered the most efficient (i.e. fastest) version of the source code"; and I cited the fastest programs.
This is legitimately painful to discuss, as this information is readily available in the paper, and seemingly we are getting nowhere by picking at how I made my observations; so I am going to do something more enjoyable, somewhere very far away from you.
So the study took a subset of the programs shown on the benchmarks game website sometime 5 years ago, and that is why instead of looking at the benchmarks game programs we need to look in the repo provided with the study.
So, just to make this clear, you were aware from the very start that
- At 2017 when the study was made, CLBG relied (and still is) on "FFI, unsafe code, and hand-written SIMD intrinsics".
- The author of that paper did in fact mention the benchmarks game.
- The two 2017 CLBG examples that hayley-patton linked are exactly the same in the study's github repo.
But despite that, you decided to waste everyone's time and your real complaint is that https://news.ycombinator.com/item?id=31502504 should have linked at the github links that I posted in https://news.ycombinator.com/item?id=31548339 even though contents are exactly the same (at least as far as the argument is concerned, I have not and will not check if one of the versions has an extra ; or whatever), is that right?
Edit: it came to my attention that you are the one running CLBG, you might want to mention that (either on your profile or on your posts) when you engage in CLBG-related arguments.
> The author of that paper did in fact mention the benchmarks game.
Different author.
When hayley-patton writes "The third sentence should ring alarm bells in the head of the author" they mean the author of "We're choosing Rust, and not Go, C++, or Node.js".
"The author does not mention the benchmarks game" and "Please quote the author's words which you say are misinformation" and "the author is talking about a 2017 study" and "the author actually tells us the reason" are also referring to the author of "We're choosing Rust, and not Go, C++, or Node.js".
hayley-patton said the author of "We're choosing Rust, and not Go, C++, or Node.js" — "shouldn't repeat misinformation" — and gave this as the "misinformation":
"TypeScript is apparently far more energy-hungry (and we're not likely to use pure JavaScript)."
We got to your misunderstanding of the author's comment — contrary to your belief, the author meant “TypeScript is apparently far more energy-hungry” than Rust, Go, C++.
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.
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.
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.
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
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.
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.