3 ms·

"Carcinization" is not a reference to creating cancer as you might first think, it is instead "an example of convergent evolution in which a crustacean evolves

"Carcinization" is not a reference to creating cancer as you might first think, it is instead "an example of convergent evolution in which a crustacean evolves into a crab-like form from a non-crab-like form"[0] - in this case because the Rust mascot is a crab. [0] https://en.wikipedia.org/wiki/Carcinisation https://en.wikipedia.org/wiki/Carcinisation

fxtentacle 4y ago
Odd. When I read the article, I thought "creating cancer" is a pretty good description of the idea that one embeds a whole f*ing JavaScript runtime and accept a 10x performance decrease on runtime just so that you can avoid copying one .so file around.
- masklinn 4y ago
  > I thought "creating cancer" is a pretty good description of the idea that one embeds a whole f*ing JavaScript runtime wasm is not a javascript runtime. > and accept a 10x performance decrease on runtime Unless SIMD is involved (which is indeed a major issue around warm), the overhead of compiled wasm is generally observed below 50%, often closer to 15. Obviously if you're using a wasm interpreter all bets are off.
  - deleted 4y ago
    [deleted]
  - nuc1e0n 4y ago
    It might involve a performance penalty today, but in the years to come vendors will be investing in making it fast. And Wasm has a much smaller surface area to optimise than JavaScript does.
    - masklinn 4y ago
      The overhead I’m talking about is compared to native code, not to javascript. I’m not sure why you’re bringing up javascript, it’s nowhere in the discussion except in ggp’s misconceptions.
      - nuc1e0n 4y ago
        That's why I mentioned js. There's nothing in principal to stop wasm being implemented in hardware. Then it would be native code. Maybe this can be done easily with an FPGA?
wzdd 4y ago
Though in this case I think it should be called "the gopherisation of Rust programs" as it is going to extraordinary lengths to impose a Go norm (single binary) onto Rust.
- ilyt 4y ago
  Rust can do single binaries just fine IIRC...

fxtentacle 4y ago

Odd. When I read the article, I thought "creating cancer" is a pretty good description of the idea that one embeds a whole f*ing JavaScript runtime and accept a 10x performance decrease on runtime just so that you can avoid copying one .so file around.

masklinn 4y ago
> I thought "creating cancer" is a pretty good description of the idea that one embeds a whole f*ing JavaScript runtime wasm is not a javascript runtime. > and accept a 10x performance decrease on runtime Unless SIMD is involved (which is indeed a major issue around warm), the overhead of compiled wasm is generally observed below 50%, often closer to 15. Obviously if you're using a wasm interpreter all bets are off.
- deleted 4y ago
  [deleted]
- nuc1e0n 4y ago
  It might involve a performance penalty today, but in the years to come vendors will be investing in making it fast. And Wasm has a much smaller surface area to optimise than JavaScript does.
  - masklinn 4y ago
    The overhead I’m talking about is compared to native code, not to javascript. I’m not sure why you’re bringing up javascript, it’s nowhere in the discussion except in ggp’s misconceptions.
    - nuc1e0n 4y ago
      That's why I mentioned js. There's nothing in principal to stop wasm being implemented in hardware. Then it would be native code. Maybe this can be done easily with an FPGA?

wzdd 4y ago

Though in this case I think it should be called "the gopherisation of Rust programs" as it is going to extraordinary lengths to impose a Go norm (single binary) onto Rust.

ilyt 4y ago
Rust can do single binaries just fine IIRC...