ECMAScript 2018: final feature set | Hacker News Reader

ECMAScript 2018: final feature set

2ality.com

183 pointsGarbage109 comments

I'm not sure about this named capture group proposal. The idea behind the proposal is that regexp engines parse using the old grammar, but if a GroupName is found, re-parse using a different grammar:

If the result of parsing contains a GroupName, reparse with the goal symbol Pattern[~U, +N] and use this result instead.

But "the result of parsing" by definition cannot contain a GroupName because GroupName is not part of the initial grammar.

Furthermore it appears that the named capture group backreference syntax `\k<groupname>` is in fact valid under the "old" (no-named-capture-group) syntax. Thus the interpretation of `\k<groupname>` depends on the future parts of the expression, similarly to how `\3` can be an octal escape or a backreference depending on the rest of the expression.

JS regexp parsing is already underspecified [1] and requires two passes to disambiguate backreferences from octal escapes. Now it appears we potentially need a third pass to disambiguate named capture groups.

[1]: https://blogs.msdn.microsoft.com/ie/2010/08/25/chakra-intero...

A quick summary of what's new:

* Asnyc Iteration: Looping over async lists, e.g, reading lines from file or an async generator.

Allows code like:

  for await (const x of asyncIterable) { foo(x) }

* Spread/Rest (`...`): Makes FP easier.

  const a = { foo: 1 }
  const b = { bar: false, ...a }
  // b is { bar: false, foo: 1 }

Works on arrays (spread operator for literals) or objects (rest operator for destructuring)

* RegEx features like named capture groups

* `Promise.prototype.finally()` - Callback function is always executed, regardless of what promise returns.

I honestly thought object/array spread/rest were already in ES2017. Maybe it's because I'm in my own little Babel/React world. I literally just had to stop and go create-react-app and see if that specific use of rest/spread works and it does. Then I went to babel's docs and found it's part of TC-39.

Maybe this is meta, but I wonder what it means for us in this ecosystem. Some of us have totally lost touch with whether the language features we use are supported by the runtime, or are even "canon". Right now I'm probably using a bunch of language features in different projects that are still proposals. I have a few handwoven .babelrc's in different projects that use all manner of things.

I'm almost 40 now and looking back on my programming career, what we do with JS and language features is truly bizarre.

Yeah, most people don't keep track of what features are "legitimate/standard" and which are not.

It's even more problematic because some influential figures in the community push those non-standard features and encourage people to use them. Some are pretty harmless (object spread back when it wasn't standard), some are PROBABLY okay (class field declaration, pushed very hard in the React community because the ES6 class syntax with React kind of suck without it and they pushed THAT too early).

Some, however, are downright dangerous, such as decorators (pushed pretty hard in the MobX world) or bind operator (used to be pushed in the RxJS community, though not as much lately with pipeable operators). Those things are not standard, and in the case of decorators, the version being pushed doesn't even match the latest proposal. These are the stuff of tech debt nightmare when used at scale. Yet most people using them have no idea what kind of hole they're digging themselves into, and it's hard to blame them. Can't really keep track of all of that when you have deadlines to meet.

In other ecosystems you'd just use a language with features that you prefer, since you can't do that in a browser environment transpilers came along to fill the gap. It doesn't seem bizarre at all, it seems like a giant hack taken to the extreme, which is pretty common thing in the programming world.

"Right now I'm probably using a bunch of language features in different projects that are still proposals. I have a few handwoven .babelrc's in different projects that use all manner of things."

This is one of the main reasons why I am increasingly interested in TypeScript: it gives you more features than JS, but in a way that is consistent and manageable between projects.

It seems inevitable at this point that any large project is effectively going to be using a particular flavour of JS, with language or library extensions.

Typescript has been very good at sticking to Stage 3 proposals likely to be adopted by browsers, and providing "off ramps" if the specs change between Typescript implementation and browser adoption. (For instance, Typescript module syntax still recognizes a predecessor to ES Module import/export syntax, but it provides good warnings for the out-of-date syntax and between Typescript strict modes and tslint warnings as errors you can very quickly migrate a project over to the standard syntax.)

The async iterators look very powerful to me. That's essentially Streams/Rx Observables right in the language, amirite? Pretty cool, and feels very lightweight. Like, an async generator is how you can write a map/filter/etc over existing streams (eh, async iterators), seems quite nice.

But I bet I'm missing something important. Rx is pretty huge and it looks like this feature isn't really. Does anyone know more, from the trenches? What are the downsides? Does Babel compile it well? Are all important use cases covered?

We have had async iterators in python for a short bit now, they're truly an awesome feature for evented code. (I don't mention that as a flamewar, simply to confirm that the concept of async iterators is awesome and powerful).

Async Iterators are orthogonal to Streams/Rx Observables. Async Iterators are async "pull" operations (think disc I/O; pulling data record at a time from disc) and Streams/Observables are async "push" (think events like mouse clicks).

They work great together, using each's strengths to specific needs in an application.

Additionally, a lot of the weight of Rx is its large set of "higher order functions" beyond the basics of map/filter/reduce. Similar higher order functions are possible for async iterators. One such library for that is Ix, maintained by some overlap with the Rx team, and maintaining some consistency in operator names and APIs.

I've been using Async Iterables fairly heavily lately in an application in combination with Rx-like Observables (using the xstream library, rather than Rx) and Ix operators. I've been letting Typescript do all the downlevel compilation, and have been pretty happy with it in the use cases where I've been using it.

Hmm I don't follow. Wouldn't a generator function producing async iterators be "push"? Without any Rx involved?

I mean, ever since JS got generators, it has support for unlimited length iterables. Isn't an unlimited iterable of promises precisely what you describe as a push stream?

I didn't dive deep, but I do believe I was able to cook up a generator function that produces an async iterable of mouse events. It was able to `for await` it and console log the event data.

Certainly there are overlaps in what you accomplish with both technologies, and the push/pull analogy isn't necessarily the best analogy to explain the distinction, but it's the best one I currently have.

Async Iterators/Generators are seen as "pull" because your "main thread" has to actively consume it (you `for await` results), whereas with Rx Stream/Observables your "main thread" passively subscribes to updates.

It probably still seems like a semantic distinction at that, especially as you can relatively easily convert between them. However, a lot of the big differences come down to how each technology deals with A) pressure (lots of items/events), and B) scheduling "intermediate" work (iterables do more work on the "main thread"; streams/observables are better at/have more tools for chunking work on a scheduler/thread pool outside of the "main thread").

Which is also why JS isn't exactly the best language to discuss the differences between async iterators and streams/iterables, because a lot of those biggest differences/distinctions aren't very important in mostly-single-threaded browser JS, which is its most common problem domain.

Have been using the spread operator via Babel for several months now. It's definitely convenient - saving me from writing several extra lines of code.

I worry that spread operators make code less readable. You really have to squint and think more when confronted with one.

They also make your code less understandable to a beginner, or people coming from other languages.

One of my favorite ways to use them:

  const foo = {};
  if (bar) {
    foo.bar = bar;
  }

Turns into:

  const foo = {
    ...bar && {bar},
  };

That's a good example of Abad use of the feature. The logical check and assignment are obvious, and represent the same two operation that three or more nested operations in spread and combine end up causing implicitly. If I saw anyone do that at work, I'd have a chat with them. This is on the same level the newlinephobia.

Some parens would at least make that more readable:

    const foo = {
      ...(bar && {bar}),
    };

… Wouldn't

    const foo = bar ? {bar} : {};

be both more efficient and more readable?

Well typically there are more parameters being set than just the one.

Not nearly as abusive as

    const obj = {
      foo: 1,
      bar: 2
    };
    const propToDelete = "foo";
    { [propToDelete]: _, ...newObj } = obj;
    newObj;  // { bar: 2 }

but will probably be more performant than `delete` in the long run.

Warning; a few weeks ago I ended up in a debate with a co-worker and ran the performance tests on this construct. Turns out that you would be better served by ```foo.bar = bar``` since nodejs doesn't give you the performance you expect.

Why?

if you really want to write shorter code, try

const foo = {};

foo.bar = bar ||undefined;

All I want is a datetime literal: #2018/01/31 17:00:21.2234233#.

I don't even care that it isn't backwards compatible. Eventually platforms will catch up... so the sooner it's added the sooner everything will catch up.

Is that because you want date/times in JSON? Shouldn't it include a timezone, and maybe implement ISO8601?

2 things I want in JSON:

1. Datetime

2. Expand the encoding to escape '<' and '>'

Being able to specify a datetime as local vs utc would also be nice... so "2018/01/31 17:35:21.2222Z" for UTC and "2018/01/31 17:35:21.2222" for local.

As to the actual format used... that it's just a bikeshed argument waiting to happen. I picked y/m/d for no particular reason (well... other than my ancient preference for a simple sort key). I also picked 24 hour time for no particular reason (well... other than my ancient preference for a simple sort key).

No one would really care too much one way or another what the format was (so long as it was easy to generate using common server side technologies... node, php, java, .net).

You can use Unicode escapes for < and > if you need them to be escaped. (Which is unfortunate, but defense in depth I guess.)

It might be nice to transfer dates as a separate type from string. But for the love of FSM, use ISO 8601 as the format! [1]

1: https://xkcd.com/1179/

Putting it into ES won’t change the JSON standard though.

Wouldn't it have to? It does stand for JavaScript Object Notation after all.

That's where the idea came from. But it's now a completely standalone standard, with its own grammar, that just happens to be compatible with a subset of ES.

Even that's not technically true. You can represent things in JSON that can't be represented in ES object literals. There's a proposal in Stage 3 to fix that though: https://github.com/tc39/proposal-json-superset

This question seems reasonably sincere enough that you could attempt to answer it rather than downvote it.

It wouldn't... but it could open the door to updating the standard.

TC39 has a pretty open process for proposals, so you can help. But “not backwards compatible” won’t fly. “Don’t break the web” is a key part of TC39’s thinking

Haven't they already given up on backwards compatibility with things like => and for..of?

Those are additive, they don't affect the semantics of code that was written before they were added. That is what is meant by backwards compatibility here - you never need to change existing code because of new features.

before es6 anything added also did not break existing implementations. eg you could run es5 features in a es4 engine using polyfill and progressive enhancement/degression. maybe its time for ES to add meta and overloading - although with a huge cost of complexity !?

No? They're both backwards compatible.

I understand JS was an experiment and that there was much to add to make it a proper language, but isn't it good enough now? Can we expect the pace of changes to slow down (specially in light of WebAssembly)? I'm not a JS developer and/or language developer, honestly just curious.

WebAssembly doesn't really have anything to do with Javascript. As for being good enough now: not yet. It's getting closer, another iteration or two and I think it could settle down for a while. Also it's worth noting the rapid pace of change in the JS specs is a recent phenomenon. It was stagnated for years before that.

WASM-compiled code might completely replace javascript, being faster at all stages: loading, parsing and execution. That's probably the point he was making.

WASM compiled code doesn't improve upon the use of javascript as a scripting language, only javascript as 'bytecode.' I don't think WASM would replace javascript in those cases, unless you could drop another language into a script tag and have it work as easily for basic DOM manipulation, which people still do.

That’s true, but the vast majority of web sites today are already compiled applications.

I think "vast majority" is an overstatement, unless you're counting by popularity and not sheer numbers.

I also don't consider a website serving machine-generated javascript to be a "compiled application" analagous to a C, Flash or Java binary (whereas WASM would be,) but almost every time I try to go down the "javascript is not machine code or bytecode" rabbithole, I get downvoted to oblivion.

i find it amusing when a lower level lang compiles to a higher level. but i still think its the right word. another word is assembled when assembly goes into machine code.

Vast majority? Do you have data to back that up? I'd bet the data would show far below 10% of websites are compiled applications (I'd be shocked if it approached 5%).

When I say 'compiled' I'm abusing the term to mean they have any kind of build step, and could not be written the same way by dropping code into a script tag [1] as said in the parent comment. For the most part what comes out of the build process could be replaced with WASM at a whim, whenever it gains access to all the DOM and browser APIs.

The majority of news, social media, video, media sites, message boards, online games and web apps fit this description. I'd wager that 95%+ of websites produced by a paid professional today are in this category. Unfortunately no, I don't have data to back this up, only my perception as a web developer.

[1] due to relying on a module system, es6 transpiler, etc

Majority of top 1000 websites perhaps, most websites aren't compiled at all, they just link to jQuery on a CDN somewhere.

WordPress powers almost 30% of the others, and could also switch to WASM whenever they feel like it.

I don’t see JavaScript ever reaching a point where everyone involved agrees that is good enough. There are still too many conflicting opinions of what the language should be. The ecosystem’s constantly evolving libraries and frameworks also drive the language design, and new language needs are always emerging from these

I don't like the idea of considering a language "good enough" and here's why.

First off I must be careful and acknowledge that a language which changes at a pace faster than the body of programmers using it can safely absorb could be considered an anti-pattern. As it stands I'm not sure if JS fits this.

Look at how Java has changed over the years. Back when it was created the syntax was appreciated by many as resembling C++ enough and being OO enough to be "good". Obviously there were many nits to pick by purists but programmers adopted the language and many people touted it. Java did not become popular because non-technical people were pushing it. Programmers liked it well enough.

I was a religious zealot when it came to OO. Now I find myself loathing large OO systems and trying to write procedural functional code as often as possible and only using classes when necessary. The Java language has evolved to add lambdas, streams, etc.. Should Java have added lambdas or should it have stayed the way it was, "good enough"? Even if one is a programming paradigm zealot of any persuasion one must acknowledge that a great deal of production code was written just fine using only the early Java language features. Should we have stopped there?

If code should be written first and foremost for programmers to understand and only incidentally for compilers to then it should stand to reason: as our collective understanding of how to express the behavior of a computer program evolves, so should the language(s).

That makes a lot of sense, thanks for your thoughtful comment.

No. There's still lots of ongoing work. There's a repo [0] with proposals and the different stages they're in.

Why would WASM mean slowing down JS changes?

[0] https://github.com/tc39/proposals

Because people would start developing in other languages that target WebAssembly and demand less of JS today.

Competing options lowering demands? I think that only makes sense if something has lost market share to the point that it is not in use.

Most people that write JavaScript don’t care about any of these new features. They are developed by those on the cutting edge, for those on the cutting edge. Eventually, some of them become more widely used, occasionally even going mainstream. (We’ve seen a rash of that in the past few years.) If the technology leaders all switched to WebAssembly and no longer cared about JavaScript, JavaScript development would stall, and people that still wrote JavaScript would probably breathe a sigh of relief as their target stopped moving. (It could still regain momentum after such an event.)

It seems very improbable to me that this will occur in the next five years.

My two cents, JS has come a long way and should qualify as a "proper language" if it wasn't one before. Is it good enough? Is any language ever good enough?

As for the pace of changes, it's hard to tell. All the same, if TIOBE is to be believed, JS is getting more popular, not less.

JS still lacks support for 64-bit integers and BigDecimal support would be extremely nice. Otherwise I think the language is good enough.

Just in case anyone is not aware there is a stage 3 proposal [1] for 64 bit integers right now called BigInt [2].

[1]: https://github.com/tc39/proposals

[2]: https://github.com/tc39/proposal-bigint

JS is the language of the Web. The web is in constant flux. It is no surprise that the JS language will involve too.

If it’s not breaking backwards compatibility then what’s the problem with improvements?

Because these constant "improvements" usually mean two things:

1. The language design is flawed. That is, the desired functionality requires changes to the core language, because it can't be made from existing building blocks. The fundamental language constructs are not universal enough, so new functionality will always require "just one more" special case in the language itself.

2. People are shoving things into the core language, that should rather be implemented as a library/framework.

20 years ago I used JavaScript to make cute Neopets pages, but today I get asked about how to use it for scalable web services in job interviews. That’s kind of crazy to me! It’d be like if Google made a JIT for LOGO and we all went nuts blogging about using it for ORMs.

I think JavaScript’s core foundation is changing because its use cases have rapidly changed. Like C++ or PHP though, it likely has a lot of legacy cruft.

Are any Ruby experts able to chime in if its language/runtime changed much after Rails hit the scene?

#1 'use strict' already went a long way to disabling broken parts of the language without breaking backwards compatibility. While what you are saying can be true in general, I find many of the features are more of a design correction that happen to work along side the old flawed way. Take 'var' vs 'let' / 'const' as an example.

What will they use once people are mostly using strict, but the language isn't yet good enough (because the keyword is already there, but it still isn't a good language)?

Keep adding rules and break the compatibility of strict code, or forget about it and live with current problems forever?

“use very strict”

"use even stricter than very strict";

The language design is absolutely flawed, hence the push to make that less so.

What things going into core do you think should be a separate framework?

>The language design is absolutely flawed, hence the push to make that less so.

But a flawed language cannot be made non-flawed while keeping backwards compatibility... E.g. JS has now two different ways to write functions, with slightly different semantics.

>What things going into core do you think should be a separate framework?

An example would be async/await and generators, both which are just a special cases of coroutines. If JS would have coroutines, then these two would just be coroutine libraries.

> But a flawed language cannot be made non-flawed while keeping backwards compatibility

Sure it can. Just introduce new syntax and discourage use of old syntax, ideally with tooling. For example, `var` is disallowed by any popular lint config, and for most practical purposes, it doesn't exist in JS anymore. The execution environment will still handle it, but it's not an available option when writing code in any professional or non-professional project I work on (because it won't pass lint).

Plenty of languages do this: Java raw types, Python old-style classes, goto in lots of languages. Python actually did a breaking change to remove old features, and it's a good example of how breaking changes can cause much more trouble than you might expect.

> ...it's not an available option when writing code in any professional or non-professional project I work on...

That is surprising to me. I work with code that is more than a couple years old all the time and I would guess most people do to.

Yeah, it's a slight exaggeration to say that `var` is effectively not in the language anymore, e.g. I see it plenty when reading open source projects or Babel output. Keep in mind that ESLint can autofix `var` to `let` or `const` (except in some rare cases when it's unsafe), so even if you have a big legacy codebase, it's not hard to migrate completely away from `var` with very little time or risk. But it's true that you need to keep up with tooling for legacy projects, which happens to be the case for the stuff I work on, but may not be universally true.

> E.g. JS has now two different ways to write functions, with slightly different semantics.

Just 2? More like 9:

* function expression

* function declaration

* arrow function (single line, single param)

* arrow function (single line, multiparam)

* arrow function (multiline, single param)

* arrow function (multiline, multiparam)

* object shorthand

* class declaration

* class expression

It's not just syntactic differences either: they behave differently with regard to whether they're hoisted and the value of this.

> An example would be async/await and generators, both which are just a special cases of coroutines. If JS would have coroutines, then these two would just be coroutine libraries.

async/await could be implemented with just generators, and were so implemented in ES6; async/await was added to the language because it was convenient. A language without full coroutines is fine.

It obsoletes older browsers. For a while it used to be you could browse the web with almost anything, even a 10-year old Netscape. Now it's the norm that a 4 year old browser isn't supported, because of new APIs and JS syntax.

Why do people like you feel that's acceptable? Software can work from anywhere between a few hours to a decade before an update is required, and it entirely depends on what you're doing.

Websites evolve, and that's the choice of developers around the world. You have no right to complain if you don't keep your software up to date to a reasonable level.

If you want to use 4 years old software, you MUST accept things are broken and that it's your fault. Try downloading Firefox 1-10 and see if they work today ;)

I'm not necessarily against forcing upgrades because it comes with advantages, but I was explaining the tradeoff. It's one good thing about Apple and if say, domestic power outlets could change every few years, we could get higher voltages, DC, built in networking, more compact connectors, metering features, etc...

But if everything operated like the web ecosystem, we might consume 100% of our time and money just on upgrades.

And it pretty much guarantees there will only be a handful of vendors, because it's very expensive to stay current.

> Software can work from anywhere between a few hours to a decade before an update is required

All other things being equal, a decade is preferable because time/attention is valuable. Frequent and in particularly non-careful updates can put individuals and in the grip of a form of the red queen problem rather than being able to spend time/attention on new levels of capability.

I don't particularly mind some obsolescing of browsers where JS is concerned, and browsers in general have done a remarkable job of retaining backward compatibility.

More problematic, though, is the attitude that's more or less every website should be a JS-powered (or, in the future, web-assembly) SPA without any kind of back-end fallback for user agents that don't support it, thus making JS capability the bar for any UA. That's short-sighted, doesn't consider user conditions outside of a narrow range of experience, doesn't consider that there might be user agents other than browsers as commonly understood. If that's all you have the resources to do and how you choose to spend them, that can still be reasonable engineering (though my experience is the benefits of figuring out how to make it work w/o JS first -- if it's possible -- often pays engineering dividends), but I think it's weird it's the default now.

> Try downloading Firefox 1-10 and see if they work today ;)

Firefox 1-10 would be broken because they're embedded in a set of assumptions about specific non-web platforms, not because many (if not most) websites couldn't reasonably support them as clients. I don't see any reason to import the shortcomings of non-web platforms into the web.

My view is, if everyone was on an evergreen browser (and didn't do something like turn off the auto updates) then there would be no such thing as a 4-year old (or even 1-year old browser). If I could wave a magic wand I'd have 100% of websites all using cutting edge HTML, CSS, JS features tomorrow so the WWW absolutely breaks for anyone not using an up to date evergreen browser (the lone exceptions being the download pages for Firefox, Chrome, etc.). The sooner businesses, Luddites and grandpas upgrade the better. But that's just my view as a developer who is so sick and tired of supporting browsers that have been out of support for years.

Your view excludes all platforms made before "evergreen browsers" became a thing and will exclude all platforms which the makers of "evergreen browsers" deem too small or unprofitable to support.

So thanks, but no thanks. There is enough of planned obsolescence already, no need to add another weapon to the arsenal.

If you haven't updated your browser for four years then you've got a hell of lot more to worry about than if javascript works correctly.

New syntax can obsolete older browsers, but it doesn't necessarily have to in the age of Babel and Typescript.

Babel can already translate ES2018 async iterators and rest/spread into ES5 code that works pretty much everywhere.

If you are using babel there is no need for the new browsers to support the new syntax at all.

Sure there are. For example, your bundle size shrinks when targeting newer browsers because more features exist, fewer need to be polyfilled.

Then you must prepare two bundles, one for new browsers and one for old. I suppose that's possible, but doesn't seem worth it.

You can use <script type=module> to target newer browsers. It’s definitely worth having two bundles because the ES6 and newer is much smaller. And one day, you stop shipping the old ES5 bundle.

It is worth it most of the time.

That 4 year old browser is full of security holes though. Why would anyone want to encourage that?

The more there's featues, the harder it will be to create new independent implementations, which is not good for openness/competition. The bar is already too high.

Why stop adding new useful features? What actively used high level language has done that?

>> Can we expect the pace of changes to slow down?

> Why stop adding new useful features?

No actively used languages that I know of have stopped adding features.

Compared to ES5->ES6, I think these yearly bite-sized updates have indeed made it slow down and be much more manageable

LISP

Lisp is a family of languages, there hasn't been a single Lisp language since the 1960s. The different dialects of Lisp add new features.

However, the major ANSI dialect hasn't changed since 1994, so OP has a fair point.

Common Lisp is a standard, but the various implementations of that standard have added non-standard features. For example, I believe Unicode support was added to SBCL around 2004.

    RegExp Lookbehind Assertions

Finally... I've had to lookaround it's absence too many times.

I've always been baffled by the absence of lookbehinds. Made a lot of regex searching unwieldy, so I'm glad they finally added it together with named capture groups.

I couldn’t immediately see any proposals for list/set/object comprehensions at https://github.com/tc39/proposals, are there any?

I don't think those are happening, but how about basic set arithmetic? The fact that you can't do difference / union / intersection using the standard library is frustrating.

There's a proposal for that.

Two of them now. One to add Set-specific methods, and another to port the usual Array.prototype methods over to Set and Maps. Can't wait!

https://github.com/tc39/set-methods https://github.com/tc39/collection-methods

Unlikely. Mozilla had extensions which they submitted for ES6 IIRC (lists and generators) but it seems the tc39 preferred going with HoFs instead.

Thanks. On the face of it it seems a bit of a shame to me. My experience writing python daily (since before dict and set comprehensions were introduced) is that the comprehension syntax is used extremely commonly in a large codebase and that the way that you can specify both the transformation and the filtering in a single comprehension is much more readable than composing a map and a filter.

Thank you so much for "finally"!

WASM will eventually completely replace the need to use JS for any web development. That will be a good day.

Are there polyfills available for any of this?

You generally can't polyfill an operator or things that require changes to language parsing, but you can run it through a transpiler like Babel so it converts everything to an earlier version like ES5 with more widespread and stable feature support.

The Rest and Spread operators are interesting, I think they're cool syntactic sugar and they've got reasonable use for some types of functional programming, but they feel like a ticking time bomb. It doesn't exactly promote resilience if objects are being passed around many different contexts. It seems like it promotes clunky boilerplate checks over more explicit logic

Funny how the "final feature set for 2018" is nailed near enough Feb 2018.

Call me stupid, when I'll get whiteboard tested on these shiny new concepts, but I really don't (and you shouldn't also) give a rats ass about all of this.

Reply on news.ycombinator.com