[erlang-questions] Maturity, models matter - Re: Go vs Erlang

[Tim Watson]

On 28 Mar 2013, at 12:35, Toby Thain wrote:
> 
> Go might shake down in 5 or 10 years into a robust platform (for what, is not clear), but even then the programmer model can still be questioned. It's not like the world needed "another C".
> 

Indeed. I also found the Damian Katz blog post referenced in an earlier post rather interesting, because writing a bunch of C and a bunch of Erlang that go together is - AFAICT - the canonical way to do things (e.g., AXD, ejabberd, Riak, etc) and I know nobody who loves Erlang to be bashing C. Personally I'd rather reach for a library to facilitate 'difficult things' (memory management/gc, atomic opts, concurrency support) in C rather than trying to pick another language that wants to be C. And there's a reason why we write our emulators/vms/containers/etc in C - i.e., beam, the JVM, the CLR, V8 and so on, are all written in C/C++.

So to me, reaching for C when I need to do a fast external call (using a NIF/BIF) or integrate with something long(er) running (or threaded) using a driver seems like the most natural thing to do. And our FFI is very mature and robust - though it'll be a lot more pleasant to work with once 'native processes' appear - so there's no need to worry about competing with systems programming tools like C (or go, I suppose) because you can just reach out and *use* C whenever you like. High level concurrency primitives and declarative programming where you need it and fast, low-latency, highly efficient C when you need that.

Cheers,
Tim