5 ms·

> Maintaining Software that is written in a dynamically typed language like JavaScript is costly. Maintaining a JavaScript frontend that is build with React, NP

> Maintaining Software that is written in a dynamically typed language like JavaScript is costly. Maintaining a JavaScript frontend that is build with React, NPM, WebPack and Babel is even more expensive. Not exactly. In modern browsers JavaScript executes in a VM. If the JavaScript instance is written in a strongly typed way it executes quickly by receiving the full benefits of a compiled language. Aside from arithmetic it executes almost as fast as Java. That is one of the strengths of TypeScript. I do completely agree about NPM, dependency overkill, and framework insanity. In short, don’t blame the language for being slow. Blame marketing and bad developers. That being said I have little faith that WASM will be fast once it meets the reality of bad developers and marketing teams.

jlelse 7y ago
I think that quote isn't about JS performance but maintaining software written in JS.
- austincheney 7y ago
  Again, that goes to the quality of product/people in a given instance. I have done this long enough to fully appreciate that when it comes to fucking up software on the web people will find a way whether it’s for some poorly conceived developer motivation or media/marketing motivation.
  - bsaul 7y ago
    i think the original post just mentionned « costly ». It didn’t say it was impossible to mess things up even with rust. Just that it removes the cost of checking types are still matching after a refactoring or a dependency update.
    - The_rationalist 7y ago
      Typescript allow that too.
    - rienbdj 7y ago
      This a true, but the advantage is probably more than offset by the relative cost of JS vs Rust developers. You can also add Flow types. A single threaded environment does not yield the usual advantages of the Rust borrow checker.
      - zozbot234 7y ago
        > the relative cost of JS vs Rust developers I.e. pay peanuts, get code monkeys? > A single threaded environment does not yield the usual advantages of the Rust borrow checker. This is quite wrong - reference invalidation and async code that's being scheduled within a single thread are two common examples where it matters a lot.
        Eikon 7y ago
        Lots of boilerplate and error-prone code can also be avoided by implementing `drop` on relevant types, this can yield to pretty interesting APIs in the web space.
      - steveklabnik 7y ago
        The borrow checker still helps quite a bit with a single thread: http://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/ http://manishearth.github.io/blog/2015/05/17/the-problem-wit...
ossworkerrights 7y ago
But rust is trendy so anything that is not rust is crap. I find it amusing when people blame technology for their own shortcomings, and think using a different language will improve things only to end up using the new lang just as bad. You are getting downvoted because there is just too much religion surrounding tech x vs tech y on hackernews and some people imagine rust is great for the web as if the world will suddenly drop tried and tested languages, with loads of tools and documentation available, with package manager and nearly ubiquitos support in favour of a fringe language like rust.
- rienbdj 7y ago
  This argument is a bit... tired. There are genuine advantages to different technologies and we should explore them. Every article about rewrites (not only Rust) is met with this sort of comment and it is counter productive. If someone is claiming a technology is better in some way and you disagree, explain why they are mistaken.
  - austincheney 7y ago
    > There are genuine advantages to different technologies That is also a tired argument. The compile target is WASM. Rust can be the greatest thing ever, but the performance that matters and the only limitations the user will see are those inherent to WASM. Is WASM multithreaded with the execution speed of a Rust binary? No, so who cares?
    - rienbdj 7y ago
      The process of generating the WASM is entirely different. C, C++ and Rust all generate x86 assembly but they have very different trade offs. Following this line of reasoning writing raw WASM would also be a fine choice!
- austincheney 7y ago
  It certainly isn't HN. It's everywhere. Reddit was worse by an order of magnitude and poorly moderated. I don't even think WASM executes faster than JavaScript in any meaningful metric. The strongest motivation, from developers that are not in any way involved in the WASM spec, is a shimmering hope that developers will be off the hook for writing JavaScript. In the context of "replacing JavaScript" type threads this results in the religious fascination that you and others have observed, but in other contexts comments are equally up-voted for their critical examination: https://news.ycombinator.com/item?id=21723071 https://news.ycombinator.com/item?id=21723071
tiborsaas 7y ago
I think he might have referred to costly in business sense, because more bugs lead to more developer hours spent.

jlelse 7y ago

I think that quote isn't about JS performance but maintaining software written in JS.

austincheney 7y ago
Again, that goes to the quality of product/people in a given instance. I have done this long enough to fully appreciate that when it comes to fucking up software on the web people will find a way whether it’s for some poorly conceived developer motivation or media/marketing motivation.
- bsaul 7y ago
  i think the original post just mentionned « costly ». It didn’t say it was impossible to mess things up even with rust. Just that it removes the cost of checking types are still matching after a refactoring or a dependency update.
  - The_rationalist 7y ago
    Typescript allow that too.
  - rienbdj 7y ago
    This a true, but the advantage is probably more than offset by the relative cost of JS vs Rust developers. You can also add Flow types. A single threaded environment does not yield the usual advantages of the Rust borrow checker.
    - zozbot234 7y ago
      > the relative cost of JS vs Rust developers I.e. pay peanuts, get code monkeys? > A single threaded environment does not yield the usual advantages of the Rust borrow checker. This is quite wrong - reference invalidation and async code that's being scheduled within a single thread are two common examples where it matters a lot.
      - Eikon 7y ago
        Lots of boilerplate and error-prone code can also be avoided by implementing `drop` on relevant types, this can yield to pretty interesting APIs in the web space.
    - steveklabnik 7y ago
      The borrow checker still helps quite a bit with a single thread: http://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/ http://manishearth.github.io/blog/2015/05/17/the-problem-wit...

ossworkerrights 7y ago

But rust is trendy so anything that is not rust is crap. I find it amusing when people blame technology for their own shortcomings, and think using a different language will improve things only to end up using the new lang just as bad. You are getting downvoted because there is just too much religion surrounding tech x vs tech y on hackernews and some people imagine rust is great for the web as if the world will suddenly drop tried and tested languages, with loads of tools and documentation available, with package manager and nearly ubiquitos support in favour of a fringe language like rust.

rienbdj 7y ago
This argument is a bit... tired. There are genuine advantages to different technologies and we should explore them. Every article about rewrites (not only Rust) is met with this sort of comment and it is counter productive. If someone is claiming a technology is better in some way and you disagree, explain why they are mistaken.
- austincheney 7y ago
  > There are genuine advantages to different technologies That is also a tired argument. The compile target is WASM. Rust can be the greatest thing ever, but the performance that matters and the only limitations the user will see are those inherent to WASM. Is WASM multithreaded with the execution speed of a Rust binary? No, so who cares?
  - rienbdj 7y ago
    The process of generating the WASM is entirely different. C, C++ and Rust all generate x86 assembly but they have very different trade offs. Following this line of reasoning writing raw WASM would also be a fine choice!
austincheney 7y ago
It certainly isn't HN. It's everywhere. Reddit was worse by an order of magnitude and poorly moderated. I don't even think WASM executes faster than JavaScript in any meaningful metric. The strongest motivation, from developers that are not in any way involved in the WASM spec, is a shimmering hope that developers will be off the hook for writing JavaScript. In the context of "replacing JavaScript" type threads this results in the religious fascination that you and others have observed, but in other contexts comments are equally up-voted for their critical examination: https://news.ycombinator.com/item?id=21723071 https://news.ycombinator.com/item?id=21723071

tiborsaas 7y ago

I think he might have referred to costly in business sense, because more bugs lead to more developer hours spent.