Hacker News Reader

Comment by rumcajz | Hacker News Reader

The article is about undefined behaviour. Erlang won't help much with that.

Depends how you write your code. Actually Erlang is pretty good at avoiding undefined states (which can be thought of as undefined behaviour) by putting everything in an OTP framework. There's no custom "I'll just handle this earlier here in a tricky way" - if you stick to OTP you'll have message handlers and state machines. That's really awesome if you're programming network daemons. You can pretty much follow the state machine diagram and make sure that unless some progression is possible, it will not occur in practice.

Testing based on OTP service trees also makes the verification fit the possible transitions in a much closer way than trying to cover all the branches in an OO app.

So yes, I'd say it's actually quite a good response to an "exception handling all over the place" problem. You simply don't do that. Instead your exceptions finish at the FSM level and progress you to one of the error states on your diagram. You know exactly what state you're in at that point so the behaviour is pretty well defined at almost every step.

However zeromq is a library that was supposed to be portable, rather than a daemon itself, so from that perspective, it's a very bad fit for ZMQ.

What worried me about Erlang was that when a process dies and gets restarted, the message queue for the old process gets thrown away. Neither the sender(s) nor the new process can tell how many messages were lost.

If you care about reliability of the delivery, you can do a number of things: do a single call, wait for response and retry if needed, or store the messages in mnesia and only notify there's something to pick up (pull scenario with ack), or do a number of other possible things.

Lost messages are a fact of life really - the same will happen with any other system - either you persist the message and ack the reception on every stage or you risk dropping the queue.

Yes, that situation is usually handled by using an ETS table to store messages (essentially, you create an internal message queue for the supervision tree).

On the other hand, there's no guarantee the message arrived in the first place (especially when using multiple nodes) unless you use ack patterns.

Well, yes and no. I know more about OCaml than Erlang, but pattern matching and guards let you be very sure that a function is going to handle every possible input, and static typing means all code paths can be verified at compile time - there's no way into or out of a function without the program being in a valid state.

What about, say, a function that puts ten elements into a list that needs to get sent a receiver that only expects nine ? Or a network call that returns an unparseable reply?

In the first case, I wouldn't use a list for that, but a record/struct/class with 9 fields. In the second, I would use an Either/Maybe type, or raise an exception (these work differently in OCaml than in C++)

Firstly the article is about the use of C++ vs C in ZeroMQ (crossroads). Then the article is about systems having a high uptime and how C++ is not ideal for that.

Here is the quote:

> First, it's important to take into account that ZeroMQ was intended to be a piece of infrastructure with continuous uptime

So it is about uptime, that's the supposed goal of someone using ZeroMQ. C++ has undefined behavior and this, the author claims, can lead to more crashes and reduce uptime.

Then nirvana suggested that if uptime is needed, there is a better language and platform designed for it.

Reply on news.ycombinator.com