Hacker News Reader

Comment by PeCaN | Hacker News Reader

What are some cases where I would choose to write a server in Go instead of in Erlang?

As an Erlang fan, my guess is that Go is a bit faster for many things, whereas Erlang's concurrency, fault tolerance, and distributed stories are "better". Not everyone needs all those though. Go is probably a bit more 'generic' - you can do anything with it. Erlang has always felt like it's a tool designed to do a few things really, really well.

I've not used Erlang, but I've also heard comparisons that prefer Go to Erlang for its familiar syntax and comprehensive standard library. Obviously I can't vouch for these claims.

When you want to hire developers.

Hiring good developers for Erlang is easy: just look for functional programmers.

It is indeed hard to hire mediocre developers for Erlang: they stay away from FP.

Great meme bro.

The last place I worked, we built a system that included Erlang. When it was time to hire someone, we found a guy who was curious about Erlang, and although he didn't know it pat, he was a good hire, as he was a smart guy, hard worker, and curious not only about Erlang, but a lot of stuff.

That's the kind of person you want to hire anyway, unless you are super crunched for time in getting someone up to speed.

Never had a problem finding or training great Erlang engineers, and even had a few cases where the absolute best of the candidates were only interested because they'd get to use Erlang.

(shrug).

> When you want to hire developers.

When you want to hire good developers pick Erlang, Elixir, Rust, Haskell, ML, LISP. Because chances they went out of their way to learn the language as it is not taught in US universities in depth. They are probably curious, good learners and could probably learn or adapt to other new things thrown at them.

I am at shop were we use Erlang and syntax has not phased new people that much. If typing . instead of ; is a big deal, then what are they doing to do when a netsplit hits or they have to understand other concurrency issues.

I don't know, I find Erlang's syntax rather nice, if anything it tells my brain "this is not C anymore, don't think like C". Works for me, any way.

There is Elixir of course if syntax is an issue. Elixir has other useful features as well but still runs on the same battle proven platform.

I've also found though that these languages attract primadonnas who care more about "attractive" code and getting to play with cutting edge technology that might not be ready for prime time yet than they care about providing business value.

Edit: fixing typo. Pay -> play

Agreed. I've seen that too.

Then Go should be in the list too. In fact any language that's trending is automatically in that list.

The only languages that don't attract prima donnas are the "not hip" ones like Java, C++, C#, Perl, etc.

Not really. Considering Go does not offer features that PL theory enthusiasts love, it remains a boring language.

I don't think it's about features, but rather a combination of fashion, chance and some other key element (such as author, supporting company, etc) that in addition to the technical merits lead to a piece of technology becoming cool and liked.

Interestingly Go programmers have turned lack of features into a definining feature in itself and are proud of it. If you want to be oart of the in crowd you have to use that signal.

To those replying with anecdotes about how you managed to hire or train an Erlang developer, you missed this part of the presentation: "Go is an answer to problems of scale at Google."

You are scared of Erlang because it has uglyish syntax. Only reason I can think of. The "need to do computation" argument is silly. Just call into a C lib from Erlang.

I think you're replying to the wrong person - they just asked a question about when Erlang might be a good fit.

> Just call into a C lib from Erlang.

That's easier said than done. Certainly possible, but it's not quite as easy as just linking and calling.

I've found dropping down to C to be a pain to set up the first time in any language (Ruby, Tcl, etc...) but once you have the tooling, it's just another workflow. When you think about it, even JavaScript takes a lot of setting up these days (preprocessors, linters, endless debates about why coffeescript is still a good language (hint: it's the existential operator)). But, you amortize the cost of this setup over the lifetime of the project so they are actually quite small.

But, it does seem that there are not regular blog posts about how to drop into C to make even the worst scripting language performant. Seems like maybe it's a dying art???

Dropping down to C is pretty cool in a language like Tcl. To toot my own horn, a bit, I worked on those chapters here: http://amzn.to/1U6sFPN

Erlang is a bit different though: if you're really concerned about being 'robust' with it, you don't want to link in some random C code in the main node. Not only could it crash, it might simply block for an unacceptable length of time, messing up the system's internal scheduler and making it unresponsive to events.

So with Erlang, to do things properly, you need to get the architecture right as well, which makes it that much tricker.

I think compared to most FFI API's the NIF interface is extremely clean and straight forward.

See my other reply though: it's not just about the API, which is nice, but about getting the architecture right. It does make the system more robust, but it requires more thought and planning.

Sure. Once you cross that barrier, you now have unlimited ammo and all the feet that ever were or will be, so you have to be a lot more diligent about what you're doing.

I guess my point is that in, say, Tcl, you pretty much just worry about calling out to the C code and if it takes 2 seconds to process an image or whatever, so be it. You merrily go about your business once the call returns. In Erlang there's more to think about.

I think that's technically true in Erlang as well... it's just that it makes all the other stuff that people expect from Erlang to mostly stop working smoothly. :-)

When your server has to do some computations to return results.

Erlang is bad at that.

Such as what exactly? "Computations to return results" is rather generic, to say the least (and, if ‘computations’ includes handling requests, something that servers tend to always do).

C is best at problems that are CPU and memory bound, Go can handle problems that are CPU bound-ish and goroutines help with IO bound problems. Erlang handles problems that are MASSIVELY IO bound.

I think it's fairer to say that "Go is better at that". "Bad" depends on the user and their needs. In some cases, Go is "bad" at that too and you should use C. In that case, you could always connect the C code to either Go or Erlang, although that introduces complexity into the system you're creating.

First thing on duckduckgo when you search for how to write a server in erlang:

http://20bits.com/article/erlang-a-generic-server-tutorial

That's just ridiculous. Erlang looks like php and python had an unholy child.

What is ridiculous exactly? You just dislike the superficial look of the syntax?

Different stokes for different folks. Looks fine to me. But I'd prefer you don't try to offer advice if you don't actually know Erlang in the slightest.

I won't downvote you because you are certainly entitled to your opinion, and there is no way I'm going to get into an Erlang vs Go For Writing Servers argument, but if you immediately write off Erlang/OTP because of how it looks, you are going to miss out on some pretty amazing server writing functionality.

If all you dislike is the syntax, you can use Elixir instead.

Actually, it was more like Prolog self-pollination with a dash of acid. ;)

But seriously, the syntax is not that big a deal once you've understood it (and being permeable to the history behind it helps).

Before you get all indignant, that's not even a TCP server.

Reply on news.ycombinator.com