4 ms·

Hardware instructions created to handle JavaScript specifics makes me so very sad. What a terrible state of affairs.

by forrestthewoods 8y ago

umanwizard 8y ago
Why?
- FridgeSeal 8y ago
  Because, despite our papering over of some of it's warts, JS is still fundamentally a pretty terrible language; and rather than everyone trying to make it be better, shouldn't we devote time and hardware efforts like this to either language agnostic improvements, or to languages that are better designed?
  - wild_preference 8y ago
    Well, it's not terrible nor worse than other dynamically-typed programming languages. And it's one of the few languages with async-everything. Let's not exaggerate nor underestimate the fool's errand of replacing a ubiquitous language.
    - FridgeSeal 8y ago
      > Well, it's not terrible nor worse than other dynamically-typed programming languages. Not better or worse? It's got a type system with holes you could drive truck through, and more arcane edge-cases than a fantasy book of spells. > And it's one of the few languages with async-everything. Just because something is async doesn't make it better or faster, at some point the work has to be done, and for those cases where async does make a difference, pretty much every other language has an async implementation that is either just as good or superior. > Let's not exaggerate nor underestimate the fool's errand of replacing a ubiquitous language. Yeah, I think that horse has bolted, but we can stop making it anymore widespread than it absolutely needs to be.
      - Matumio 8y ago
        I agree about the type system, but as far as async is concerned, javascript with its (now standardized) promises is miles ahead. The main advantage IMO is not to gain performance, but to allow concurrency without data races (as required by a GUI that needs to wait for a server). If you try async programming in C++ or Python you'll quickly discover that half of the libraries are pre-async and block, and you'll have to resort to threads and still worry about data races.
        empthought 8y ago
        Python has easy-to-use shared-nothing message passing concurrency libraries based on threading, so no, you don’t have to worry about data races any more than you do with JS.
      - floatboth 8y ago
        > a type system with holes you could drive truck through That's most dynamic languages. (Python is a bit more strong than others, sure, but whatever.) > pretty much every other language has an async implementation that is either just as good or superior Most other languages have async bolted on and a lot of existing libraries are synchronous. Pretty much all JS embeddings (both the browser and various server side things) exposed everything as asynchronous from the beginning using callbacks — and now callbacks easily get wrapped into promises and async/await works with them very well.
millstone 8y ago
Nah. Tweaking rounding modes or overflow flags costs very little. Observe there's nothing being proposed for NaN-boxing, hidden class check support, etc. If someone goes all-in on JS you'll known it.
FridgeSeal 8y ago
I agree. All the things we could be doing and we're making CPU improvements for the flaming pile of hot trash that is JS? Why?
- wild_preference 8y ago
  We? You had zero stake in the matter. How many homeless people did you help out today? None while you were writing that comment.
  - dang 8y ago
    We've already asked you to stop being nasty in HN comments. Continuing to do that will get you banned, so please stop. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- olliej 8y ago
  Floating point to integer conversion instructions already exist - this changes sentinel value and rounding conversion behavior only, which is a minor conditional change at the end of the existing conversion pipeline. I would expect that the only actual change here is the final rounding and register store which is not significant. Those are already things that have to happen.
- koffiezet 8y ago
  Maybe because it's a considerable part of the code that CPU's are executing these days? Certainly UI stuff that should be responsive and fast. Even many 'native' apps, mobile or desktop (electron) are written in javascript, and how much of your time do you spend in your browser or electron apps every day? Think vscode, atom, Spotify, Slack, facebook, reddit, twitter, ...

Hardware instructions created to handle JavaScript specifics makes me so very sad. What a terrible state of affairs.

umanwizard 8y ago

Why?

FridgeSeal 8y ago
Because, despite our papering over of some of it's warts, JS is still fundamentally a pretty terrible language; and rather than everyone trying to make it be better, shouldn't we devote time and hardware efforts like this to either language agnostic improvements, or to languages that are better designed?
- wild_preference 8y ago
  Well, it's not terrible nor worse than other dynamically-typed programming languages. And it's one of the few languages with async-everything. Let's not exaggerate nor underestimate the fool's errand of replacing a ubiquitous language.
  - FridgeSeal 8y ago
    > Well, it's not terrible nor worse than other dynamically-typed programming languages. Not better or worse? It's got a type system with holes you could drive truck through, and more arcane edge-cases than a fantasy book of spells. > And it's one of the few languages with async-everything. Just because something is async doesn't make it better or faster, at some point the work has to be done, and for those cases where async does make a difference, pretty much every other language has an async implementation that is either just as good or superior. > Let's not exaggerate nor underestimate the fool's errand of replacing a ubiquitous language. Yeah, I think that horse has bolted, but we can stop making it anymore widespread than it absolutely needs to be.
    - Matumio 8y ago
      I agree about the type system, but as far as async is concerned, javascript with its (now standardized) promises is miles ahead. The main advantage IMO is not to gain performance, but to allow concurrency without data races (as required by a GUI that needs to wait for a server). If you try async programming in C++ or Python you'll quickly discover that half of the libraries are pre-async and block, and you'll have to resort to threads and still worry about data races.
      - empthought 8y ago
        Python has easy-to-use shared-nothing message passing concurrency libraries based on threading, so no, you don’t have to worry about data races any more than you do with JS.
    - floatboth 8y ago
      > a type system with holes you could drive truck through That's most dynamic languages. (Python is a bit more strong than others, sure, but whatever.) > pretty much every other language has an async implementation that is either just as good or superior Most other languages have async bolted on and a lot of existing libraries are synchronous. Pretty much all JS embeddings (both the browser and various server side things) exposed everything as asynchronous from the beginning using callbacks — and now callbacks easily get wrapped into promises and async/await works with them very well.

millstone 8y ago

Nah. Tweaking rounding modes or overflow flags costs very little. Observe there's nothing being proposed for NaN-boxing, hidden class check support, etc. If someone goes all-in on JS you'll known it.

FridgeSeal 8y ago

I agree. All the things we could be doing and we're making CPU improvements for the flaming pile of hot trash that is JS? Why?

wild_preference 8y ago
We? You had zero stake in the matter. How many homeless people did you help out today? None while you were writing that comment.
- dang 8y ago
  We've already asked you to stop being nasty in HN comments. Continuing to do that will get you banned, so please stop. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
olliej 8y ago
Floating point to integer conversion instructions already exist - this changes sentinel value and rounding conversion behavior only, which is a minor conditional change at the end of the existing conversion pipeline. I would expect that the only actual change here is the final rounding and register store which is not significant. Those are already things that have to happen.
koffiezet 8y ago
Maybe because it's a considerable part of the code that CPU's are executing these days? Certainly UI stuff that should be responsive and fast. Even many 'native' apps, mobile or desktop (electron) are written in javascript, and how much of your time do you spend in your browser or electron apps every day? Think vscode, atom, Spotify, Slack, facebook, reddit, twitter, ...