GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-09-06) - page 2 of 10
 
___________________________________________________________________
Stuff Goes Bad: Erlang in Anger (2016)
261 points by mutor
https://www.erlang-in-anger.com/
___________________________________________________________________
 
ishtu - 11 hours ago
Related: http://spawnedshelter.com/
 
  luketherrien - 9 hours ago
  That is an awesome site. Does anyone know if there's a similar
  resource for JavaScript that gives high and low level information
  about the language?
 
    FLGMwt - 8 hours ago
    There's a "thanks" section at the bottom that linked to
    http://superherojs.com/ which seems to be the same thing for JS
    : )
 
    weaksauce - 3 hours ago
    you don't know javascript is fantastic at the more advanced
    stuff.https://github.com/getify/You-Dont-Know-JS
 
SomeStupidPoint - 10 hours ago
Erlang (even though I only use it via RabbitMQ) forever changed how
I think of reliable systems.Hardware has always been a story of
reliably operating unreliable parts. It was eye-opening to see the
same concepts applied to software.Fail fast, fail early!(Also,
Erlang did a really good job of lightweight threading, and how that
interlaces with things like a cluster of servers.)
 
  whyever - 10 hours ago
  > Hardware has always been a story of reliably operating
  unreliable parts. It was eye-opening to see the same concepts
  applied to software.Walter Bright has been advocating this for
  some time:http://www.drdobbs.com/architecture-and-design/safe-
  systems-...
 
    igouy - 6 hours ago
    http://erlang.org/download/armstrong_thesis_2003.pdfSee 2.10
    Related work.
 
kaycebasques - 5 hours ago
Erlanger
 
mac01021 - 9 hours ago
http://www.ldoceonline.com/dictionary/do-use-something-in-an...(I
had never heard this idiom before)
 
  twoquestions - 2 hours ago
  I've heard it mostly in military contexts, like "That ship has
  never fired her guns in anger", but otherwise not.
 
maxfurman - 8 hours ago
I don't use Erlang or Elixir but I love the idea of this book. Are
there any similar troubleshooting guides for other languages?
 
  dmix - 8 hours ago
  There is a book like this for Ruby (on Rails?) which I believe is
  the inspiration for this Erlang book. I just can't seem to find
  it at the moment.It was about improving old/legacy/poorly-built
  code bases that are in a bad shape and need to be 'rescued'.
 
    mononcqc - 8 hours ago
    I have not read any Rails book ever and they could therefore
    not be the inspiration for this one :)The true rationale behind
    the book was to give a better tool to train new coworkers that
    could help us operate the Erlang routing and logging stacks
    back when I was still at Heroku, and at the same time to
    provide similarly useful resources to other people maintaining
    similar software in the broader community.Most of the
    operational aspects of Erlang were a bit of black magic,
    knowing where to dig through experience, having read the right
    kind of docs, and everyone would carry little gists of
    incantations and anonymous functions to run on production
    servers to help figure out what may be going oddly on there by
    correctly prodding at the VM.I wrote the 'recon' library along
    with Erlang in Anger so that instead of just being black magic
    & oral tradition, people would have a better set of well-
    encoded practices to help approach the debugging and
    optimization of running systems.
 
      dmix - 7 hours ago
      Fair enough, the landing page and description just seemed
      similar to the one I remember for Ruby, that's all. Although
      that was more about rescuing a project rather than overcoming
      common barriers in a programming language.Sounds like a great
      basis for an advanced programming book either way.
 
  brudgers - 7 hours ago
  There is a sense in which it is not possible to write a similar
  book for other languages. Erlang's "Let it crash" design
  philosophy is more or less unique among languages used as much as
  more than Erlang. This means the definition of 'trouble' which
  requires troubleshooting will tend to be different when trouble
  is not an error in business logic. Likewise the details of
  implementing solutions will be different, for example handling a
  high frequency of crashes by making 10x the number of concurrent
  actors available to the system.{A Love Song to Erlang} I think
  Erlang is a beautiful piece of engineering design as engineering
  design. I would not say that about any other language and find
  other languages beautifully designed for other reasons. But
  Erlang is an engineer's tool designed based on engineering
  principles. The abstractions are engineering abstractions...but
  with garbage collection.
 
okket - 11 hours ago
Previous discussions:https://news.ycombinator.com/item?id=8330501
(3 years ago, 54
comments)https://news.ycombinator.com/item?id=8979267 (3 years ago,
21 comments, dupe)
 
jlouis - 11 hours ago
Still a recommended book if you need to handle Erlang systems.
Either as a developer or as an operator.* Still good if you work
with Elixir* Good if you have, say, RabbitMQ or Riak in your stack*
Fred knows his stuff.
 
  zzzcpan - 11 hours ago
  Even if you don't need to handle Erlang systems, there is still
  enough to learn if you need to build reliable systems.
 
  sotojuan - 11 hours ago
  Most great Erlang resources, like this and Designing for
  Scalability, are very much recommended for Elixir programmers.
  It'd be a shame for them to disregard some of the best OTP
  resources just because they're in Erlang.
 
    s_kilk - 11 hours ago
    Just a quick +1 for "Designing for Scalability", as an avid
    Elixir programmer. It's a great book on the Erlang/OTP
    fundamentals which underlie Elixir and Phoenix.
 
    polack - 8 hours ago
    I'm going to go against the stream an say -1 on "Designing for
    Scalability". Not that it isn't a good book, but the title
    doesn't really reflect the contents. It's more of a beginners
    book on Erlang/OTP than of scalability.
 
      derefr - 3 hours ago
      Do you have a recommendation for a more advanced book on that
      particular topic?I'd also love to see something from the
      other angle: taking a program that's already an instantiation
      of a complex, distributed architecture, written in e.g. C,
      and then rewriting it in idiomatic Erlang (or
      Elixir?especially with GenStage/Flow stuff) to reduce its
      code size while retaining the same distributed-system
      properties as its ancestor system.
 
  rdtsc - 6 hours ago
  Agreed.Remsh and recon are tools I use almost every day.Chapter 3
  planning for overload is useful in general not just for Erlang
  systems, and is something that is not given enough consideration
  usually.
 
    mononcqc - 6 hours ago
    I've since written a fairly complete blog post only on overload
    management of asynchronous systems at https://ferd.ca/handling-
    overload.html -- it hasn't made it in the book, though.
 
      davidw - 5 hours ago
      Wow, wonderful post that I hadn't read yet.In particular the
      'fuse' type stuff is really important when you have a real
      world system where "let it crash!" is not really ok, because
      you have, say, a user interface, or a web server that should
      not be part of everything just crashing.  In particular,
      something I've seen: if your Erlang application talks to a
      database, and the database goes down for some reason, it may
      be desirable to have the whole application not go down with
      it!Thank you!