Kind of light on the tech details, but what with all the breathless "we replaced 8492 Java and Ruby servers with one 386 machine running Go!" pieces, it's worth a look.
FWIW, we built a team of Elixir developers in the spring of 2014 in Austin Texas. Austin is not the bay area, it's maybe a Tier 3 startup town. And still we were able to build a great team over the course of a few months.
At the time, Elixir had not hit 1.0 and while there's a lot of overlap between elixir and erlang this is a good comparison because Elixir is a lot less common than erlang.
Here's the thing-- by having that filter of using this language-- a good language-- we self selected for good engineers because the good engineers were either already using it or were very interested in it. I for one, for instance, came to that job, relocating across the country just because I wanted to work in that language.
I learned Erlang on the job when I started at an Erlang shop, in between taking care of existing php stuff. It's not super hard: the syntax is weird, but at least whitespace isn't significant.
There seems to be a pervasive sentiment that developers can't learn erlang.
There is a learning curve, and you're going to want to seed your staff with expertise (it sounds like bet365 did this), but there's no reason that a competent developer can't learn this or any other functional language.
And given the increasing usage of Erlang, it's a good skill to pick up - so if you have the opportunity to learn it as part of a job you already have, so much the better.
Guys who designed the LMAX 'disrupter' for Betfair have a good talk about how much trading these betting sites do per second http://www.infoq.com/presentations/LMAX and how concurrency is a major issue, Erlang makes sense even if they have to search for replacement devs
I don't think bet365 does the kind of volumes a popular betting exchange would, but I do agree they are probably the kinds of traffic volume that can benefit from Erlang.
Exchange workloads are trivial, but sports betting requires a lot more work per transaction. This is mostly to do with liability management. I talk a little about this here:
i wonder whether they considered scala so they could stay on the JVM (no mention of it in the OP). i don't know Erlang but i develop in scala (w/ Akka) and always interested to know how the two languages are different/similar w/r/t enabling devs to build build distributed systems.
If you read the article he mention that his company needed low latency.
Java doesn't have a preemptive scheduler.
An example would be, an infinite loop.
If you have an infinite loop in a msg pass to an actor then that message will use the Actor forever in Scala. Because the scheduler is not preemptive.
For Erlang, it'll let that msg (infinte loop) run for a small amount of time, put it back in the queue/mailbox and run another task for some time and etc..
Also all actor in Erlang are new processes, so if a process fail it doesn't take down the main process. I've talked to an Akka company and apparently you can spawn actor for akka in same thread/process.
IIRC actor in Scala had a weird caveat in coding too. But it's been so long since I've used Scala.
The article mentioned small language in Erlang. Erlang gives you primitive to create distributed language. As in it's built into the language to spawn a process, to link the process together and monitor it, etc...
With Scala it's a library.
Also Erlang isn't just a programming language it's the run time, as you can see with premptive scheduler and etc.. Erlang is powerful because it BEAM or it's VM.
19 comments
[ 2.7 ms ] story [ 66.2 ms ] threadAt the time, Elixir had not hit 1.0 and while there's a lot of overlap between elixir and erlang this is a good comparison because Elixir is a lot less common than erlang.
Here's the thing-- by having that filter of using this language-- a good language-- we self selected for good engineers because the good engineers were either already using it or were very interested in it. I for one, for instance, came to that job, relocating across the country just because I wanted to work in that language.
There is a learning curve, and you're going to want to seed your staff with expertise (it sounds like bet365 did this), but there's no reason that a competent developer can't learn this or any other functional language.
And given the increasing usage of Erlang, it's a good skill to pick up - so if you have the opportunity to learn it as part of a job you already have, so much the better.
If syntax is their main complaint, chances are, they'll fall face first handling distributed code or supervision hierarchies.
https://www.youtube.com/watch?v=zVUPmmUU3yY
If you read the article he mention that his company needed low latency.
Java doesn't have a preemptive scheduler.
An example would be, an infinite loop.
If you have an infinite loop in a msg pass to an actor then that message will use the Actor forever in Scala. Because the scheduler is not preemptive.
For Erlang, it'll let that msg (infinte loop) run for a small amount of time, put it back in the queue/mailbox and run another task for some time and etc..
Also all actor in Erlang are new processes, so if a process fail it doesn't take down the main process. I've talked to an Akka company and apparently you can spawn actor for akka in same thread/process.
IIRC actor in Scala had a weird caveat in coding too. But it's been so long since I've used Scala.
The article mentioned small language in Erlang. Erlang gives you primitive to create distributed language. As in it's built into the language to spawn a process, to link the process together and monitor it, etc...
With Scala it's a library.
Also Erlang isn't just a programming language it's the run time, as you can see with premptive scheduler and etc.. Erlang is powerful because it BEAM or it's VM.