Hacker News Reader

Comment by reitzensteinm | Hacker News Reader

I think plinkplonk was saying that it's fine (not necessarily bad) to come full circle in general, not that it will work out in this particular case.

View on HN

"it's fine (not necessarily bad) to come full circle in general, not that it will work out in this particular case."

exactly. I was not saying this step is specifically a bad (or good!) one. I didn't want the thread to devolve into a "which is better Erlang or C++?" flame war. I am sure the devs on the project have good reasons for the change. I just thought it was interesting that the project came full circle.

Yes. Erlang is great for proving ideas and making something work reliably. I have mad respect for Erlang, it's the kind of language where one guy can code a whole a distributed database. But when you need high performance and low level control, and you have the resources and team to make it happen, you really can't beat C. I'll write more about that soon.

Erlang for abstraction and C for performance sounds cool. I'd be interested in how much (or whether) you are using C++ (vs C). I hope you'll address that in your write up.

ep-engine (the core of membase and what handles all of the data moving around between networks, memory and disks) is almost entirely C++.

Are you using any C++ libraries for the networking stuff or plain OS specific socket APIs?

The networking stuff is the memcached engine branch. It's pure C and loads ep-engine as a module for doing all the backend junk.

I wonder if Riak will ever get to this point.

To what point? Already large portions of Riak (the performance-critical ones) are in C, and have been for a long time.

Oh, I didn't realise much of Riak was in C, and the website now mentions Erlang a whole lot less than I remember. Still, in the technology stack http://basho.com/technology/technology-stack/ Riak Core seems to be all Erlang. Bitcask is possibly C--is that what you're referring to?

Your language and line of questioning leads me to assume that you're perhaps not that familiar with Erlang.

Erlang has facilities for running native code within the VM (NIFs and linked-in drivers) and for interacting with non-Erlang processes in an Erlang like way (ports and c-nodes). Extending the VM via these mechanisms is not the default path but it's also not unusual - much of the standard lib is implemented via these mechanisms after all.

To answer your question, bitcask, ebloom, eleveldb, erlang_js and skerl all have c_src directories which suggests they're likely either all or in part implemented via NIFs or linked-in drivers.

EDIT: You might also find http://vimeo.com/17078993 interesting viewing.

Have you considered a language like OCaml or Haskell? You can still get many of the benefits from Erlang while having near-C performance.

Reply on news.ycombinator.com