How dangerous are Go’s http stack, Phoenix, or Twisted in these regards? Some of them seem like they are easier to avoid in Go (due to its bounded channels), but I’ve not been working at large enough of a scale to witness bugs from this.
Addendum: I suppose I’d like to understand how much of this is due to node.js being node.js, and how much of this is inherent to the nature of concurrent servers.
The event based programming model is the main reason on these issues.
The current programming languages and tools are based around the assumption that the code can be read as a novel and not as a ‘choose your own adventure book’. There are some solutions to make things simpler (like implementing channels, typed events, continuations…) but every one has its own issues, specially when you have to handle complex I/O events.
Possibly the easiest solution is to keep it as simple as possible and keep the computation to a single loop with non blocking I/O. This has been the way much games work and is straightforward enough if you have good tools to check for loop blocking.
Unfortunately, that limits a lot the kind of projects you can develop, specially if you don’t have clever primitives for I/O.
Personally, after working a lot with node.js in server side programming, I prefer to use node.js event model directly defining few events in systems (get data/process data/reply with data, plus a timer). Unfortunately, no editor has good tools for working with events as first class elements (like functions, variables, classes). That means that having to find manually why an event is not triggering a function is really common (and exasperating) task.
One thing that is nice about Go and Elixir/Erlang is that both of them, via CSP/Actors, make it very easy to create your own event loops, but treat I/O as effectively blocking. But I wouldn’t say that either Go or Erlang are event oriented as such.
What kind of complicated I/O events cause problems with channels, if I may ask?
In the worst case, if you have a multi-stage async operation in progress, it can even result in corrupt or inconsistent data. What else do you expect if you immediately take down the process?
Thinking that your system design can punt on asynchronous interruptions is always wrong. The computer itself can always be interrupted at random points (power loss, network partitions, etc), so you have to deal with crash safety anyway.
Yeah - the thing that was shocking to me, in the Node.js community, is the “just let it crash” mentality with no related “remember to design your system to be resilient to this kind of thing.” It kind of makes sense when you consider the types of people getting pulled into Node.js programming - people who were solely frontend before aren’t necessarily used to thinking about fault-tolerance and data consistency. Hence the article. :0)