4 ms·

It looks like it's really the alternate VM that's being "shot down". After all, the piece goes to the trouble of pointing out that "...transforming compiler lib

It looks like it's really the alternate VM that's being "shot down". After all, the piece goes to the trouble of pointing out that "...transforming compiler libraries like Traceur and CoffeeScript show how syntax additions to JavaScript and even completely alternative syntaxes can be supported in today’s browsers, without changes to the runtime." Disclaimer: I work at Microsoft.

kodablah 15y ago
But those languages aren't a significant deviation and still require pre-compilation as opposed to runtime cross-compilation to be useful. Dart is a significant deviation and expected to support debugging directly in the language. Similar to developing in GWT, I doubt the JS will really be looked by the developers at once Dart's compiler is optimized more. Also, the VM wouldn't be required, it would just provide performance improvements.
- gcp 15y ago
  Dart is a significant deviation and expected to support debugging directly in the language. This can be done for CoffeeScript et al too - efforts are already underway. Also, the VM wouldn't be required, it would just provide performance improvements. There's just too much embrace-extend-extinguish risk for anyone but Google in that. That's why Mozilla and Microsoft are burning it at the stake.
- munificent 15y ago
  > Similar to developing in GWT, I doubt the JS will really be looked by the developers at once Dart's compiler is optimized more. Readable, debuggable JS is a high priority for Dart's Dart->JS compiler.
- azakai 15y ago
  > Also, the VM wouldn't be required, it would just provide performance improvements. I'm curious, is this true? Last I heard, Dart-in-JS didn't enforce types, so integer math could overflow into doubles for example, but the Dart VM did use native types (so ints would not overflow). So the semantics of the language differ in JS and in the native VM, which means the VM doesn't just provide speed, it provides different behavior. Is this no longer the case - are the semantics of Dart-in-JS and in the VM exactly the same?
  - adgar 15y ago
    Disclaimer: I work for Google. JavaScript doesn't have integers. I suspect that the Dart VM will support integers with overflow. So yes, I suspect in that case they are different. I also strongly suspect this will not be a significant edge case in practice: if you use integer types in your dart code, then you clearly don't want doubles to result from a calculation. So the only unexpected "surprise" you would encounter there is if you expect integer overflow but get doubles. If you are writing code that expects integer overflow to happen a certain way, you're doing it wrong. If you're writing code that doesn't expect integer overflow, and you want integers, then you're going to be fucked either way. Either you end up with doubles and type errors or an overflow and your result is wrong. Changing things as entrenched as JavaScript while maintaining backwards compatibility is messy and hard. Especially given some of the horrible characteristics of the language. I'm glad someone's at least trying.
    - azakai 15y ago
      > JavaScript doesn't have integers. I suspect that the Dart VM will support integers with overflow. So yes, I suspect in that case they are different. [..] I also strongly suspect this will not be a significant edge case in practice [..] If you are writing code that expects integer overflow to happen a certain way, you're doing it wrong. It's a valid position to say that relying on integer overflow in one's Dart code is "wrong". But you will need to carefully educate coders about that, since relying on overflow is common in popular languages like C and C++. This won't be easy. Another big worry is that this could lead to very hard to diagnose bugs. Having the native VM and the compiled code have different semantics in subtle ways is risky - unintended overflows will lead to different bugs in different cases. Also, integer overflow is not the only case where this problem arises. It also happens with say division of an integer. Will Dart compiled code in JS add proper rounding correction to all divisions of integers? Or will this be another case where the VM differs from compiled code? Overall, it seems much simpler and safer to just correct overflows in the compiled code. > Especially given some of the horrible characteristics of the language [JavaScript] It's fine if you don't like something of course, but I don't think calling languages "horrible" is going to lead to a productive discussion.

kodablah 15y ago

But those languages aren't a significant deviation and still require pre-compilation as opposed to runtime cross-compilation to be useful. Dart is a significant deviation and expected to support debugging directly in the language. Similar to developing in GWT, I doubt the JS will really be looked by the developers at once Dart's compiler is optimized more. Also, the VM wouldn't be required, it would just provide performance improvements.

gcp 15y ago
Dart is a significant deviation and expected to support debugging directly in the language. This can be done for CoffeeScript et al too - efforts are already underway. Also, the VM wouldn't be required, it would just provide performance improvements. There's just too much embrace-extend-extinguish risk for anyone but Google in that. That's why Mozilla and Microsoft are burning it at the stake.
munificent 15y ago
> Similar to developing in GWT, I doubt the JS will really be looked by the developers at once Dart's compiler is optimized more. Readable, debuggable JS is a high priority for Dart's Dart->JS compiler.
azakai 15y ago
> Also, the VM wouldn't be required, it would just provide performance improvements. I'm curious, is this true? Last I heard, Dart-in-JS didn't enforce types, so integer math could overflow into doubles for example, but the Dart VM did use native types (so ints would not overflow). So the semantics of the language differ in JS and in the native VM, which means the VM doesn't just provide speed, it provides different behavior. Is this no longer the case - are the semantics of Dart-in-JS and in the VM exactly the same?
- adgar 15y ago
  Disclaimer: I work for Google. JavaScript doesn't have integers. I suspect that the Dart VM will support integers with overflow. So yes, I suspect in that case they are different. I also strongly suspect this will not be a significant edge case in practice: if you use integer types in your dart code, then you clearly don't want doubles to result from a calculation. So the only unexpected "surprise" you would encounter there is if you expect integer overflow but get doubles. If you are writing code that expects integer overflow to happen a certain way, you're doing it wrong. If you're writing code that doesn't expect integer overflow, and you want integers, then you're going to be fucked either way. Either you end up with doubles and type errors or an overflow and your result is wrong. Changing things as entrenched as JavaScript while maintaining backwards compatibility is messy and hard. Especially given some of the horrible characteristics of the language. I'm glad someone's at least trying.
  - azakai 15y ago
    > JavaScript doesn't have integers. I suspect that the Dart VM will support integers with overflow. So yes, I suspect in that case they are different. [..] I also strongly suspect this will not be a significant edge case in practice [..] If you are writing code that expects integer overflow to happen a certain way, you're doing it wrong. It's a valid position to say that relying on integer overflow in one's Dart code is "wrong". But you will need to carefully educate coders about that, since relying on overflow is common in popular languages like C and C++. This won't be easy. Another big worry is that this could lead to very hard to diagnose bugs. Having the native VM and the compiled code have different semantics in subtle ways is risky - unintended overflows will lead to different bugs in different cases. Also, integer overflow is not the only case where this problem arises. It also happens with say division of an integer. Will Dart compiled code in JS add proper rounding correction to all divisions of integers? Or will this be another case where the VM differs from compiled code? Overall, it seems much simpler and safer to just correct overflows in the compiled code. > Especially given some of the horrible characteristics of the language [JavaScript] It's fine if you don't like something of course, but I don't think calling languages "horrible" is going to lead to a productive discussion.