
Platform as a reflection of values [video] - overcyn
http://www.nodesummit.com/videos/?the-video-node2017=45
======
rdtsc
I'll watch all of Bryan's talks, he is just such an engaging and interesting
speaker.

Very good insights there, the idea that when you buy into a platform you buy
into the values of its community.

Interestingly enough it's why I didn't buy into the node.js's community. From
interviewing people and talking to them at conferences and meetups somehow
nodejs fans were both the most excited yet didn't really know what they talked
about. Either one of those characteristics are ok, but both at the same time
are hard to stomach. Then all the public scandals that seem to have node, also
makes it hard to buy into - that pronoun scandal, io.js fork, another fork
(ayo?), left-pad-gate.

~~~
inglor
The happenings in the Node.js community such as forks are a positive and good
thing. They let people experiment with things in a new environment.

A lot of good came from io.js (modern V8, promise integration etc). Ayo are
working on interesting stuff like shared-memory workers for CPU intensive
stuff.

The left-pad thing was indeed strange, but it could have equally happened with
most package manager - and NPM improved for it.

Newbies being excited about something is the hallmark of a popular platform.
Node.js feels like this as it graduated from a "fun project" to a popular web
platform.

I think most stacks have competent and incompetent developers - making Node.js
accessible is a good thing, even if it means there are more new people. At the
Node.js project we're really fine with those and some "newbies" turned out to
be pretty great programmers.

full disclosure: I am a Node.js collaborator.

~~~
reificator
The left pad thing _could_ have happened somewhere else, true enough.

But it was far more likely to happen in Node than anywhere else, for the
following two reasons:

1.) Javascript has a tiny stdlib relative to other languages that are also
used for "real work". I make that distinction just to rule out LOLCode/etc....

2.) NPM makes it so damn easy to add dependencies, both for finished products
as well as component packages themselves.

#2 came about because of #1, and is honestly the only way that Node could have
gained traction. So while it's NPM's fault you can't really blame them for
making that choice.

A month or two ago I wanted to add a single NPM dependency to a project at
work. I knew it built on top of other packages, but when I installed it I
ended up somewhere between 690 and 700 dependencies. From typing `npm install
{one-specific-package}`.

~~~
thehardsphere
More crucially to your point 2, NPM allowed people to remove packages once
they've been released, and for others to release packages with the identical
name as a previously-existing package.

I'm not aware of any other package managers that exhibit this rather dangerous
behavior.

~~~
reificator
Yeah, I did leave that bit out, because that's an implementation detail that I
believe they have since resolved. It was a massive mistake, but one that could
have been avoided and has since been patched.

#1 and #2 are foundational to providing Javascript on the server. You _could_
do without #2, but because of #1 it means you'll have a harder time attracting
and maintaining a userbase if you don't do it that way.

This leaves you vulnerable in the long run IMO.

~~~
kbenson
> but one that could have been avoided and has since been patched.

It would be really nice if many newer languages didn't act like they existed
in a vacuum and no prior art existed. Package management was by no means new
at the point NPM was being developed, and if they didn't have enough people
with experience with the nasty edge cases package managers in other languages
had discovered, it would have been trivial to solicit advice from the
architects of the package systems for other languages. If there's one thing
software engineers love, it's talking about crazy situations where nobody
considered this weird edge case and how they had to scramble to fix it (I know
I do).

I think we've thankfully gotten to a spot where there's enough users and
developers of modern programming languages with experience in other languages
that we're seeing good cross-pollination at the language design level (e.g.
async/await is quickly being adopted by many languages as either a core
feature or through a library that's popular). That just doesn't seem to have
happened yet with the architecture around the languages yet.

~~~
reificator
> If there's one thing software engineers love, it's talking about crazy
> situations where nobody considered this weird edge case and how they had to
> scramble to fix it (I know I do).

Stay awhile and listen while I discuss IE8 in quirks mode with a domain
specific, terrible WYSIWYG editor from over a decade ago...

> It would be really nice if many newer languages didn't act like they existed
> in a vacuum and no prior art existed.

I don't limit that to newer languages only, and balancing the outside world
with your users' needs is an invaluable skill.

NPM should have known better, and it bit them _hard_ for not doing so. But
they learned very, very quickly, because if they didn't Node would have fallen
overnight.

I do like to make a point to not crucify people and organizations for things
that have since been fixed. Yeah they were forced to, yeah it caused a lot of
problems, but at the end of the day no one's using Node for pacemaker firmware
or missile guidance systems. (And if you have counter examples, please don't
post them for the sake of my sanity. Petition the people responsible instead.)

------
Annatar
Old school system / kernel engineering valuing robustness, correctness,
backward compatibility, observability and security versus people who didn't
care about any of those things because they are web developers (and I'm really
trying to restrain myself here from using the term n-gate uses): it was a
collision of epic proportions.

Most importantly, I believe it was very instructive for Bryan Cantrill: when
he used JavaScript to develop the front-end for the Fishworks storage
appliance he thought JavaScript was the new cool, and after this, it certainly
appears that he came around and realized all is not that well as it seemed in
the world of web development and JavaScript. Glad to see a person I deeply
admire being willing to reconsider or at least re-evaluate their position as
shaped by the new experiences.

More to the point of the talk: this is why I will never accept Linux, and
Bryan spells it out to me why that is the case: I do not want to, and will
never share nor live by the values of the people in that community, whereas I
live by the values that the illumos and SmartOS communities espouse.

~~~
X86BSD
Well said. Also FreeBSD would welcome your knowledge as well. Put a foot in
both illumos and FreeBSD? :)

~~~
Annatar
I already run TrueOS on one of the laptops. I think a lot of us in the illumos
community view the people in the FreeBSD community as our brethren in arms,
and when Bryan speaks about the values, I also think our two communities share
a lot of the values together. The best part is that it's not just lip service,
you guys help us out with driver code and the bootloader and we help you out
with OpenZFS and DTrace. We love you guys, you're the best!

------
noelwelsh
Just a quick comment. I think the differences go beyond values, to what you
might call world views or paradigms (in the Kuhnian sense). Take, for example,
the value of "simplicity". This is extremely overloaded. I doubt the speaker
and I would agree on what is simple. I'm not familiar with a lot of the
examples they used, but I'm going to guess they would consider C simple and
something like Haskell as "not simple". I think that C is familiar but not
simple (too much undefined behavior) and Haskell is simple but not familiar;
more generally people conflate simple with familiarity. There is a nice Rich
Hickey talk "Simple Made Easy" ([https://www.infoq.com/presentations/Simple-
Made-Easy](https://www.infoq.com/presentations/Simple-Made-Easy)) on this
theme, or a blog post I wrote "Simple is Not Easy"
([https://underscore.io/blog/posts/2015/07/21/simple-isnt-
easy...](https://underscore.io/blog/posts/2015/07/21/simple-isnt-easy.html)).

Similarly in the discussion of promises. I have written a lot of code using
promises---though not in Javascript---and it's fine to debug. Javascript just
makes a mess of it because it can't decide on what world view it wants. Is it
trying to become a modern somewhat-functional language, which is the direction
Ecmascript, Flow, Typescript, etc. are going? Or it is a primarily imperative
language? If you go for the former you have very different expectations about
how the language operates than the latter. It's notable that most functional
programmers (which is my day job) don't make much use of debuggers and the
kind of tools the speaker talks about building are not generally valued that
much.

Now I don't want to give the impression that I think the speaker's world view
is wrong. It's just different. Notable though is that we would have
fundamental disagreements in how we view the world. It's not that we value,
say, simplicity differently. We disagree on how simple is even defined.

------
rhinoceraptor
I’d like to read more about the promise error handling thing, I’ve heard
him/joyent mention that being a defect of promises but it’s not totally clear
to me.

I can also second the node async library not being amazing to work with.
Before version 2.0 of the library, some of the functions (filter, detect,
every) wouldn’t propagate errors.

~~~
m1el
Earlier this year I asked the exact same question. When I learned the answer,
I was severely disappointed in JS Promises.

You can read about that here:

[https://www.joyent.com/blog/post-mortem-debugging-and-
promis...](https://www.joyent.com/blog/post-mortem-debugging-and-promises)

[https://gist.github.com/misterdjules/2969aa1b5e6440a7e401](https://gist.github.com/misterdjules/2969aa1b5e6440a7e401)

Let me provide an example:

    
    
        asyncRequest().then(value => {
          var intermediateValue = 'foo';
          return null.thisIsAnError;
        }).then(_ => console.log('success!'), err => console.log('error!', error));
    

This program contains a _programmatic error_ , but Promises make it look like
an _operational error_.

Why is this bad? Because it prevents you from doing post-mortem debugging of
your program. No matter what you do, you can't access intermediateValue after
you noticed the error..

Promises catch all exceptions thrown inside callbacks, which makes debugging
(especially post-mortem debugging) harder. I've personally encountered this
problem.

~~~
nailer
> No matter what you do, you can't access intermediateValue after you noticed
> the error..

Couldn't this be solved by dumping all values in the scope the exception was
created? Ie this sounds like a VM feature request, rather than a limit of
Promises.

~~~
m1el
This cannot be done the way you describe it.

We already have VM features to inspect the scope of a function that failed.
The problem is, Promises "handle" the exception, and prevent users from using
this feature.

I will repeat the statement: Promises catch exceptions thrown from handlers.
This means that the scope in which the exception was thrown doesn't exist
anymore.

~~~
nailer
[Small note: I'm trying to learn here, that's all]

I still don't understand. When a Promise throws an exception and we catch() it
(assuming 'await' here as I've never used Promises with .then() for anything
serious), couldn't the err passed to the catch() expose the necessary parts of
the scope like it could for exceptions _not_ created by Promises?

~~~
m1el
> couldn't the err passed to the catch() expose the necessary parts of the
> scope like it could for exceptions not created by Promises?

That would require Promises to create and use a new unique and intrusive API
into the interpreter. Requiring an exception to _preserve_ the scope in some
specific case is... problematic, to say the least.

Instead exceptions in Promise callback could be handled as uncaught
exceptions, which would solve the problem caused by Promises catching all
exceptions and passing them as error values.

~~~
nailer
Thanks for replying.

> Requiring an exception to preserve the scope in some specific case is...
> problematic, to say the least.

I was thinking about having exceptions preserve scope in all cases, or in all
cases if a flag is turned on. I don't quite understand what the difference is
between `catch(error)` when using await/promises and `catch(error)` when doing
something else. Is the main concern here the overhead?

------
andrewstuart
The two programming languages that I know best are Python and JavaScript and
given the choice will always choose Python for the back end.

ES2015 is a pretty good language and its inherently asynchronous nature makes
it ideal for UI.

Python's synchronous programming model makes it much more effective for back
end.

When I started an AWS Lambda project recently I started with JavaScript and
then thought "why am I torturing myself?" and switched to Python and never
looked back.

At the front end, it's a real pleasure to use ES2015 although there's plots of
room for improvement, which I guess will come over time.

~~~
qaq
We have services in both Python/Tornado and Node and to be honest for async
backend services I kinda prefer Node, because in JS everything is async plus I
find the dep. management in Python annoying. If it was my choice I'd use
neither and go for Elixir which is a pure joy to use.

------
nickpeterson
I know Bryan comments on HN regularly, if he sees this, "Why Go?" Is Go really
better than the JVM for performance or robustness? Is it a matter of choosing
a language that isn't Java for political reasons or in order to keep strong
developers interested? What specifically does Go get you that the JVM would
really hurt?

I don't know much about Go (I use .net mostly), but would be curious to hear
some reasons to choose it over JVM/CLR.

~~~
Olreich
Not Bryan obviously, but here's a rundown of the highlights and lowlights of
Go as I see them, paying attention to JVM languages (since I don't know that
much about C#).

The Good:

* Performance. Java and the JVM are certainly performant once things get going, but Go and other compiled languages are at peak performance out of the box. Go should generally be a bit faster or equal speed to Java and should use a fraction of the memory. Here's some microbenchmarks that look good for Go vs Java: [https://benchmarksgame.alioth.debian.org/u64q/go.html](https://benchmarksgame.alioth.debian.org/u64q/go.html)

* Concurrency. Go makes it simple to communicate and synchronize with other threads, and the co-routine model allows for expressiveness in async without running into callback hell.

* First-class Functions. Some JVM languages have this, but even Java 8 doesn't have the ability to set a variable equal to a function definition. Coming from Node, Python, C, C++, etc. Making functions first class citizens helps a lot.

* Interfaces. Go has auto-fulfilled interfaces that you opt-in to by writing the functions they require. The compiler figures out which types match an interface for you, instead of you specifying it. This is probably my favorite feature of Go. It feels like duck-typing with type-safety.

* Unicode support. Go has excellent unicode support, which I don't think any JVM language has. Javascript also has great unicode support. This is probably a big one for someone doing a lot of web-based application deployments.

* "Batteries included". Go's standard library is amazing. All the basics you'd expect like string manipulation and math functions are there. They also have a dead-simple http server/client that supports http2 and SSL. Full crypto libraries with key-management. Encoding/Decoding for csv, json, and xml built into the standard library, even compression formats. The standard library feels really good to use compared to C++ and Java for me. C# I believe is on-par with Go as far as built-in libraries go.

* Compiled and statically linked. Go only does static linking for Go code, and does interoperate with C (but it's awkward). This means you compile the Go program and then run it, the runtime is in the binary. There's no worrying about versions of your JVM and ensuring that class paths are set up correctly. A single binary executable is all you need and what you get out.

* The tool chain. Go comes built in with documentation generation (really nice stuff, everything on golang.org/pkg is automatically generated from the source and comments), testing facilities (including coverage tools and benchmarking), and dependency gathering (like pip without the versioning). The dependency gathering uses VCS, so you can point it at any mercurial, svn, or git repo and Go will go download and put it in the right spot for you. The compiler can do cross-platform compilation from your local machine (on windows machine, compile for linux) with some playing with the settings. There's a race detector, code formatter, and version upgrade tool in there too.

The Divisive:

* Error handling. A lot of people I've seen using Java/C# like exceptions for error handling. Go doesn't use exceptions except in exceptional circumstances (and no try catch when that happens). Go instead recommends you use secondary return values (since you can return multiple values) for your errors. This leads to a lot of code that says `if (err != nil) { return nil, err }`. I find that in my first pass, that line is everywhere, but when I start building toward production of the system, I'm responding to the errors fairly deep in the call stack and the number of default error lines drops dramatically. Your mileage will vary.

The Bad:

* No generics. This might be a deal-breaker for you, depending on how you like to program. Go has first class support for a simple hash map (generic) and dynamic arrays (with slicing semantics similar to python) (generic). Every other generic collection type you might want will be made yourself, made by code generation with a third party module, or lacking any type safety through the use of `interface{}`. Generics are probably going to come at some point, but not yet.

* Package version management. While Go makes it easy to get the latest version of a package, Go does not have a robust package version management system yet. Getting the specific version of a package your project needs is difficult and error prone at times. Third party tools are currently the best way to deal with versioning and freezing your dependencies. Hopefully the `dep` tool or something like it will become a first class part of the tool chain, but it's not there yet.

* Debugging and IDE support. There's still not a lot of IDEs that support Go, but it looks like JetBrains may be fixing that soon with a dedicated IDE: [https://www.jetbrains.com/go/](https://www.jetbrains.com/go/)

* Lack of expressiveness. In Go, there is often only one way to do things. Go is specified in it's entirety in under 30k words. You can write a whole compiler based on that information. That means it's lacking a lot of nice syntax that's become popular: Option types, pattern matching operations, decorators, lambda expressions, etc.

~~~
pron
> Go should generally be a bit faster or equal speed to Java and should use a
> fraction of the memory.

Eh. Go certainly starts out faster and is faster in some benchmarks, but in
most workloads Java is faster.

> but even Java 8 doesn't have the ability to set a variable equal to a
> function definition
    
    
        Function<Integer, Integer> f = x -> x + 1;
    

> which I don't think any JVM language has.

Java (and so all JVM languages) has had Unicode support since at least 1997.

> The standard library feels really good to use compared to C++ and Java for
> me

I think you haven't seen Java's standard library recently.

> The tool chain.

This is one area where Java is ahead by a _large_ margin in almost every
single component you list.

For me, Go shines for small applications, and especially small command-line
tools, for which the JVM is not a great fit. It's easy to learn and get
started with, and the deployment is convenient. But for anything big, Java
wins hands down, in robustness, ecosystem, debuggability and serviceability.

~~~
Olreich
> but in most workloads Java is faster.

I can't find any data to back that up, can you point me at some?

> Function<Integer, Integer> f = x -> x + 1;

Fair point, didn't know about Function

> I think you haven't seen Java's standard library recently.

I dislike the standard library. It feels kludgy, as if things were added
haphazardly for the last 20 years. It's still missing valuable things that
have been around and proven to be very common and desired, like format
reading/writing (CSV and JSON come to mind). The HTTPServer implementation is
even in com.sun.* and isn't part of the official standard library. Oracle even
has a page telling you not to use it:
[http://www.oracle.com/technetwork/java/faq-sun-
packages-1422...](http://www.oracle.com/technetwork/java/faq-sun-
packages-142232.html)

> This is one area where Java is ahead by a large margin in almost every
> single component you list.

Java as an ecosystem, they may be ahead in some ways (IDE + Gradle). But Java
is not, they are missing most of the components I listed. You have to use an
IDE and Gradle/Maven to come close to the out-of-the-box experience with Go.
And I did note that IDE support is one of the negatives.

~~~
pron
> I can't find any data to back that up, can you point me at some?

These[1] are some recent results of the computer language benchmark game,
where Java beats Go overall even though startup time _is_ measured (similar
results here[2]). How much faith you'd want to place in these benchmarks is
questionable. As to real workloads, that's what people I know at Google tell
me.

> It's still missing valuable things that have been around and proven to be
> very common and desired, like format reading/writing...

I don't think any of it should be part of the standard library. In fact, one
of the best things happening with Java now is that the standard library is
being broken apart, and things like XML, cryptography and JDBC are taken _out_
of the "base" module.

OTOH, a standard library should provide truly foundational stuff, like good
data structures, deep monitoring infrastructure, things that Go _seriously_
lacks.

> You have to use an IDE and Gradle/Maven to come close to the out-of-the-box
> experience with Go.

But that's _because_ the Go ecosystem is poor in comparison. The Java
ecosystem is so strong and well established that the "out of the box" package
simply can't compete with it (and when it tries -- as with the logging API --
it loses). Go had to provide this stuff out of the box because there was no
ecosystem. True, this makes Go much easier and more pleasant to get started
with for beginners, but you can't compare something that's built around an
ecosystem, and something built to be self contained.

[1]: [https://sites.google.com/view/energy-efficiency-
languages/re...](https://sites.google.com/view/energy-efficiency-
languages/results?authuser=0)

[2]:
[https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...](https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2=go)

------
nstart
For anyone interested in a similar talk: DHH's talk from Rails Conf on what he
thinks people should think of when choosing tools. (Also, the Rails Doctrine)
[https://www.youtube.com/watch?v=Cx6aGMC6MjU](https://www.youtube.com/watch?v=Cx6aGMC6MjU)

------
alexandercrohde
I think there is merit in what he says, and it kind of explains why the
hot/sexy languages (Ruby, Node, Go) seem to be outsurvived by the Javas/PHPs
of the world

~~~
SwellJoe
Node is JavaScript and JavaScript is roughly the same age as Java and is, I
think it's reasonable to say, at _least_ as successful and long-lived. I'd be
willing to believe it'll actually outlast Java, as JavaScript has been
accelerating in adoption and its deployment footprint (by that I mean the
variety of places it is deployed), while Java seems to be popular but pretty
stable.

So, maybe I just don't understand what you're suggesting. JavaScript may be
the most successful language in history; it wouldn't surprise me to find that
there's more lines of code in JavaScript today than any other language
(possibly by a wide margin), even counting the billions of lines of C/C++ code
out there that we don't see because it never makes it to Github or whatever.
If it's not true today, it seems likely to be true within a few years.

~~~
jstimpfle
I believe Javascript wasn't really "hot" for many years, also due to
compatibility problems. And there have been no alternatives for a long time.

Although I'm strongly anti-OO and hate Java with a passion for going all-OO,
Java is a much better designed language than Javascript. And I think that
sentiment is common enough that Javascript could become less relevant now that
WebAssembly has entered the game.

~~~
SwellJoe
I tend to think JavaScript is the "next Java": It's nobody's favorite
language, but it's the one that many, many, many projects and businesses
settle on as a compromise on popularity, availability of talent, quality of
tooling, options for deployment, etc.

And, I would disagree with you on Java being a "much better designed
language". I enjoy coding in JavaScript a lot more than Java and always have
(even though neither is my favorite), and historic Java had tons of
misfeatures, too. Both have evolved in very good directions, but I think
JavaScript is evolving faster and in more interesting ways, partly because of
its history of being an open platform vs. Java's Sun->Oracle guided path.

Both also followed some dead ends...JavaScript, in particular, has always been
a mess of warring factions, and the uncomfortable bolted-on feeling of some of
the Java-like things it borrowed in the early days is particularly weird
feeling in today's language. Coding in JavaScript feels like coding in three
or four different languages. But, the thing as a whole isn't bad at all. It's
extremely powerful and has become extremely concise in recent years (which has
always been the biggest turn off for me with Java...so many damned lines of
code, I just can't see the forest for all the trees).

Edit: I agree that WebAssembly is going to shake things up, but it'll probably
be many years before any language is as widespread as JavaScript on the web.

------
nailer
I'm confused re: this slide at 24m23s:

> We cannot know if a thrown exception in a Promise is going to be caught or
> not

Bryan could you explain this? If you catch exceptions, or handle uncaught
exceptions, it'll be caught.

    
    
      process.on('unhandledRejection', function(reason, promise) {
        console.log(promise);
      });
    

If programmatic errors were not exceptions as you wish, what would they be
instead?

------
brockers
This seems to be the argument that Richard Stallman has been making for years.

~~~
nailer
I disagree: Stallman doesn't understand that while others value freedom, they
don't often value it to the same extent he does in their 'list of primary
values' per this talk.

I value freedom, but I value other things more. As the talk mentions, that
doesn't make me wrong. Stallman would suggest it does.

~~~
kbenson
Stallman has the unfortunate habit of being proven right over time. It's
unfortunate because I, like you, don't necessarily share his same fervor for
freedom as he defines it, and actually used to more than I do now approaching
middle age. That said, my point of view does occasionally cause me pain as
reality intrudes. I suspect eventually most his views will be seen in a much
more favorable light as they are able to be compared with more and more
situations proving his points.

Here's some interesting reading, a search of HN comments about stallman being
right.[1] You might not agree with every instance (and not every instance is
indicative of the point), but seeing the submissions the comments are
generally on does tell an interesting story.

1:
[https://hn.algolia.com/?query=stallman%20right&sort=byPopula...](https://hn.algolia.com/?query=stallman%20right&sort=byPopularity&prefix&page=0&dateRange=pastYear&type=comment)

~~~
nailer
You've misinterpreted my comment. I'm not saying I am right or Stallman is
wrong, I am saying he believes that others who have different values do not
understand freedom, whereas they simply rate freedom as a secondary value.
Much like node does 'robustness' according to Cantrill's presentation.

Also a HN search for 'Stallman is right' isn't much of a reference, any more
than an HN search for 'Stallman is wrong' would be.

~~~
kbenson
> I am saying he believes that others who have different values do not
> understand freedom

I understand. I'm saying that his views regarding just that have continually
received more and more evidence. I think it's entirely _possible_ that many of
us truly _don 't_ understand freedom, and are letting convenience alter our
perceptions to some degree, such that we've made our faustian bargains and are
now rationalizing them to ourselves. I'm not entirely convinced of this, but I
think there's a trend worth looking at, and some self reflection is warranted.

> Also a HN search for 'Stallman is right' isn't much of a reference, any more
> than an HN search for 'Stallman is wrong' would be.

The point, which I apparently didn't get across well, is that the phrase is
often pulled out at times where his views come sharply into focus, and used in
HN comments on submissions that sell that point, and the article submission
titles hammer that point home if you are familiar with the subject matter. For
example, here are some of the article submission titles on the first two pages
of that search, which only reaches about 8 months back:

\- It appears my Google account is slated for deletion

\- Demon-Haunted World

\- Apple Removes Apps from China Store That Help Internet Users Evade
Censorship

\- Microsoft Blocks Windows 7/8 Updates on AMD Ryzen and Intel Kaby Lake
Systems

\- Oracle finally targets Java non-payers six years after plucking Sun

\- Tesla bans customers from using autonomous cars to earn money ride-sharing

\- Apple Has Removed Dash from the App Store

\- HP Allegedly Time Bombs Unofficial Ink Cartridges from Working in Its
Printers

The point was never to say "look how often people say Stallman was right" as a
form of appealing to authority, but as a handy anchor to find events which
might be relevant to this discussion.

Edit: Whoops, was meant to be "apparently _didn 't_ get across well"

~~~
nailer
That's true, and people who understand and value freedom and understand how
bad those things are still don't have freedom as the same priority as, say,
usability: there's less use of free platforms in 2017 than there was in 2006.

------
vosper
Is this broken on IOS? I just see a picture carousel and a list of events.
What is it supposed to be a link to?

~~~
StreamBright
It works for me on iPad

------
gkya
Doesn't play on Firefox for me.

------
inglor
I have to say that I've just watched the video and I'm still surprised by how
some people get confused by promises.

If you forget to handle an asynchronous error in Node.js by default it will
silently fail (forget to check err in (err, data)). If something throws
synchronously the process will crash so if I find an endpoint that does a
`JSON.parse` in your server and pass it invalid JSON - I can easily do a DoS.

With promises, you drop the incorrect assumption that operational ===
asynchronous and acknowledge that things like `JSON.parse` can cause
"operational" errors too (and asynchronous errors can be caused from
programmer errors).

With promises, both synchronous and asynchronous operational errors are
handled in the same way - nothing is swallowed and everything is reported.
Except for extreme edge cases you get your core dumps - and debuggability is
actually much much better because you have real stack traces and errors.

