9 ms·

Platform as a reflection of values [video]

103 points by overcyn 9y ago

rhinoceraptor 9y ago
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.
- bcantrill 9y ago
  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 https://github.com/joyent/node-vasync [2] https://github.com/joyent/mdb_v8 https://github.com/joyent/mdb_v8
  - rhinoceraptor 9y ago
    Yep, I was just responding to the "don't use async, use vasync" comment.
- m1el 9y ago
  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-promises https://www.joyent.com/blog/post-mortem-debugging-and-promis... 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 9y ago
    > 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 9y ago
      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 9y ago
        [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 9y ago
        > 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 9y ago
        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?
alexandercrohde 9y ago
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
- chrisco255 9y ago
  They're just older and have first mover advantage. Like Windows...
  - alexandercrohde 9y ago
    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).
    - kbenson 9y ago
      > 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).
      - jcelerier 9y ago
        > 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.
vosper 9y ago
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 9y ago
  It works for me on iPad
rdtsc 9y ago
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 9y ago
  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.
  - deleted 9y ago
    [deleted]
  - reificator 9y ago
    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}`.
deleted 9y ago
[deleted]
nstart 9y ago
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
andrewstuart 9y ago
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 9y ago
  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.
- nailer 9y ago
  I feel your pain but ES8 (specifically 'await') is a game changer. You won't feel like you're torturing yourself.
Annatar 9y ago
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 9y ago
  Well said. Also FreeBSD would welcome your knowledge as well. Put a foot in both illumos and FreeBSD? :)
  - Annatar 9y ago
    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!
gkya 9y ago
Doesn't play on Firefox for me.
nailer 9y ago
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?
nickpeterson 9y ago
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 9y ago
  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.
noelwelsh 9y ago
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.html 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.
inglor 9y ago
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.
brockers 9y ago
This seems to be the argument that Richard Stallman has been making for years.
- nailer 9y ago
  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 9y ago
    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=byPopularity&prefix&page=0&dateRange=pastYear&type=comment https://hn.algolia.com/?query=stallman%20right&sort=byPopula...
    - nailer 9y ago
      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.
      - 9y ago

103 points by overcyn 9y ago

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.

bcantrill 9y ago
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 https://github.com/joyent/node-vasync [2] https://github.com/joyent/mdb_v8 https://github.com/joyent/mdb_v8
- rhinoceraptor 9y ago
  Yep, I was just responding to the "don't use async, use vasync" comment.
m1el 9y ago
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-promises https://www.joyent.com/blog/post-mortem-debugging-and-promis... 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 9y ago
  > 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 9y ago
    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 9y ago
      [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 9y ago
        > 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 9y ago
        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?

alexandercrohde 9y ago

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

chrisco255 9y ago
They're just older and have first mover advantage. Like Windows...
- alexandercrohde 9y ago
  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).
  - kbenson 9y ago
    > 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).
    - jcelerier 9y ago
      > 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.

vosper 9y ago

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 9y ago
It works for me on iPad

rdtsc 9y ago

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 9y ago
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.
- deleted 9y ago
  [deleted]
- reificator 9y ago
  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}`.

deleted 9y ago

[deleted]

nstart 9y ago

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

andrewstuart 9y ago

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 9y ago
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.
nailer 9y ago
I feel your pain but ES8 (specifically 'await') is a game changer. You won't feel like you're torturing yourself.

Annatar 9y ago

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 9y ago
Well said. Also FreeBSD would welcome your knowledge as well. Put a foot in both illumos and FreeBSD? :)
- Annatar 9y ago
  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!

gkya 9y ago

Doesn't play on Firefox for me.

nailer 9y ago

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?

nickpeterson 9y ago

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 9y ago
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.

noelwelsh 9y ago

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

inglor 9y ago

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.

brockers 9y ago

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

nailer 9y ago
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 9y ago
  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=byPopularity&prefix&page=0&dateRange=pastYear&type=comment https://hn.algolia.com/?query=stallman%20right&sort=byPopula...
  - nailer 9y ago
    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.
    - 9y ago