3 ms·

The author of esbuild also started the implementation of esbuild in rust, found it painful too and switched to build it in go.

• pjmlp 5y ago
  For me the ideal use case for Rust is really for places where automatic memory management is a hard sell, even if technically possible, kernels, drivers, hypervisors, firmware, GPGPU, ... For everything else I rather enjoy the productivity of automatic memory management.
  • ameliaquining 5y ago
    My general inclination is to go straight to Rust if I already tried a different reasonably performant language (like Node.js) and it wasn't fast enough—because only Rust (and C and C++ and a few more obscure languages) guarantees that basically any performance optimization that I might want to do will at least be possible, even if it might be inelegant or unsafe. I don't want to run the risk of hitting another performance wall that I can't climb over. That being said, porting this kind of codebase to Rust would indeed be really rough—definitely possible, but by no means pleasant. I like to think the platonic ideal Rust, which we're hopefully getting closer and closer to over time, is capable of elegantly handling cyclic data structures and the like even while encouraging a single-ownership model for the 95% of cases where that's the right design. I don't think the Rust we have today is there yet.
    • pjmlp 5y ago
      I wouldn't put node.js and performance on the same sentence. Better than other dynamic languages, definitely. That is about it. Plenty of languages that offer AOT compilation and automatically managed memory to chose from.