STRML

That's a great graphic! I see a few more from around 2003 on http://chip-architect.com/, do you know of anyone who's doing modern chips (x86 or ARM) this way?

I agree that the IE decision was practically braindead and killed the utility of DNT. Because of it, we have no idea if the user actually specifically wants DNT (and this may degrade the user experience, so it should be opt-in), or their browser vendor simply decided for them.

Well, the optimizing pipeline has completely changed in V8 5.8 (if you use `--turbo --ignition`) and in 5.9+. It's been simplified and most importantly, does not deoptimize on quite so many common features (such as try/catch). More information at http://benediktmeurer.de/2017/03/01/v8-behind-the-scenes-feb... and some of his other articles.

In my testing it appears that TurboFan cannot optimize certain patterns as well as Crankshaft did, but there's no reason to believe those regressions will remain as TF evolves. Optimizing more code is much more important for real apps.

This is a big release. Async/await in stable core is something I've been (literally) waiting 6 years for.

Many people have criticized Node's cooperative multithreading model, with both good and uninformed reasons. Yet, it is without dispute that the model is popular.

Async/await is a giant leap forward toward making Node usable for beginner and expert alike. This release is a celebration.

For those of you with existing applications looking to migrate, try `--turbo --ignition` to emulate (most) of the V8 5.9 pipeline. Anecdotally, microbenchmark-style code regresses slightly, real-world code improves by as much as 2x. Exciting times.

This was tried many years ago. At that time, Promises/A+ was not finalized, and the community could not agree on which Promise specification was best, or even if one was needed at all.

Callbacks are lightest-weight re: CPU & memory overhead, so it was decided that core APIs should implement that, and developers can override using promisify (via e.g. Bluebird or the new `util.promisify()`) as they need. But putting that kind of assumption in core could lead to significant pain.

It does - and has for a long time:

https://nodejs.org/api/debugger.html

Shrinkwrap did not use hashes and did not guarantee deterministic installs. Subdependencies could still end up as different versions.

Even the shrinkwrap file itself contained a lot of trash and generated massive diff noise. I had a file full of scripts to make the shrinkwrap file usable and even then we had (production!!!) issues due to changing subdeps. We reworked our build processes to zip & deploy the exact code that passed the tests to work around that, but it was still a massive pain that installs at different points in time would yield different trees.

When yarn came out, I deleted a folder full of hacky scripts, cut my install time by 60% and finally got deterministic installs. Needless to say, I was ecstatic.

If this test was correct, this smells like a class-action. Enterprise users (and home users, for that matter), have a right to control egress.

Watching the newly-released HD version helps quite a bit with that perception of age.

"God forbid, SQLite"? It's honestly a great product and a wonderful stepping-stone. I wish more new projects used it rather than half-measures like Mongo.

It's large, of course. But you have a full VM and a bunch of unminified javascript dependencies sitting in there. V8 isn't known for being small, either.

Compared to a proper systems language it's always going to look ridiculous. And it appears to be 3-4x larger than, say, py2exe. You can apparently get about a 30% reduction using `strip`, and there's likely other low-hanging fruit.

It's about 12MB compressed. It's not so terrible in today's world, and the simplicity at runtime is worthwhile IMO. I don't worry too much about my tools getting larger, so long as they solve problems and don't cause them.

Anecdotally, I built a small project (lambda fn) with just a single dependency (`request`) - the mac/alpine node6 build was 37MB.

It will also allow returning raw strings (TextNodes), which will allow for some very light i18n libraries.

I like the idea, but this is very confusing to end-consumers:

- Is this just a messaging app? A payments app? A web browser?

- It's all of those things, except not a web browser, it's an "app browser" (why not app store, especially considering the whole point of these is that they are paid?)

- The starting experience is anything but compelling: http://i.imgur.com/U69Gskl.png

- Is this developed by Coinbase? If so, why is there no mention, and the app is developed by "Bluxome Labs"?

They're different. Flow is not a "superset" of JS in that it introduces new features, it only introduces new types of annotations. Remove all the annotations (literally delete them), and you have valid ES6.

Typescript has its own class system, public/private/protected, and its own compiler. This was a big negative while ES6 was still brand new and the TS compiler was catching up, but now it's pretty much a wash between the two.

A year ago, I would have said Flow, no question. Today, TS has really caught up and the tooling is better, no doubt. It depends on how complex your types are - Flow can express types TS can't, but TS has an incredible ecosystem and far fewer bugs. In the end, it's all about reducing bugs in your own application, and TS seems to do that better in the end despite its limitations.

Yes - and no. Flow can express some really complex types that were previously only possible in much more esoteric (or modern) languages. Types as many people know them from Java, C#, etc., are more mature (aka fewer bugs), but far less powerful.

For example:

The utility types in https://flow.org/en/docs/types/utilities/ can be used to great effect to express things like "A type of the keys of T, but values passed through this function" or "A type that is the difference of these two maps".

In practice, this helps me write things like React Components that take some of their props from the root store via context, and the rest of their props directly, and for Flow to actually know which is which just by reading the code (no explicit typedefs!), override root store props as needed (so long as I don't change their types), and throw a type error if I miss or misdefine one. Awesome.

I have been a fan of Gun's and the HackingDistributed blog for a long time. It's one of the few sites I regularly read on my RSS feed, and he's one of the few people who really seems to "get" Bitcoin and on-chain scaling.

That said, I am surprised at how much this article seems to miss the point, given his otherwise stellar work. Gun, like many in the field, would agree that one of the defining characteristics of Bitcoin is its decentralization. Why, then, push the narrative that the current state of mining centralization is okay? Furthermore, how could it possibly be fine with him that these groups use a patented process - exclusive patents go against everything Bitcoin stands for - to cement their domination over other miners?

In my opinion, the fact that this was hidden invalidates much of the anti-SegWit rhetoric coming from the miners. We all can agree that the soft-fork is large and complex, but it is well-engineered, well-tested, and solves several hard problems while opening Bitcoin up to a variety of novel scaling situations. Now we learn that the opposition's absolute opposition was based on a hidden advantage, not any technical failing of SegWit itself. It is not possible to consider many of these criticisms honestly given this regressive, protectionist hidden motive.

And on many cloud systems, especially those with network disks like EBS, compression gives you some serious avg throughput wins.

Yeah, I'm actually completely wrong. My apologies to the Buble team. For whatever reason, I thought I saw an announcement of Buble essentially saying it was an opinionated feature-freeze of Babel with most of the configuration stripped out, but it appears to be a totally new project.

That said, the two are very different tools. Buble appears to be essentially string manipulation (which Babel does to occasionally with babel-template) built on top of Acorn. It's much simpler but there are a lot of useful transformations you simply can't do with that approach.

Edit: After some further looking into the project, I have to say that it seems like it would nice & easy to use for simple transformations, like the aforementioned React.createClass -> class Foo extends React.Component. However, you have to keep in mind that code that is not spec-compliant will break in mysterious ways perhaps months or years into the future. It may not be worth it, despite the ease.

`yarn install babel-cli babel-preset-es2015; ./node_modules/.bin/babel --presets es2015 <sources> -d <out-dir>` is not particularly difficult.

Come on. Buble is Babel, just with a few presets hardcoded. Yeah, it's better usability, until you need to run a production application.

I agree that this is the future. But that will mean telling everyone that they should now run their node_modules through Babel - no inconsequential feat, given the size of the code that must now be transpiled.

We use Flow everywhere now and love it. It's not perfect by any means but it's a lot easier to use than Java's static typing and a lot more expressive to boot. I can't overstate how great it is to be able to strongly type your modules and ensure you don't send the wrong input or receive the wrong input from them.

In fact, Flow allows us to confidently implement APIs that would just be cumbersome otherwise; we can use complex string keys for UI actions, rendered templates, etc., and make Flow actually enforce them via its $Keys<T> helper. This has the incredible effect of making it a type error if you try to execute an action that doesn't exist.

Cumbersome APIs become easy with Flow, and that's just scratching the surface of its utility on any sufficiently-complex JS project. It's nothing but wins for your development team.

TS is great too. Honestly, either way is a giant leap forward.

I was in awe the entire time Lin was speaking. Not a single "um" or other verbal tic; she's an incredible speaker and was admirably lucid throughout that entire talk. That's so difficult to do. And style aside, she made understanding Fiber incredibly simple.

Just wanted to express my admiration for her work and gratitude for making this information public, available, and free.

This is a big deal to deprecate `createClass` and `propTypes`.

PropTypes' deprecation is not difficult to handle, but the removal of createClass means one of two things for library maintainers:

(1). They'll depend on the `create-class` shim package, or,

(2). They must now depend on an entire babel toolchain to ensure that their classes can run in ES5 environments, which is the de-facto environment that npm modules export for.

I'm concerned about (2). While we are probably due for another major shift in what npm modules export and what our new minimum browser compatibility is, the simple truth is that most authors expect to be able to skip babel transcompilation on their node_modules. So either all React component authors get on the Babel train, or they start shipping ES6 `main` entries. Either way is a little bit painful.

It's progress, no doubt, but there will be some stumbles along the way.

Which would be another worthwhile fix: some way to run `apt remove` or `apt autoremove` in a zero free-space environment. It could detect it and pick pick data somewhere (like /usr/src) to persist to memory temporarily while it works, then replace.

Verizon, Comcast, and Rogers have done it, that we know of. In North America that's a very large proportion of traffic.

Just wanted to say thank you for CoffeeScript. Despite its somewhat ambiguous syntax it really was a better version of JavaScript, and it would be fair to say it really mainstreamed the idea of JS as a target language. Many of the ideas in CS made it all the way to ES6. Many other ideas didn't make it to ES6 because CS fleshed out issues that quite possibly would have been missed otherwise.

It was a huge net positive for web development. 2009-2011 were really heady times - a whole programming community emerged from a deep, dark cave with new tools and a new optimism for the web.

Those are extremely impressive specs for the size. Great find and thanks for the link.

Disclosure: I'm CTO of BitMEX, a Bitcoin derivatives exchange built on kdb+/q. We don't compete directly with itBit or any of the exchanges I mention below (we don't do spot trading, they don't do derivatives) but we are in a similar space.

Audits matter. Your books should always sum zero. Time and time again, we've seen bugs like this across the space: there was the infamous Bitcoinica "infinite leverage" bug [1], a rounding error in another's order sizes, and it's theorized that a similar bug was leveraged in the downfall of MtGox to create virtually infinite balances and use it to buy Bitcoin up to $1000 in 2013.

Whether it's in your engine or outside of it, whether it's a Bitcoin product or any other financial product, make sure there is something - somewhere - that is regularly summing up all accounts and ensuring that every cent or satoshi is accounted for.

We run such a system at every execution. If the system doesn't sum zero, we shut down. It's happened three times in two and a half years, each time due to tiny mathematical errors in our liquidation process, each time for less than 10,000 satoshis (~$0.10). We sleep much better at night knowing it's there.

Audits would catch the error caused by float math. And of course, don't do float math.

1. I can't find the original reference to it, but it was originally possible to simply edit the DOM to submit any leverage amount you pleased (such as 100,000x; never trust the client!) and then run your account massively into profit - or bankruptcy.

Looks like it won't take much. A lot of USB-C power banks on Amazon max out at 3A/5V; at 15W, that's just about the top power consumption measured on the Switch (16W), so it ought to be enough to at least keep the battery constant as power use fluctuates during regular gameplay.

I expect we'll see 5A+ power packs in the future which will handle it easily.