3 ms·

> There is also no reason to believe that changing the programming language will yield a better tool than before. Except similar tools like esbuild (Go) and sw

> There is also no reason to believe that changing the programming language will yield a better tool than before. Except similar tools like esbuild (Go) and swc (Rust) have achieved an order of magnitude improvement in performance compared to JS based fools. This is critical because developers will prefer the fastest tools to get work done. Guessing you didn’t know this and that’s why you confidently and condescendingly proclaimed that > just admit you want to rewrite in Rust because you like Rust.

optymizer 5y ago
It's irrelevant whether it is in principle possible to create faster tools in other languages. Joe Schmo, who ran into a wall with his project in Node.js, is lying to himself if he thinks that rewriting the whole thing in Rust is going to magically solve the problems that drove his project into a wall in the first place. A bad workman blames his tools.
- pdimitar 5y ago
  It's irrelevant according to you. That's not an accepted fact.
  - optymizer 5y ago
    I find your comment puzzling. What specifically is not an accepted fact?
    - pdimitar 5y ago
      Sorry, should have been more specific, my bad. I mean this part in particular: > It's irrelevant whether it is in principle possible to create faster tools in other languages. I disagree that it's irrelevant. There's a ton of development tooling nowadays that can be much faster. The accumulated slowdown and thumb-twiddling that ensues when 20 JS junior devs have to wait for a solid minute or two on their mid-range laptops can and has lead to real productivity losses.
      - optymizer 5y ago
        In this scenario, the team uses dev tool X for project Y. I'm not arguing that X shouldn't be faster, or even that it's not beneficial for Y to run faster. My original point was that the team that worked on project Y so far is unlikely to do a better job in a completely new language, just because some other team managed to write fast software in that language, because the other team isn't the one working on project Y. I didn't think this would be a controversial point. I probably should have phrased it better.
        pdimitar 5y ago
        Now that you explained it I actually agree with you so maybe another phrasing was needed indeed. But maybe I'm just dumb and didn't get it earlier. :) I agree the odds are against the team employing a new language. Far from impossible though. I've seen it successfully pulled off a number of times (I've seen plenty of unsuccessful tries as well).

optymizer 5y ago

It's irrelevant whether it is in principle possible to create faster tools in other languages. Joe Schmo, who ran into a wall with his project in Node.js, is lying to himself if he thinks that rewriting the whole thing in Rust is going to magically solve the problems that drove his project into a wall in the first place. A bad workman blames his tools.

pdimitar 5y ago
It's irrelevant according to you. That's not an accepted fact.
- optymizer 5y ago
  I find your comment puzzling. What specifically is not an accepted fact?
  - pdimitar 5y ago
    Sorry, should have been more specific, my bad. I mean this part in particular: > It's irrelevant whether it is in principle possible to create faster tools in other languages. I disagree that it's irrelevant. There's a ton of development tooling nowadays that can be much faster. The accumulated slowdown and thumb-twiddling that ensues when 20 JS junior devs have to wait for a solid minute or two on their mid-range laptops can and has lead to real productivity losses.
    - optymizer 5y ago
      In this scenario, the team uses dev tool X for project Y. I'm not arguing that X shouldn't be faster, or even that it's not beneficial for Y to run faster. My original point was that the team that worked on project Y so far is unlikely to do a better job in a completely new language, just because some other team managed to write fast software in that language, because the other team isn't the one working on project Y. I didn't think this would be a controversial point. I probably should have phrased it better.
      - pdimitar 5y ago
        Now that you explained it I actually agree with you so maybe another phrasing was needed indeed. But maybe I'm just dumb and didn't get it earlier. :) I agree the odds are against the team employing a new language. Far from impossible though. I've seen it successfully pulled off a number of times (I've seen plenty of unsuccessful tries as well).