Hacker News new | comments | show | ask | jobs | submit login
Platform as a reflection of values [video] (nodesummit.com)
103 points by overcyn 5 months ago | hide | past | web | favorite | 62 comments

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.

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.

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}`.

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.

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.

> 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.

> 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.)

I have been thinking about programming languages in terms of communities as well lately. Which one do you find most attractive?

I like these communities:

Python - it's a very large community. Given its size it's pretty diverse and also mature. It had some drama around an incident at Pycon a few years back and around the 2 -> 3 transition. Also Pycon is probably one of the most fun tech conferences.

Erlang - it's an example of a great small community. A lot of knowledgeable people. It has been around for about the same time as C. A good mix of people who have been involved in the community for 30 years and newcomers. There is almost no drama, people might disagree but that's ok. Sometime someone said something that was taken offensively in the online discussion, and the person apologized and everyone moved on. No forks, no backstabbing, voting anyone out and so on.

Elixir - probably my favorite example of wonderful community. And here all credit goes to Jose Valim and others on the team. They specifically focused on making the community warm, and welcoming for new people. That means not just codes of conduct but great documentations, good help and support online, tools to get started to write tests and so on. Also as a nice benefit they also in a way a part of the Erlang community as because there have been a lot of cool new fixes and features they've submitted for BEAM VM over the years.

So depending on what you'd be interested in, I'd pick one of those. No doubt there are other great communities (I suspect Rust is one) I am just not as familiar with them so this is definitely not a exhaustive list or a ranking, just my personal experience.

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.

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

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!

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) on this theme, or a blog post I wrote "Simple is Not Easy" (https://underscore.io/blog/posts/2015/07/21/simple-isnt-easy...).

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.

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.

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:



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.

> 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.

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.

[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?

> 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.

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?

For whatever it's worth, I was actually referring to vasync[1], not async. The similar name is due to similar semantics (and in this regard, async inspired vasync), but vasync is very much designed around debuggability: you can couple it with the postmortem support we built into mdb for node.js[2] to be able to meaningfully debug seeming hung node programs from an operating system core.

[1] https://github.com/joyent/node-vasync

[2] https://github.com/joyent/mdb_v8

Yep, I was just responding to the "don't use async, use vasync" comment.

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.

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.

I feel your pain but ES8 (specifically 'await') is a game changer. You won't feel like you're torturing yourself.

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.

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

* 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/

* 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.

> * "Batteries included".

That's a tricky one. Right now it's wonderful, because all the included core modules are recent and relevant. I suspect in a decade you might find that the core modules are somewhat more crusty, sometimes support defaults that don't necessarily make sense with what's the common standard at the time, and is hard to change because of backwards compatibility. You might find in a few years you're not using the built in SSL library, or the http2 implementation, because better (either through capability or interface) alternatives have come about, and the core libraries start to look really annoying as you have to continuously tell new users to avoid them in lieu of the current best practice, which is not in the core libs.

It's a trade-off these languages make when designing their core libraries. There are upsides and downsides to both approaches, but one isn't necessarily clearly better than the other overall (even if different approaches have stronger outcomes when the language is new and when it's mature).

> 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.

> 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...

> 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.

> 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...

[2]: https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...

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

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

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.

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.

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.

> JavaScript may be the most successful language in history

Which is interesting because it's not that good a language, but circumstances and "luck" put it in the position it's in.

Not unlike a lot of successful companies.

The language may not be great, but the platform (where "platform" == "an ever-expanding pile of web technologies already deployed on billions of devices") is seemingly unbeatable.

They're just older and have first mover advantage. Like Windows...

I think that's dismissive. I think the stability of PHP to not change too rapidly has made it very attractive compared to the alternatives, as well as the documentation.

When you look at why JS lost its way it changed too quickly, python changed in a non-backward-compatible way, ruby changed quickly (as did all its packages).

> I think that's dismissive. I think the stability of PHP to not change too rapidly has made it very attractive, as well as the documentation.

If that was it, we'd all be writing Perl. Seriously. The documentation is better, the backwards compatibility is second to none, it's well designed (even if it's not what people expect, and people often misinterpret how it works because it's just similar enough to most procedural languages to seem the same). Particularly when compared to PHP (which copied a lot of parts of Perl, but did so poorly), it stands up well.

That said, I think you are half there. It's not just stability and documentation, but that with a minimum level of community, which PHP garnered by being dead easy to deploy back when that was actually a concern and in-language frameworks didn't abound. Perl lost a lot of community in the early 2000's, and never really recovered fully from that (relative to popularity of other languages at least).

> If that was it, we'd all be writing Perl. Seriously. The documentation is better, the backwards compatibility is second to none, it's well designed

but you can learn how to write PHP in junior high school while being drunk at 4 am.

You could learn Perl, or Lisp, too in the same circumstances. Most people won't, though, because they'll pick a "hot" language for their domain of interest.

This is how, in our fashion-driven industry, suboptimal solutions win - they grow off tiny differences in a positive feedback loop.

Why not LISP than? I dont think Java is popular because of the first mover advantage at all. It is popular because of tooling, raw perfomance and number of libraries available.

LISP didn't capture broad market share, ever. C would be a better example. It's not just age, it's market dominance that matters for first-mover advantage.


Yes, why not? As I maintan a data driven, static content web page generator, I keep thinking in terms of LISP functions. LISP, with its stateless and functional approach appears to be the right tool for the job. Why not LISP, indeed?

With that written, LISP does have one huge barrier to entry: lack of documentation. For example, I've been trying to figure out how to use the getopt LISP library in Clozure LISP (it's the only LISP which works on my OS) and there is no documentation nor examples; the best I was able to come up with was "look at the source". Being forced to reverse engineer isn't good for adoption. That needs fixed!

What OS is that, Multics?

Solaris 10 on the i86pc platform.

Have you tried Gambit, or alternatively Gerbil (which uses Gambit as its foundation)?

Ouch, my condolences. (SBCL not working though?)

No need for condolences; I run Solaris 10 because the damn thing is unbreakable; all the other machines keep busting but this thing runs and runs and runs, and it's fast and low power. SBCL goes straight into some sort of a LISP debugger and is unusable. I guess quality control is not a term in Steel Bank's dictionary.

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) {
If programmatic errors were not exceptions as you wish, what would they be instead?

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

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.

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...

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.

> 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"

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.

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?

It works for me on iPad

Doesn't play on Firefox for me.

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.

Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact