[falcolas]

Go's panic() acts similarly to what you're expecting out of Erlang. You still have to call it for other libraries.

> so it's not possible to "forget" to check for a null reference like you do in Go

The Go compiler will complain if you don't use the `err` variable after creating it, helping to make you remember to check it, and letting you branch accordingly. This doesn't help with someone who re-uses the err variable or assigns the error return to `_`, but those are conscious choices to bypass the checks Go adds for you.

[rdtsc]

> Go's panic() acts similarly to what you're expecting out of Erlang. You still have to call it for other libraries.

Go uses a shared heap. So even though one go-routine panics, you can't safely assume the state of your system is still predictable. If it is not predictable you can't necessarily safely restart that go-routine.

Without Erlang/Elixir I would actually do it with OS processes / containers at a higher level. Erlang's processes are only a few K of memory and are very easy to restart and handle so you get all that built in.

[falcolas]

To be fair, if you're modifying the heap from a goroutine, you're "doing it wrong". Go provides channels, which work quite well at reducing the need to mutate the global state. I use such a pattern quite frequently (the http.Server), and have never had a problem with heap corruption due to a handler goroutine panicing.

[rdtsc]

That's true. To that extent C, C++, Java work took. The Threads + thread safe queues is a common paradigm I've used. The problem comes with using other libraries, sharing code with others in a large code base. But errors and concurrency bugs still happen.

But just like type systems, they are there not just to make code faster but add some guaranteed safety. The guaranteed is important. In case of concurrency, errors and state, the isolated heap also adds that guarantee. That is important.

[falcolas]

There is a cost, though. Low enough to bear in most cases, but transferring more state through IPC, the overhead of starting new processes, context switching between processes, duplication of in-memory structures; these can add up to make an equivalent Erlang program much more heavyweight on a system than a Go program using many goroutines.

Right tool for the job, yadda yadda. :)

[ad_hominem]

Erlang processes are nothing at all like Unix processes. They are much, much smaller memory-wise as well as in terms of spawning/killing speed as they do not rely on system calls but rather the Erlang VM (which is highly tuned for these purposes).

Yes, there is a small overhead incurred when copying data between processes because the VM is truly copying the data[1], but the benefit gained is that you get per-process heap isolation (references can't cross process heap boundaries). This is important because in languages like Java or Go, one misbehaving bit of code that is causing a lot of GC to happen can "stop-the-world", and make your entire system pause (and it does happen[2]). This is not acceptable when writing soft real-time code, like say an auction system.

I'm not sure why you think an Erlang program is more heavyweight than Go. Is it due to Go programs being compiled to binary? Erlang can do that as well,[3] although it's not often done as Erlang requires a runtime, and it's often simpler to use a separate runtime. But you should know that Go also requires its own runtime to run Go programs[4], it's just that it is statically linked into your compiled code (which is what makes the resulting binaries so huge). But Erlang could do the same thing, it's just not really an industry practice.

[1]: http://jlouisramblings.blogspot.dk/2013/10/embrace-copying.h...

[2]: https://groups.google.com/d/topic/golang-nuts/S9goEGuoMRM/di...

[3]: http://erlang.org/doc/man/compile.html

[4]: http://golang.org/doc/faq#Why_is_my_trivial_program_such_a_l...