5 ms·

> 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 memor

> 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"?
- hayley-patton 4y 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.
  - igouy 4y ago
    > … misinformation… 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.
    - hayley-patton 4y ago
      > 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: https://web.archive.org/web/20170526092655/http://benchmarksgame.alioth.debian.org/u64q/program.php?test=pidigits&lang=java&id=2 https://web.archive.org/web/20170526092655/http://benchmarks... just FFIs out to GNU MP. https://web.archive.org/web/20170619103241/http://benchmarksgame.alioth.debian.org/u64q/program.php?test=mandelbrot&lang=sbcl&id=1 https://web.archive.org/web/20170619103241/http://benchmarks... uses "inline assembly" of a sort, and disables safety checks entirely.

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"?

hayley-patton 4y 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.
- igouy 4y ago
  > … misinformation… 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.
  - hayley-patton 4y ago
    > 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: https://web.archive.org/web/20170526092655/http://benchmarksgame.alioth.debian.org/u64q/program.php?test=pidigits&lang=java&id=2 https://web.archive.org/web/20170526092655/http://benchmarks... just FFIs out to GNU MP. https://web.archive.org/web/20170619103241/http://benchmarksgame.alioth.debian.org/u64q/program.php?test=mandelbrot&lang=sbcl&id=1 https://web.archive.org/web/20170619103241/http://benchmarks... uses "inline assembly" of a sort, and disables safety checks entirely.