> I'm not sure it's possible to move a project using Babel 5, async/await, generators and react to upgrade to Babel 6. I've spent hours on it.

Well, you're actually right. Babel 6 has had a lot of problems, particularly with async functions, but they are slowly being worked out. I think it's pretty clear at this point that it was released too early, and they really need smoke tests to prevent this kind of problem in future. If you've already built a significant project using Babel 5, definitely consider holding off the upgrade for another month or two.

The funniest problem I ran into is that in Babel 6 using `typeof` does not work. Had to rewrite all our code to use Lodash type helpers because it is an external dependency and doesn't go through our build stack. We need our shit to work in production and don't have time to wait for forever.

Bug hasn't been fixed in almost a month: https://phabricator.babeljs.io/T6644

You'd think something like a basic language feature wouldn't break when you update your compiler. I did. I was wrong.

Thank the gods of software gardening that we were only using typeof in five or so places.

It's kinda funny actually. I remember the oft quoted maxim regarding very mature static languages: "It's never the compilers fault". This was obviously a hyperbole, but it held true most of the time. These days, the definition of "compiler" has gotten extremely loose on the web side, and it seems like correctness has gone by the wayside.

That's always been the case with fast-growing technologies. I remember finding a disturbing number of bugs in Java 1.3 c. 2000; if you ask Swift programmers today about the stability of the compiler, they could tell you all about compiler crashes & bugs.

If you want stability, use a technology that was popular 10 years ago. If you want to work on the bleeding edge, you will be bleeding. Decide what's appropriate for your project. The reason people worked in Java in 2000 or Swift/Babel today is so they can take advantage of temporary market opportunities where other people get deterred by the pain of capitalizing on them. This can be very financially lucrative if you yourself are willing to put up with that pain.

This reddit thread offers some pretty interesting / convincing speculation on Craig Wright's scam - https://www.reddit.com/r/Buttcoin/comments/3web4s/some_more_...

IRHydra2 is pretty good for it but has a learning curve.

There is really no need for the arguments object in a world with default and rest parameters, and it has always been an obstacle to performance, so I'm glad arrow functions don't use it.

It's not so much that arrow functions "don't use it" that I'm complaining about but rather that they change the meaning and thus have confusing results.

Also, changing that example to use rest parameters:

    function foo() {
      const bar = (...abc) => {
        console.log(abc);
        console.log(arguments);
      };
      bar('a', 'b', 'c');
    }

    SyntaxError: 'arguments' object may not be used in conjunction with a rest parameter

...which, okay, hmmm, it's sort of attempting to help me avoid confusion here. But that...was not what I was expecting. It's really weird that all of a sudden, just by adding a rest parameter to my function, a reference to `arguments` becomes invalid syntax.

Where are you finding that? This is what I get from Chrome:

    foo(1, 2, 3)
    // ["a", "b", "c"]
    // [1, 2, 3]

And this is what I get from https://babel.io/repl :

    'use strict';
    
    function foo() {
      var _arguments = arguments;
    
      var bar = function bar() {
        for (var _len = arguments.length, abc = Array(_len), _key = 0; _key < _len; _key++) {
          abc[_key] = arguments[_key];
        }
    
        console.log(abc);
        console.log(_arguments);
      };
      bar('a', 'b', 'c');
    }

Firefox. Chrome has not released support for rest params yet (it's in beta).

It would not be a web compatible change so will never happen. Too much code relies on them being different.

That doesn't make sense. Plenty of features from ES6 and 7 on the server and other platforms have steamed ahead despite browser adoption.

Things regularly fail to make it due to web compat, e.g. Array.prototype.contains() was rejected.

"Renamed" would probably be a better term here than rejected.

Yes, true

Almost all ES5.1 code will run on a browser that implements ES2015. There are subtle breakages like there were when moving from ES3 to ES5.1, but affected code is rare (and probably bad anyway). If `arguments` were changed, it would break huge swaths of the web rather than a couple sites.

While it would be nice to require everyone to re-write their website code, the cost would probably be in the hundreds of billions of dollars. The pragmatic choice is to leave it in place and discourage it's use. Maybe it can be deprecated in a couple decades.

No one believes this, but even if it were true it would not excuse your behaviour. It is not a defence.

You just called the woman that you were harassing a coward.

No one is trashing YC here, plenty of people criticising you and your behaviour though. Maybe you should reflect on that.

No one needs to sockpuppet or troll on this thread, you are doing a fantastic job of ruining your own business and clearly need no further assistance.

You had an opportunity to make this right, but now you're doubling down on the insanity.

Your cofounder specifically mentioned that you made those comments, not your presumably fictional support team. Are you lying or is your cofounder?

No one is buying your false narrative, you are managing to make a bad situation worse. You're going to lose your status as a YC company over this.