1. 18

URL fetcher here trimmed the URL & I didn’t recognise it.

See here

  1.  

  2. 8

    Everytime I cross my fingers that @bcantrill will say “We’re moving from node to Ocaml”. So close this time, SO CLOSE. It’s a great little language with a node.js compatible concurrency model and it could use some Joyent-style love around debuggability and dtrace.

    1. 7

      In case you want to know more on this front…

      One of the biggest stumbling blocks we (at Joyent) had when evaluating OCaml was the exception handling implementation. I managed to modify the runtime to abort() on an uncaught exception, but it seems like the only context where we know it’s not been caught is one where we’ve already unwound the stack (since exceptions seem to be indicated by returning particular special values from each function). The OCaml level backtrace is actually generated by putting a string into a global symbol every time an exception is thrown, just in case it ends up uncaught (which is why running with backtraces on incurs such a high performance penalty).

      We consider it pretty important to be able to get a core file after an uncaught exception, in the context of the throw, and always run with the ability to get a detailed backtrace. The OCaml compiler makes this pretty hard at the moment.

      Another thing we value pretty highly is being able to spelunk around in a core file to get information about a program’s state, and the OCaml compiler’s aggressive type elision with lack of debug info alongside to help understand what’s going on is pretty limiting there as well. I saw there was a project to add DWARF type info generation to OCaml but I couldn’t find much about it or what happened to it (I could have missed something there, sorry).

      These might sound to some people like small details, but it’s a big deal to us with how often we encounter bugs that simply can’t be reproduced from instructions in a different environment. You get one shot at figuring out these bugs, and that shot is in production where you can’t just bring the service to a stand still to step it through something. Aggressive use of abort() and post-mortem is really the only good way. So not having them is really a deal-breaker for a new language for us.

      1. 2

        Thanks for the response! And I understand the desire for debuggability. Out of curiosity, did you get any response from the community on why these things are not in Ocaml and the possibility of getting them in it?

        Also, I don’t quite understand one aspect of the uncaught exception thing. The async libraries I’m aware of always have a catch-all for exceptions when executing callbacks so that the entire system does not get stopped due to one stray exception. Does Node.Js not do this? Can a single uncaught exception stop the entire program in Node? Or do you do a lot of sequential programming in JS where you don’t have these callback handlers? Or do you rip out any catch-all exception so a stray exception can kill the system?

        Similarly, while I can understand the desire for abort-on-uncaught-exception, IME this issue isn’t really present in Ocaml programs. The convention is that exceptions should not cross API boundaries, so they should be elevated to something in the type system (such as option or result). I don’t think I’m nearly as thorough as Joyent and I can’t remember the last time I had a stray exception. But Joyent is doing more complicated work than I do so that may or may not make one feel better. Not that this is the only issue with Ocaml for you. But hey, happy to offer consulting hours to make Ocaml Joyent-approved :)

        Do you know how Golang fits into the Joyent model (@bcantrill mentions it in his talk as an option)? It seems to be its own strange beast from what I understand but maybe it’s closer to workable.

        Thanks again for the response. I get great joy out of Joyent’s products and I feel a pang knowing they are written in JavaScript…and possibly Golang :) I’m not all negativity, though, I’m hoping Joyent does some cool stuff with Rust and look forward to seeing it.

        1. 3

          Yes, in JS-land we actively go around ripping out domains and uncaught exception handlers from libraries we want to use (and sometimes end up running our own forks of them permanently as a result). We always run with --abort-on-uncaught-exception so that a single uncaught exception takes down the process. All our services are managed by SMF which will restart it immediately after a crash. The core files are hoovered up automatically by thoth, which puts them in our object store and indexes them in a database, then automatically runs diagnostics to compare them to known bugs and identify key information about them.

          We haven’t interacted much with the OCaml community as yet, and honestly our use of it has been pretty casual just to try it out and see if we can make it work. I know the type system and the normal ways modules are used means that a lot of things that would be runtime errors in other languages are caught by the compiler, but it’s still not perfect, and we really value the ability to have assertions and panics that are debuggable in this way in any language.

          Golang really is its own strange beast, and we’re having a lot of internal back-and-forth about it. There are some people in the company who are super keen on using it and are pushing hard on trying to find the best ways we can do that. Sadly the OCaml fanclub is quite a bit smaller. But nothing is set in stone – and as Bryan is fond of saying, our future is probably a more polyglot one, rather than trying to find one new language for everything, at least as it looks today.

          1. 1

            Thanks for the detailed and thoughtful response, looking forward to hearing more out of those of you that work at Joyent.

      2. 6

        Joyent getting behind OCaml would indeed be a welcome thing. You’ve ruined my day now that I’m thinking about it not happening.

        1. 3

          I’m surprised they’re not using Erlang/OTP. Isn’t BEAM, like, the most observable and debuggable platform ever?

        2. 7

          Wow, that was a great presentation. I was expecting something along the lines of BSD/GPL values dissonance, but it was actually broader than that.

          If nothing else, now I have a name for why some technologies’ popularity is so mystifying to me: it’s just that their communities are built around values I value less highly.

          1. 2

            Looks like these Node Summit 2017 videos haven’t been made public yet.

            1. 1

              Added a note, apologies.

            2. 1

              Based on this talk I’m tempted to ask all engineering teams at $work to try to express their values in order to help with hiring & decision making.

              Bryan crystalizes many thoughts I had but couldn’t quite formulate. Highly recommended watch.

              1. 1

                It would be interesting to see the values embraced by other communities, and/or a bigger list of values to look at.