ES6, ES7, and beyond (opens in new tab)

Yeah, I won't try to speak for Eric or the SpiderMonkey team. Maybe Eric is firmly in support of STC, but in my experience he's very good at going beyond just implementation concerns and considering all the design constraints (one of which is the cost/benefit analysis of new syntax to the user model). IMO the important question isn't who supports what but what's the best outcome. AFAICT, all three of PTC, STC, and no tail calls are on the table, but there's more hashing out to be done.

Your new wording seems totally fine -- sorry if I was pedantic, and I'm really not bent out of shape about your blog post. I just want to be sure that people don't get confused about where things stand. New features such as STC require time to bake (which is part of what the multi-stage lifecycle for proposals is all about) -- I only meant to clarify the state of the discussion.

Edit: Grrr, re-reading this it still feels like I'm speaking for Eric. He's his own guy, I should shut up about his position! All I mean to say is, I don't think anyone should be staking out strong positions at this point in syntax design. The design process is iterative and uncovers new constraints and effects, and we should all keep open minds and work collaboratively. I'm open to all possible outcomes: PTC, STC, no tail calls at all. Tricky space!

I'm not on TC39, but I sit next to and work closely with people who are, and my understanding (confirmed by this article) is that the primary concern is about stack traces of existing code, specifically code with function calls in tail position.

With implicit tail call elimination, those stack traces will change in non-trivial ways that could affect debugging processes or break existing tools.

I've also heard some concerns about implementation difficulties, but I know at least one major engine has implemented PTC as specified in ES2015 without issue. I think (and hope) these concerns are secondary to the discussion about stack traces and backwards compatibility.

tl;dr: as with almost every "why is it like that" question about JavaScript, the answer is "because backwards compatibility".

(I also started with Lua and have adjusted to JS over the years; they have more in common than many people realize!)

As the article pointed out, the ternary operator, lambdas, and &&/|| make it easy to miss a tail call. I tend to agree with you - the later will see reduced use with named arguments while optimizing for the former doesn't make much sense.

Unicode properties are behind an experimental flag: --harmony-regexp-property

I do support the addition. It's an useful feature. Just couldn't stop myself :).

Transformation of most ES6 features into functionally identical, backwards-compatible ES5 is trivial, and automated tools exist to do that, so you absolutely can use them today.

For example, default arguments are purely syntactic sugar for `if (arg === undefined) { arg = x; }` in the first line of a function. Still, I'd much rather write ES6's declarative `function foo(arg=x) { }` syntax rather than imperatively implement it in ES5 each time I need it.

> windows still 90% of the market

Of all the people on the web, or target audience of your website, or what market?

Right, thank you

> so that tech recruiters confuse it with something else

At least if a recruiter starts asking you about your Eczema experience, you can more easily determine that the screening process has gone off the rails.

That would be incorrect though, there are other implementations of the ES specification that are not JavaScript (UnityScript for example).

Although it's a cute suggestion.

Exactly why we should avoid more extensions. I don't see what's wrong with a config, either package.json or System.global

Good catch, I stand corrected.

I'd think there are plenty of reasons to give software an air of "out-of-date"-ness. In this particular example, its a stigma to browser developers if it takes them until 2023 to implement ES2015.

It's a common thing in language standards to version by the year the standard was ratified, especially for ANSI languages such as C and C++, but there's a long history of it in language design including the ur-example off the top of my head of ALGOL68.

As for Windows 98. Would you seriously with a straight face want to admit to using a version of Windows that is old enough to vote? If anything, it's too bad they stopped that pattern with XP as it would have been a lot easier to shame people for still using Windows 2001 in 2015.

As I understand the reason they switched to the year based naming is because they plan to do yearly standards now, switching to a release date based model rather than a feature based model. C++ has kind of switched to this model too, where features that are ready to go for the release date are included, and ones that aren't quite baked enough will not hold up the release, to help avoid an ES6 type situation where the committee works for years and years without releasing an update.

So it's not that standards become out of date, especially as in both Javascript and C++'s case, the standards are generally additive. They just add stuff so your old software should continue to work and will not become "out of date".

Anyway, that's the reasoning I've been given behind the change and it makes sense to me. Hopefully that answers the question for you as well.

How about C++?

C++03

C++11

C++14

C++17

Ubuntu?

16.04

13.10

9.04

THAT is truly disappointing. Of all the new features, async/await is possibly the most critical for improving readability of code.

It's even more of a step forward than Promises was.

Yes, be more specific, but also there's no point in posting it here. Email the site maintainer to let them know, HN is not a tech support forum or a bug tracking system.