5 ms·

Building Resilient Services with Go

• nickpsecurity 11y ago
  Another interesting Go deployment. However, although not about that article, I think HN readers might like this post by the same team on how they do code reviews: http://blog.fogcreek.com/increase-defect-detection-with-our-code-review-checklist-example/ http://blog.fogcreek.com/increase-defect-detection-with-our-... I discovered it while reading the parent article. I think it's a good checklist that will contribute to resiliency better than a language choice. Of course, adding a language with strong type and memory safety to such a good development process will certainly drive quality up from there. Efficiency, too, as recent article indicate.
• davidw 11y ago
  There's a lot there that looks familiar there to the Erlang developer, where many things are built in.
  • seiji 11y ago
    systemd + Docker + Go is basically re-creating Erlang from the ground up, except half broken and not learning from Erlang's 20-30 year history. Now we're training people in the wrong ways to create maintainable distributed systems even when we know better ways to do things. I cry for our industry. It's been said Greenspun's 10th Rule, when applied to distributed systems, results in Erlang.
    • gtaylor 11y ago
      Do you have anything more specific to add? This comment doesn't tell me, a non-erlanger, anything other than that you like it more than systemd + Docker + Go. But clearly there are numerous success stories with this very stack (or some permutation thereof).
      • infamouscow 11y ago
        Erlang programmers have thought about how to solve these problems a lot longer than Go's, for example. The problems being solved today aren't appearing for the first time. You don't see blog posts written about how to do X in Erlang because X has likely been thought about carefully for more than a decade, a best solution to do X likely already exists. Erlang programmers today can worry about building their applications instead of the most fashionable way to do X in Y language. The latest problem Erlang is addressing is regarding leap-seconds and how they can cause all kinds of strange behavior in applications. In Erlang, this is called Time Warp [1][2]. I have yet to see another language try to tackle time correctness, since most are still too busy ironing out the performance of their garbage collector or how to do concurrency. [1]: http://www.erlang.org/doc/apps/erts/time_correction.html http://www.erlang.org/doc/apps/erts/time_correction.html [2]: http://learnyousomeerlang.com/time http://learnyousomeerlang.com/time
        • e12e 11y ago
          The only other example that comes to mind (outside of ntpd), is the TeaTime protocol used for the experimental distributed VR system (Open)Croquet implemented in Squak/Smalltalk: https://lwn.net/Articles/124712/ https://lwn.net/Articles/124712/ But if IRCC the whole premise of TeaTime is to not actually do time "correctly", but rather aim for "mostly predictable ordering of events". Maybe it's time to dust off the old Croquet ideas, and mix the oculus rift with a platform based on Elixir?
    • nvader 11y ago
      Honest question, from one who doesn't want to re-learn the lessons of the past and who would really appreciate a 2 to 3 decade boost. What are the lessons of Erlang, and how do you abstract as much of that as possible away from the language/ecosystem to others? I'm looking for an answer a little more accessible than "you have to learn Erlang to find out."
      • davidw 11y ago
        Joe Armstrong's thesis, ( https://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf https://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf ) has some good stuff. Part of what makes Erlang Erlang is that a lot of this stuff is integrated very deeply into the language and its libraries. It's not just something you can bolt on in many cases.
        • krallja 11y ago
          The parent poster asked for something "a little more accessible" than learning Erlang, and you responded with a 295-page doctorate thesis. Is there something else that one might have a chance at grokking in a single evening?
          • ams6110 11y ago
            Erlang isn't hard to learn.
            • e12e 11y ago
              And Elixir is maybe easier. I believe the documentation is making strides, but last I checked there were some rather opaque references to Erlang OTP, and other things that aren't exactly obvious. http://elixir-lang.org/ http://elixir-lang.org/
          • tmm 11y ago
            Perhaps not readable in a single evening, but this is probably the most accessible thesis I've ever read. If you don't care about the history or motivation behind Erlang, just skip to chapter 3. However, I think the "why" of Erlang is pretty compelling in and of itself, especially if you're interested in extremely high-availability telecom hardware with an operational life measured in decades.
    • vezzy-fnord 11y ago
      Well, not quite. systemd and all other process managers supervises OS processes, Erlang only supervises its own VM processes which are green M:N threads. Though one could in principle supervise an OS process as a port driver, you will need to wrap POSIX/Win32/$PLATFORM semantics to do it to the fullest extent. OS-level virtualization is also completely orthogonal.
      • rdtsc 11y ago
        Conceptually it is still building a system of concurrent units, which are also isolated from each other's memory space. Erlang's VM is like a mini OS for your backend system except that it can handle a million isolated processes while the OS can handle a few orders of magnitude less.