6 ms·

That's what Go does. The reference of the language is [an actual document](https://golang.org/ref/spec https://golang.org/ref/spec), not a reference implementat

That's what Go does. The reference of the language is [an actual document](https://golang.org/ref/spec https://golang.org/ref/spec), not a reference implementation. There are two compilers (gc and gccgo), and this way, no edge-case of an implementation can make its way into programmers' habits, something that tends to happen a lot with JavaScript.

jdmichal 11y ago
Microsoft was surprisingly open in this regard with C#. The C# language and the CLI bytecode are both ECMA standards (334 and 335) that could be implemented by anyone. Of course, this is with the realization that the .NET standard library gives Microsoft's C# implementation a lot of staying power.
swang 11y ago
What do you mean by the, "edge-case of an implementation... makes its way into programmers' habits" as something that happens a lot in javascript. Maybe I'm not understanding but I read that statement and I don't see how that applies to javascript.
- Klathmon 11y ago
  For example, a try/catch in V8 triggers deoptimization for the entire function it's in, while it might not in other engines. So this leads to many developers avoiding try/catch in performance critical code. This ends up with them avoiding it in general usage, which means that now "avoiding try/catch" is considered a general purpose performance tip in javascript, even though it might only apply to one engine (and the v8 team has expressed interest in trying to stop that deopt) This might be a bad example, i'm honestly not sure how try/catch performs in other engines, i just know it deopts in V8. But the fact that i don't know if it's a javascript thing or a V8 thing speaks to my point.
  - louislaf 11y ago
    It is a good example actually. Chakra does fully optimize functions with try/catch. Caveat: we don't optimize try/finally yet... Disclaimer: I work for MSFT on Chakra.
  - bzbarsky 11y ago
    try/catch has pretty much no runtime overhead in SpiderMonkey unless an actual exception is thrown. So yes, this is an excellent example.
- dsp1234 11y ago
  Since node.js is backed by V8, optimization decisions that the V8 team have made end up in developer code that runs in node.js. For example, Bluebird has a list of "optimization killers"[0] that many developers that I know use as a reference when making node.js libraries. However, these optimizations are V8 only, and so "edge-case of an implementation makes its way into programmers' habits". A quick example is "5.1. The key is not a local variable:", which ends up with having to jump through some hoops in a for-in loop, not because it's easy or because the language forces it, but just because V8 is the engine. [0] - https://github.com/petkaantonov/bluebird/wiki/Optimization-killers https://github.com/petkaantonov/bluebird/wiki/Optimization-k...
  - mraleph 11y ago
    > optimization decisions that the V8 team have made Optimization decisions that V8 team have made are much more universal than it might seem. It is true there are sometimes strange artificial corner cases - but those are often either bugs or temporary solutions that are going to be replaced with something more generic as soon as they start to hurt too much code. > which ends up with having to jump through some hoops in a for-in loop Could you clarify which hoops precisely do you need to jump through? I am not sure I can imagine a reasonable chunk of code that strives to be both fast, well written and wants to use a context captured or global for-in variable. for (IWantThisVariableToEndUpOnGlobalObject in obj) { } How often do you write code like this?
    - dsp1234 11y ago
      Optimization decisions that V8 team have made are much more universal than it might seem. That's certainly possible, but maybe a competing VM can do better, but finds that everyone has coded specific V8 optimizations. They may be hesitant to push out their implementation. It may be a better optimization, but it causes existing code to run slower on their VM. Thus back to the original statement that implementation quirks find their way into developer code. for (IWantThisVariableToEndUpOnGlobalObject in obj) { } The variable has to be in the local scope and can't be in any higher or lower scope, not just a global scope (which your words acknowledge, but your code snippet doesn't). It's easy to end up sending the prop variable through a closure accidentally. Some real world examples[0][1][2]. Note that the solution requires pushing out to another function just to get around the deopt. With the sproutcore example being very clear, as they made the change specifically to satisfy the V8 VM. [0] - https://github.com/paperjs/paper.js/issues/466 https://github.com/paperjs/paper.js/issues/466 [1] - http://www.html5rocks.com/en/tutorials/performance/mystery/ http://www.html5rocks.com/en/tutorials/performance/mystery/ [2] - https://github.com/sproutcore/sproutcore/blob/master/CHANGELOG.md https://github.com/sproutcore/sproutcore/blob/master/CHANGEL... (search "Removes V8 "ForIn is not fast case" warning")
mintplant 11y ago
Is this another [1] standard language feature that's being chalked up to Go now? Everything old is new again. [1] The first being statically-linked binaries.
- deleted 11y ago
  [deleted]
- addicted 11y ago
  Didn't JavaScript already have a reference spec going back at least a decade? I mean wouldn't a reference spec be a prerequisite for JavaScript becoming an ECMA standard?
- bmarkovic 11y ago
  If I'm not mistaken, the case with statically linked binaries in Go is more of a "It's not a bug, it's a feature" situation than being touted as Go invention. Besides, they are rectifiing that one if I'm not mistaken.

jdmichal 11y ago

Microsoft was surprisingly open in this regard with C#. The C# language and the CLI bytecode are both ECMA standards (334 and 335) that could be implemented by anyone. Of course, this is with the realization that the .NET standard library gives Microsoft's C# implementation a lot of staying power.

swang 11y ago

What do you mean by the, "edge-case of an implementation... makes its way into programmers' habits" as something that happens a lot in javascript. Maybe I'm not understanding but I read that statement and I don't see how that applies to javascript.

Klathmon 11y ago
For example, a try/catch in V8 triggers deoptimization for the entire function it's in, while it might not in other engines. So this leads to many developers avoiding try/catch in performance critical code. This ends up with them avoiding it in general usage, which means that now "avoiding try/catch" is considered a general purpose performance tip in javascript, even though it might only apply to one engine (and the v8 team has expressed interest in trying to stop that deopt) This might be a bad example, i'm honestly not sure how try/catch performs in other engines, i just know it deopts in V8. But the fact that i don't know if it's a javascript thing or a V8 thing speaks to my point.
- louislaf 11y ago
  It is a good example actually. Chakra does fully optimize functions with try/catch. Caveat: we don't optimize try/finally yet... Disclaimer: I work for MSFT on Chakra.
- bzbarsky 11y ago
  try/catch has pretty much no runtime overhead in SpiderMonkey unless an actual exception is thrown. So yes, this is an excellent example.
dsp1234 11y ago
Since node.js is backed by V8, optimization decisions that the V8 team have made end up in developer code that runs in node.js. For example, Bluebird has a list of "optimization killers"[0] that many developers that I know use as a reference when making node.js libraries. However, these optimizations are V8 only, and so "edge-case of an implementation makes its way into programmers' habits". A quick example is "5.1. The key is not a local variable:", which ends up with having to jump through some hoops in a for-in loop, not because it's easy or because the language forces it, but just because V8 is the engine. [0] - https://github.com/petkaantonov/bluebird/wiki/Optimization-killers https://github.com/petkaantonov/bluebird/wiki/Optimization-k...
- mraleph 11y ago
  > optimization decisions that the V8 team have made Optimization decisions that V8 team have made are much more universal than it might seem. It is true there are sometimes strange artificial corner cases - but those are often either bugs or temporary solutions that are going to be replaced with something more generic as soon as they start to hurt too much code. > which ends up with having to jump through some hoops in a for-in loop Could you clarify which hoops precisely do you need to jump through? I am not sure I can imagine a reasonable chunk of code that strives to be both fast, well written and wants to use a context captured or global for-in variable. for (IWantThisVariableToEndUpOnGlobalObject in obj) { } How often do you write code like this?
  - dsp1234 11y ago
    Optimization decisions that V8 team have made are much more universal than it might seem. That's certainly possible, but maybe a competing VM can do better, but finds that everyone has coded specific V8 optimizations. They may be hesitant to push out their implementation. It may be a better optimization, but it causes existing code to run slower on their VM. Thus back to the original statement that implementation quirks find their way into developer code. for (IWantThisVariableToEndUpOnGlobalObject in obj) { } The variable has to be in the local scope and can't be in any higher or lower scope, not just a global scope (which your words acknowledge, but your code snippet doesn't). It's easy to end up sending the prop variable through a closure accidentally. Some real world examples[0][1][2]. Note that the solution requires pushing out to another function just to get around the deopt. With the sproutcore example being very clear, as they made the change specifically to satisfy the V8 VM. [0] - https://github.com/paperjs/paper.js/issues/466 https://github.com/paperjs/paper.js/issues/466 [1] - http://www.html5rocks.com/en/tutorials/performance/mystery/ http://www.html5rocks.com/en/tutorials/performance/mystery/ [2] - https://github.com/sproutcore/sproutcore/blob/master/CHANGELOG.md https://github.com/sproutcore/sproutcore/blob/master/CHANGEL... (search "Removes V8 "ForIn is not fast case" warning")

mintplant 11y ago

Is this another [1] standard language feature that's being chalked up to Go now? Everything old is new again. [1] The first being statically-linked binaries.

deleted 11y ago
[deleted]
addicted 11y ago
Didn't JavaScript already have a reference spec going back at least a decade? I mean wouldn't a reference spec be a prerequisite for JavaScript becoming an ECMA standard?
bmarkovic 11y ago
If I'm not mistaken, the case with statically linked binaries in Go is more of a "It's not a bug, it's a feature" situation than being touted as Go invention. Besides, they are rectifiing that one if I'm not mistaken.