3 ms·

I'm curious if anyone else has noticed this? It seems Rust is tending towards "silver bullet"-status, as if; if it's written in Rust, it must be fast. I'm not

I'm curious if anyone else has noticed this? It seems Rust is tending towards "silver bullet"-status, as if; if it's written in Rust, it must be fast. I'm not here to rain on Rust's parade, but you can absolutely write unmaintainable, slow Rust code. I would even argue, beginners write fewer features that perform worse, in the same amount of time, than their main-language (in this example: Javascript) counterparts. Especially if they have years of experience.

maeln 4y ago
I agree that it is completely possible to write slow code in Rust, but the idea is still that, in general with a relatively skilled developer, a compiled langage will usually result in a faster program than with a interpreted or jit-ed langage. So, assuming you are competent in said langage, you might as well write it in your compiled langage of choice, assuming performance is one of your major priority.
- deleted 4y ago
  [deleted]
- JonChesterfield 4y ago
  A jit can tune itself to properties of input data which were unknown at compile time. That's a serious advantage for long running programs that don't know much about their input, which might be the important ones. That might still be the realm of the sufficiently smart compiler though, aka vapourware, so in practice today you're probably right.
melling 4y ago
I’m not a Rust developer and I’ve been waiting for it to bake a few more years before playing with it. However, I do appreciate the desire for developers to use languages that allow for more performance and fewer bugs, catching more bugs at compile time. Even small improvements are important. Ideally, poorly written, but correct, code in such a language could be refactored more easily in such a language.
bovermyer 4y ago
Rust does tend to make some folks starry-eyed, but that's not a good reason to avoid the language. I imagine you're of the same mind as I am - be intentional when choosing a language for a project, and consider all the pros and cons.
Waterluvian 4y ago
I agree, of course, that you can still write bad rust code. But I don’t quite see the silver bullet case happening. Rust is a great choice for a compiler and when written, in direct competition with a JS-based compiler, has enormous capacity to be far faster.
deleted 4y ago
[deleted]
dpcx 4y ago
From my reading, it's more that if written in Rust, even if it starts off slower, it can be made to be extremely fast, but that they're already bumping up against the limits of what the JS system can provide in terms of speed.
rattray 4y ago
In this case, I'm concerned that they're particularly naive to think that writing only parts of ESLint in Rust will be a win. My impression -- no firsthand experience -- is that the ser/des costs associated with FFI between node and rust when dealing with large objects like ASTs can eliminate most wins, especially if you have to go back and forth multiple times. Related: https://zaplib.com/docs/blog_post_mortem.html https://zaplib.com/docs/blog_post_mortem.html I'm also under the impression that most of the gains from rewriting Node into Go or Rust come from getting access to multithreading, which I can't imagine working well in this context if the ESLint plugins themselves are still written in JS (which, IMO, they certainly should be). A single file will still need to run on a single thread. (Of course, you can run different files on different cores with Workers or just subprocesses, but I assume ESLint does this already)
- JonChesterfield 4y ago
  The winning play here is to represent the node structure directly in rust, such that serialisation is a no-op. Which is admittedly tough to implement.
  - rafram 4y ago
    Still comes with the same issues. JS code will need access to the node structure, too, which means serializing it on the Rust side.
    - JonChesterfield 4y ago
      I mean have the same in memory representation in both languages such that no serialisation or deserialisation happens in either direction across the boundary. Fast but difficult to implement.
wwwigham 4y ago
V8 stopped dropping free perf wins on the JS community every year a while ago, and people are clearly starting to notice and feel like they need to take matters into their own hands. For some, that means an adventurous rewrite of their library with nebulous end results (I hesitate to call the proposal "eslint" still, since it seems to aspire to be an omni-linter). For others, it may mean abandoning JS entirely (see rome). And yet for some others, it has made them realize, just like with the other interpreted languages, the perf probably stopped being important after some unnoticed breakpoint. To be real, I don't think they'd get any perf gains from a wasm component - not until most of the library is wasm, anyway. The dream of offloading a small hot function to a faster, instruction-optimized wasm implementation is usually killed by marshalling costs for anything other than numbers. Even the perf of simple string functions (like `normalizePath`) often get destroyed in practice by things like unicode validation, since the string models and memory layouts between JS and Rust don't match. Still, despite all that, it's tempting to _try_ because, well, what else are you going to look into for performance gains? Once you've tracked down all your v8 deopts and monomorphized all your hot code, what's left but telling v8 to get out of the way as much as possible, while you go as low level as you can? Algorithms improvements? Those often amount to random flashes of insight - you can't plan those. So when a lot of people say "Hey, I reimplemented 5% of X in Rust and it's 20x faster!" you _could_ smugly assume it's because it's a partial implementation, or you can choose to believe that the authors don't have ulterior motives and the tech stack itself has merit and investigate it yourself. It'll be easier and more fun than thinking hard about usage patterns and algorithms all day, anyway.
cies 4y ago
> can absolutely write unmaintainable But you CAN write fast code too! And that, for a fairly high level language (in some aspects) is quite a feature, especially in the context of the safety it provides. In pure Python/Ruby you can certainly not write very fast code, not matter how hard you try.
latchkey 4y ago
Let us not forget this comment: https://news.ycombinator.com/item?id=22336284 https://news.ycombinator.com/item?id=22336284

maeln 4y ago

I agree that it is completely possible to write slow code in Rust, but the idea is still that, in general with a relatively skilled developer, a compiled langage will usually result in a faster program than with a interpreted or jit-ed langage. So, assuming you are competent in said langage, you might as well write it in your compiled langage of choice, assuming performance is one of your major priority.

deleted 4y ago
[deleted]
JonChesterfield 4y ago
A jit can tune itself to properties of input data which were unknown at compile time. That's a serious advantage for long running programs that don't know much about their input, which might be the important ones. That might still be the realm of the sufficiently smart compiler though, aka vapourware, so in practice today you're probably right.

melling 4y ago

I’m not a Rust developer and I’ve been waiting for it to bake a few more years before playing with it. However, I do appreciate the desire for developers to use languages that allow for more performance and fewer bugs, catching more bugs at compile time. Even small improvements are important. Ideally, poorly written, but correct, code in such a language could be refactored more easily in such a language.

bovermyer 4y ago

Rust does tend to make some folks starry-eyed, but that's not a good reason to avoid the language. I imagine you're of the same mind as I am - be intentional when choosing a language for a project, and consider all the pros and cons.

Waterluvian 4y ago

I agree, of course, that you can still write bad rust code. But I don’t quite see the silver bullet case happening. Rust is a great choice for a compiler and when written, in direct competition with a JS-based compiler, has enormous capacity to be far faster.

deleted 4y ago

[deleted]

dpcx 4y ago

From my reading, it's more that if written in Rust, even if it starts off slower, it can be made to be extremely fast, but that they're already bumping up against the limits of what the JS system can provide in terms of speed.

rattray 4y ago

In this case, I'm concerned that they're particularly naive to think that writing only parts of ESLint in Rust will be a win. My impression -- no firsthand experience -- is that the ser/des costs associated with FFI between node and rust when dealing with large objects like ASTs can eliminate most wins, especially if you have to go back and forth multiple times. Related: https://zaplib.com/docs/blog_post_mortem.html https://zaplib.com/docs/blog_post_mortem.html I'm also under the impression that most of the gains from rewriting Node into Go or Rust come from getting access to multithreading, which I can't imagine working well in this context if the ESLint plugins themselves are still written in JS (which, IMO, they certainly should be). A single file will still need to run on a single thread. (Of course, you can run different files on different cores with Workers or just subprocesses, but I assume ESLint does this already)

JonChesterfield 4y ago
The winning play here is to represent the node structure directly in rust, such that serialisation is a no-op. Which is admittedly tough to implement.
- rafram 4y ago
  Still comes with the same issues. JS code will need access to the node structure, too, which means serializing it on the Rust side.
  - JonChesterfield 4y ago
    I mean have the same in memory representation in both languages such that no serialisation or deserialisation happens in either direction across the boundary. Fast but difficult to implement.

wwwigham 4y ago

V8 stopped dropping free perf wins on the JS community every year a while ago, and people are clearly starting to notice and feel like they need to take matters into their own hands. For some, that means an adventurous rewrite of their library with nebulous end results (I hesitate to call the proposal "eslint" still, since it seems to aspire to be an omni-linter). For others, it may mean abandoning JS entirely (see rome). And yet for some others, it has made them realize, just like with the other interpreted languages, the perf probably stopped being important after some unnoticed breakpoint. To be real, I don't think they'd get any perf gains from a wasm component - not until most of the library is wasm, anyway. The dream of offloading a small hot function to a faster, instruction-optimized wasm implementation is usually killed by marshalling costs for anything other than numbers. Even the perf of simple string functions (like `normalizePath`) often get destroyed in practice by things like unicode validation, since the string models and memory layouts between JS and Rust don't match. Still, despite all that, it's tempting to _try_ because, well, what else are you going to look into for performance gains? Once you've tracked down all your v8 deopts and monomorphized all your hot code, what's left but telling v8 to get out of the way as much as possible, while you go as low level as you can? Algorithms improvements? Those often amount to random flashes of insight - you can't plan those. So when a lot of people say "Hey, I reimplemented 5% of X in Rust and it's 20x faster!" you _could_ smugly assume it's because it's a partial implementation, or you can choose to believe that the authors don't have ulterior motives and the tech stack itself has merit and investigate it yourself. It'll be easier and more fun than thinking hard about usage patterns and algorithms all day, anyway.

cies 4y ago

> can absolutely write unmaintainable But you CAN write fast code too! And that, for a fairly high level language (in some aspects) is quite a feature, especially in the context of the safety it provides. In pure Python/Ruby you can certainly not write very fast code, not matter how hard you try.

latchkey 4y ago

Let us not forget this comment: https://news.ycombinator.com/item?id=22336284 https://news.ycombinator.com/item?id=22336284