3 ms·

That was the whole idea of the Dart VM, by the way: to bridge the gap between the maximum performance you could get out of JavaScript and what you could get of

That was the whole idea of the Dart VM, by the way: to bridge the gap between the maximum performance you could get out of JavaScript and what you could get of a more statically-typed language. My recollection from a few years ago was that there was about a 2x performance gap between V8 and HotSpot. (All three VMs efforts: HotSpot, V8, and the Dart VM, were led by Larks Bak, by the way). I don't know if that gap has shrunk, grown, or has remained the same.

adam_arthur 5y ago
Yeah, it was a good idea. Given that Typescript is mostly consensus at this point, I'd argue trying to integrate it into the language spec is the better approach vs introducing a new language. But maybe there are technical reasons why it's not feasible
- viddo 5y ago
  It appears there are some attempts somewhat in that direction: - https://devblogs.microsoft.com/typescript/a-proposal-for-type-syntax-in-javascript/ https://devblogs.microsoft.com/typescript/a-proposal-for-typ... - https://github.com/giltayar/proposal-types-as-comments/ https://github.com/giltayar/proposal-types-as-comments/
cogman10 5y ago
So, what's interesting is that static typing buys you somewhat minimal gains in performance. This is why dart 1 shipped with what they called "optional typing". The thing Dart "fixed" in terms of performance is it forced consistent typing. It removed the ability to add/remove/change fields/methods on an object at runtime. The Achilles' heel of javascript (at least, when I got hype on dart years ago) is how stupidly easy it is to change the memory shape of any object. That means the VM can't generally lay out memory for an object in a compact form. Further, the VM has to do a bunch of checks before it can go down the optimized path (in case assumptions are invalidated). For a consistent type system, the only check needed is "is this object shaped like I think it should be?" and then you go from there. I think the most disappointing part of Dart is that all that effort was spent creating a new language when what the browser needed (and still needs) is a new bytecode. I'd love to see WASM reach the point of a universal bytecode but fear that it painted itself into a corner by first targeting memory managed languages.
- mraleph 5y ago
  > what's interesting is that static typing buys you somewhat minimal gains in performance. There are a lot of caveats here. You could potentially claim "minimal gains in peak performance if you can apply adaptive JIT compilation techniques", but even that is stretching it somewhat. Adaptive JITing comes at a price in terms of warmup, memory usage and implementation complexity. Fixed object shapes help somewhat to reduce the amount of checks needed but they don't take you all the way there. Optimising numerics remains challenging (e.g. think about optimising the case where a field always contains a `double` floating-point value or a field that always contains a 64-bit integer value). Knowing the shape of the container does not yield any information about the shape of elements which implies that some checks have to stay behind in the loops. Yes, monomorphic checks are usually simple (compare+branch) but polymorphic are not. And so on and so forth. Yes, Dart 1 is easier to compile into efficient code compared to JavaScript. Dart 2 is even easier though - because it is more statically typed. > but fear that it painted itself into a corner by first targeting memory managed languages. FWIW WASM GC is coming - and it looks great.
  - cogman10 5y ago
    > FWIW WASM GC is coming - and it looks great. I've not been tuned in. Is there some good forward progress there? It along with threads felt stalled out. I'd love to see GC adopted as that would, IMO, turn WASM into something close to a universal bytecode. It would significantly expand the number of languages that could reasonably target WASM.
    - mraleph 5y ago
      The extension has recently reached Stage 2 - most of the questions around type system have been resolved. V8 has a working implementation. We have build `dart2wasm` compiler targeting this and it shows good numbers.
      - cogman10 5y ago
        Well that's really exciting! Time to work on bringing back java applets ;)

adam_arthur 5y ago

Yeah, it was a good idea. Given that Typescript is mostly consensus at this point, I'd argue trying to integrate it into the language spec is the better approach vs introducing a new language. But maybe there are technical reasons why it's not feasible

viddo 5y ago
It appears there are some attempts somewhat in that direction: - https://devblogs.microsoft.com/typescript/a-proposal-for-type-syntax-in-javascript/ https://devblogs.microsoft.com/typescript/a-proposal-for-typ... - https://github.com/giltayar/proposal-types-as-comments/ https://github.com/giltayar/proposal-types-as-comments/

cogman10 5y ago

So, what's interesting is that static typing buys you somewhat minimal gains in performance. This is why dart 1 shipped with what they called "optional typing". The thing Dart "fixed" in terms of performance is it forced consistent typing. It removed the ability to add/remove/change fields/methods on an object at runtime. The Achilles' heel of javascript (at least, when I got hype on dart years ago) is how stupidly easy it is to change the memory shape of any object. That means the VM can't generally lay out memory for an object in a compact form. Further, the VM has to do a bunch of checks before it can go down the optimized path (in case assumptions are invalidated). For a consistent type system, the only check needed is "is this object shaped like I think it should be?" and then you go from there. I think the most disappointing part of Dart is that all that effort was spent creating a new language when what the browser needed (and still needs) is a new bytecode. I'd love to see WASM reach the point of a universal bytecode but fear that it painted itself into a corner by first targeting memory managed languages.

mraleph 5y ago
> what's interesting is that static typing buys you somewhat minimal gains in performance. There are a lot of caveats here. You could potentially claim "minimal gains in peak performance if you can apply adaptive JIT compilation techniques", but even that is stretching it somewhat. Adaptive JITing comes at a price in terms of warmup, memory usage and implementation complexity. Fixed object shapes help somewhat to reduce the amount of checks needed but they don't take you all the way there. Optimising numerics remains challenging (e.g. think about optimising the case where a field always contains a `double` floating-point value or a field that always contains a 64-bit integer value). Knowing the shape of the container does not yield any information about the shape of elements which implies that some checks have to stay behind in the loops. Yes, monomorphic checks are usually simple (compare+branch) but polymorphic are not. And so on and so forth. Yes, Dart 1 is easier to compile into efficient code compared to JavaScript. Dart 2 is even easier though - because it is more statically typed. > but fear that it painted itself into a corner by first targeting memory managed languages. FWIW WASM GC is coming - and it looks great.
- cogman10 5y ago
  > FWIW WASM GC is coming - and it looks great. I've not been tuned in. Is there some good forward progress there? It along with threads felt stalled out. I'd love to see GC adopted as that would, IMO, turn WASM into something close to a universal bytecode. It would significantly expand the number of languages that could reasonably target WASM.
  - mraleph 5y ago
    The extension has recently reached Stage 2 - most of the questions around type system have been resolved. V8 has a working implementation. We have build `dart2wasm` compiler targeting this and it shows good numbers.
    - cogman10 5y ago
      Well that's really exciting! Time to work on bringing back java applets ;)