4 ms·

Another hot take: maybe we will see a spike of compiles languages like Go, Rust and WASM, over Python, Ruby, and Node.

by rilindo 9mo ago

memoriuaysj 9mo ago
we can use AI to rewrite everything in Rust this way all the RAM that AI data centers scoop up will be used to lessen demand for RAM that those same datacenters created net-zero RAM!
- shellwizard 9mo ago
  You've got to [download more ram](https://downloadmoreram.com/ https://downloadmoreram.com/)
- supertrope 9mo ago
  Are you selling renewable memory offset credits? My company is seeking to burnish our ESG reputation.
baxtr 9mo ago
Yet another hot take: we won’t see any of that. Instead users will simply get used to waiting.
- kitsune1 9mo ago
  This. Nodejs and Python were used in 2012, why is now any different?
999900000999 9mo ago
To be fair, we could also just optimize the runtime engines for interpreted languages. I do enjoy golang, but Rust gives me nightmares. I make my living in higher level languages. When I started learning to program JavaScript was just starting to gain popularity outside of the browser. It was the first language I could actually grasp, and I largely think it for giving me a career. No more evictions for me! The only real downside to JavaScript, you know being used as a tool for native apps with stuff like electron is it eats ram. Everything needs to a ship a full chrome binary. But if we go back to native applications, we don't get things like quality Linux ports. If you would have told me 15 years ago that Microsoft would create the most popular IDE on Linux I'd assume that you had misspoke.
Dwedit 9mo ago
I actually compared WASM to Javascript for a particular integer-math-heavy task. For a single run, Javascript beat out WASM because WASM had a lot more setup time. After running both 1000 times, they were almost equal in runtime. Yes, even though the Javascript was written using Doubles and the WASM was written using 64 bit ints. It just means that it's possible to write optimized Javascript (mainly by reducing object allocations, reuse objects instead)
- testdelacc1 9mo ago
  A benchmark of adding numbers doesn’t tell you how it performs on real world websites and codebases. I wouldn’t be surprised if JavaScript was still very competitive, simply because of how good V8 is, but I don’t think we can conclude anything from your benchmark. Of course it is always possible to write highly optimised code. But that’s not what people actually do, because of time, skill and maintenance constraints. Here’s a case study: in 2018 Mozilla ported some code from JS to Rust + WASM and got a 6x speed up [1]. An expert in V8 responded to this with highly optimised JavaScript, saying Maybe you don't need Rust and WASM to speed up your JS [2]. Both articles are worth reading! But it is worth remembering that it’s a lot quicker and easier to write the code in #1 than #2 and it is easier to maintain as well. [1] - https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with-rust-and-webassembly/ https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with... [2] - https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to-speed-up-your-js.html https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to...
  - bluGill 9mo ago
    V8 means javascript can be fast. However no amount of optimization can get around inefficient code. There is only so much optimizes can do about too many layers of abstraction, calculations that are used but not needed, and nested loops. Someone needs to step back once in a while and fix bottlenecks to make things fast.
  - Dwedit 9mo ago
    It wasn't some dummy "add numbers" loop, this was doing math (multiply-add) on large 336-bit integers. Performance sucked when I used native Javacsript BigInts. When I made my own BigInt by using an array of doubles, and pretended that the doubles were 48-bit integers, performance was much better. Using the arrays meant that all allocation of temporary values completely stopped. I had to write my own multiply-and-add function that would do bigint = bigint * 48-bit number + other bigint + other 48-bit number.

Another hot take: maybe we will see a spike of compiles languages like Go, Rust and WASM, over Python, Ruby, and Node.

by rilindo 9mo ago

Another hot take: maybe we will see a spike of compiles languages like Go, Rust and WASM, over Python, Ruby, and Node.

we can use AI to rewrite everything in Rust this way all the RAM that AI data centers scoop up will be used to lessen demand for RAM that those same datacenters created net-zero RAM!

shellwizard 9mo ago
You've got to [download more ram](https://downloadmoreram.com/ https://downloadmoreram.com/)
supertrope 9mo ago
Are you selling renewable memory offset credits? My company is seeking to burnish our ESG reputation.

baxtr 9mo ago

Yet another hot take: we won’t see any of that. Instead users will simply get used to waiting.

kitsune1 9mo ago
This. Nodejs and Python were used in 2012, why is now any different?

999900000999 9mo ago

To be fair, we could also just optimize the runtime engines for interpreted languages. I do enjoy golang, but Rust gives me nightmares. I make my living in higher level languages. When I started learning to program JavaScript was just starting to gain popularity outside of the browser. It was the first language I could actually grasp, and I largely think it for giving me a career. No more evictions for me! The only real downside to JavaScript, you know being used as a tool for native apps with stuff like electron is it eats ram. Everything needs to a ship a full chrome binary. But if we go back to native applications, we don't get things like quality Linux ports. If you would have told me 15 years ago that Microsoft would create the most popular IDE on Linux I'd assume that you had misspoke.

Dwedit 9mo ago

I actually compared WASM to Javascript for a particular integer-math-heavy task. For a single run, Javascript beat out WASM because WASM had a lot more setup time. After running both 1000 times, they were almost equal in runtime. Yes, even though the Javascript was written using Doubles and the WASM was written using 64 bit ints. It just means that it's possible to write optimized Javascript (mainly by reducing object allocations, reuse objects instead)

testdelacc1 9mo ago
A benchmark of adding numbers doesn’t tell you how it performs on real world websites and codebases. I wouldn’t be surprised if JavaScript was still very competitive, simply because of how good V8 is, but I don’t think we can conclude anything from your benchmark. Of course it is always possible to write highly optimised code. But that’s not what people actually do, because of time, skill and maintenance constraints. Here’s a case study: in 2018 Mozilla ported some code from JS to Rust + WASM and got a 6x speed up [1]. An expert in V8 responded to this with highly optimised JavaScript, saying Maybe you don't need Rust and WASM to speed up your JS [2]. Both articles are worth reading! But it is worth remembering that it’s a lot quicker and easier to write the code in #1 than #2 and it is easier to maintain as well. [1] - https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with-rust-and-webassembly/ https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with... [2] - https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to-speed-up-your-js.html https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to...
- bluGill 9mo ago
  V8 means javascript can be fast. However no amount of optimization can get around inefficient code. There is only so much optimizes can do about too many layers of abstraction, calculations that are used but not needed, and nested loops. Someone needs to step back once in a while and fix bottlenecks to make things fast.
- Dwedit 9mo ago
  It wasn't some dummy "add numbers" loop, this was doing math (multiply-add) on large 336-bit integers. Performance sucked when I used native Javacsript BigInts. When I made my own BigInt by using an array of doubles, and pretended that the doubles were 48-bit integers, performance was much better. Using the arrays meant that all allocation of temporary values completely stopped. I had to write my own multiply-and-add function that would do bigint = bigint * 48-bit number + other bigint + other 48-bit number.