"Erlang Solutions" says Erlang is the bee's knees...<p>I really like when someone that doesn't have a horse in the race reviews some language (better if it has been used in anger). You gotta value the perspective of a pragmatic engineer that has misapplied a tool.<p>There's a lot to learn about where a language is best used, but when someone pay is somewhat tied to a language I don't trust the analysis as much.
I'm currently writing a GUI for industrial automation, where we have to talk to a number of machine control threads and image processing threads (all through a procedural interface that connects to other processes).<p>I'm writing in C and decided to stay in a single OS thread and to instead write my own simplistic user thread scheduler. User thread ("green threads") work by simply switching call stacks and saving registers. In my case this is as simple as making a few Windows API calls like CreateFiber() or SwitchToFiber().<p>It's one of the best things I've ever done. Maybe 1 day of work to get the threads rolling, no bugs, and still in a familiar C environment. No bindings required to interface with the libraries that I <i>need</i> to interface with (like Qt) and perfect deterministic control over what happens (just not the other processes of course).<p>I think I can understand people are not using C doing web stuff (lots of strings) but for what I do I'm convinced it's the easiest, fastest to develop, most performant, most robust thing you can do.
The article briefly mentions the similarity of online betting to stock markets, when it is about the requirements for stability and real time processing without long GC delays.<p>This makes me wonder why Erlang/ Elixir are used so little in the financial industry? I have been working for a couple of financial firms and even a HFT company but I have never seen Erlang being used, despite its apparent advantages.<p>Does anybody know why this is? Or is Erlang actually being used a lot in finance and have I just been working in the wrong places?
That was poorly written. And amazingly, the author neglected to shed light as to why Erlang has a more a 'complete' story in regards to distributed f/t systems ("reliability", "concurrency").<p>Erlang has OTP, Go does not. Erlang is FP, Go is not. These are the critical differences.<p>Silver lining (in context of OTP) for Go is that the du jour 'cloud' based architectures will provide the OTP like capabilities ("elastic", "fail-over", etc.) for deployed (micro-)services. It seems that in the (future) long-term, Go is better positioned than Erlang for cloud based systems.
Would be curious to see Pony added to the mix. It has the best of both worlds for my tastes, from Go: statically typed and native code, and Erlang: actor model, GCd at the actor level. Plus more features that neither has like capabilities.
As someone who works in this industry, the biggest issues are (besides like stuff like match-fixing and illegal internal trading/leaks):<p>1. Highly domain-specific legacy pricing model running on... Excel spreadsheets. These present huge performance bottle-necks and aren't easy to migrate.<p>2. Reliance on 3rd Party data. Did a scout just send incorrect data? Did their device disconnect? Did they rollback the wrong information? Is the source lagging behind the TV/online feed? GGs. Suspend the game and refund bets.<p>The tooling really isn't that important. Scalable software can be written in any software, and while some languages do make things simpler, often you can just also find a suitable paradigm (or middleware) that can provide similar advantages. Having said that, we do make extensive use of RabbitMQ (which is written in Erlang) in our environment. I suppose this is also just an example of my previous point though...
I spent a few years working at the UK's largest betting exchange, I could tell you what language we used for bet matching and so on but you wouldn't believe me...
I am really interested in some numbers to show how much the Go's GC harms program performance. I wonder if this is really an issue for an online service, given the stop-the-world phases are usually <1ms. Does anyone have some material on that?
What a terrible article. It's spam designed to get hits for bookmaker CTOs scouting around.<p>No benchmarks, no numbers, no real detail, just empty praise for Erlang from a company called "Erlang Solutions".
What a garbage article, Go is faster that Erlang and not by a small margin, same for the GC. Erlang has definitely its place in some scenarios but the article reflects it poorly by trying too hard to dismiss Go.