5 ms·

Question: I am considering learning Go or Elixir to develop the backend for a high-frequency financial application. Focused strictly on concurrency and scalabil

by ak_111 3y ago

Question: I am considering learning Go or Elixir to develop the backend for a high-frequency financial application. Focused strictly on concurrency and scalability benefits of each, which would be the better choice? Granted they are probably both great at highly parallel and distributed computing applications, I am just wondering if there is an interesting differentiation between these two in this aspect that I should be aware of.

bmitc 3y ago
Without more details, you're just going to get people's favorite language recommended or about how neither are suited to high-frequency trading applications.
- ak_111 3y ago
  My question is more general: what are some relative pros/cons of Go vs Erlang/Elixir when it comes to their approach to concurrency?
  - bmitc 3y ago
    I don't really know about Go. I favor functional languages, and so I am drawn to Erlang and Elixir. I recommend watching Sasa Juric's talks on YouTube to best understand Erlang and Elixir's concurrency features. One of his talks is posted elsewhere in this thread already.
  - ramchip 3y ago
    I replied more in details elsewhere in the comments, but in a nutshell Erlang/Elixir processes are a tool to contain errors, and they make some opinionated design choices to achieve that. Goroutines are a pure concurrency primitive, they don't contain errors. A goroutine crashing will take down the entire program. Elixir would be absolutely beautiful for a trading program - you could run each strategy (trading algorithm instance) in a separate process, so that a bug in one of them can't take down the whole system, and use monitors to guarantee orders are cancelled if a strategy crashes. I actually started learning it because I worked on such a system, and it was hard to sleep at night when any small coding error in the giant C++ codebase could send the whole thing crashing. It would definitely be too slow for HFT though :)
    - ak_111 3y ago
      This is great, really appreciate your insight as you seem to have good experience with both.
cpursley 3y ago
Build a POC in both and go with what you like working with the most.
sethammons 3y ago
Having used both, I think Go has better performance and due to its static typing you can reason about functions since their parameters are explicit. This scales better as the org grows. Elixir lets you define a spec but it is not enough. I routinely had to go several callsites up the stack ti understand the parameters. However, I heard static types are on their way and that is huge. Elixir has GenServer and BEAM niceties which is something you'll have to replicate, likely poorly, in another environment. As for learnability, meh. Have a senior on staff and new employees will be able to learn either. Elixir has Phoenix, liveview, and Ecto. You'll just have to look into them, but they are good. The game changer is iex, you can terminal into any running process in the cluster and interact with it. For me, I'm much more experienced in Go and would leverage managed kubernetes if I needed to cluster. I think it scales better for larger orgs. If it is a core group of one small team, Elixir is pretty rad.
- ak_111 3y ago
  Thanks, this covers all the angles quite well. What would be the closest equivalent to Phoenix/liveview for Go (as in best django-like stack).
  - sethammons 3y ago
    Nothing really; and nobody has a thing like liveview that I'm aware of. For Go, I use a request router (chi) and some helper packages for mundane things like reading env configs. I write the backend as an http api and then have a separate frontend, currently learning svelte for that. Go is very batteries included.
- icedchai 3y ago
  I recently started learning Elixir and find it super interesting (along with Erlang.) The paradigm is so different. Mostly I am looking at it for hobby projects. It reminds me a bit of OpenVMS, where the OS had built in clustering facilities, processes had mailboxes, etc. I've done a bit of Go in the past and it definitely has its place, too. It feels more mainstream. We converted a Python app to Go a few jobs back and the performance increase was incredible.
jerf 3y ago
Comparison on concurrency: https://news.ycombinator.com/item?id=34564228 https://news.ycombinator.com/item?id=34564228 On scalability, given that high-frequency financial applications are generally super performance sensitive, or at least have a reputation of such, I would probably consider the BEAM VM disqualified (not the slowest language but definitely not the fastest) and even still have some serious questions around Go. I like to characterize it as the one of the slowest members of the fastest class of languages; yes, it's compiled, and that means it generally beats interpreted and VM-based languages, but it's definitely on the slower end of compiled languages due to its prioritization of compile speed over optimization time. In the case where I ported a system straight out of Erlang into Go, without a rearchitecture, pretty much a straight port, the Go system was 5-10x faster than the Erlang system, and I'd expect that to hold. BEAM made some decisions back in the 90s that give it some significant performance headaches nowadays... not fatal for all uses by any means, it's completely possible to build a reasonable system on it, but if raw computational performance is high on your list of needs it's got some nontrivial disadvantages.
- h0l0cube 3y ago
  > if raw computational performance is high on your list of needs it's got some nontrivial disadvantages. That's what Rustler, Zigler, and Numerical Elixir (Nx) solve. It doesn't mitigate issues around deep copies when passing messages between processes, but the absence of shared memory means that race conditions aren't a problem to worry about, and the memory model is such that garbage collection is never going to be a performance issue even if you scale up to millions of processes per node. It also means you can trivially scale horizontally across multiple nodes because your code doesn't (more accurately can't) depend on sharing memory.
  - jerf 3y ago
    I've been hearing "You can use this slow language and just plug in to a faster one when you need more speed" for over two decades now, and it still has yet to impress me in practice. It's still too easy to accidentally stray back into the slow language for extended periods, and it's virtually guaranteed when it's the "glue layer". Rust straight-up solves race conditions on its own terms, it is not hard to program Go in a way that doesn't have them, etc. It's easier just to write in the fast language in the first place. Also, I think the BEAM GC is widely misunderstood. Per process it's kinda neat that it can GC without having to consider the others. But globally it's actually kinda slow. Like I said, I've straight-up ported Erlang programs into Go, network clustering and all, and Go was quite significantly faster, even with the not-so-great GC Go had in the ~1.6 era. (I suspect if I ran the same code now it would just work with no GC problems.) BEAM GC is more "hey, look at this neat trick!" than "better than anything around". I actually wouldn't consider it very good at all in modern terms. The Erlang community has a huge problem with thinking it's still 2003 and comparing Erlang to all the other competition in 2003, but unless you're still living in 2003, you need to be comparing to what's around in 2023.
h0l0cube 3y ago
This was in a top level comment on this post. It perfectly articulates what sets Erlang/BEAM/Elixir apart from other runtimes/languages. Essentially performant, fault-tolerant parallelism by design. https://www.youtube.com/watch?v=pO4_Wlq8JeI https://www.youtube.com/watch?v=pO4_Wlq8JeI If you need to break out into SIMD, you also have NX at your disposal. And Rustler/Zigler provide you an escape hatch to low-level languages, with the latter you can code in Zig inline https://github.com/elixir-nx https://github.com/elixir-nx https://docs.rs/rustler/latest/rustler/ https://docs.rs/rustler/latest/rustler/ https://hexdocs.pm/zigler/Zig.html https://hexdocs.pm/zigler/Zig.html
rramadass 3y ago
This top-level comment in this thread links to a excellent case-study which presents an architecture that may answer your question - https://news.ycombinator.com/item?id=37418015 https://news.ycombinator.com/item?id=37418015 For performance, drop down to C/C++ (carefully); 1) https://stackoverflow.com/questions/1811516/integrating-erlang-with-c https://stackoverflow.com/questions/1811516/integrating-erla... 2) https://news.ycombinator.com/item?id=14771658 https://news.ycombinator.com/item?id=14771658

by ak_111 3y ago

bmitc 3y ago

Without more details, you're just going to get people's favorite language recommended or about how neither are suited to high-frequency trading applications.

ak_111 3y ago
My question is more general: what are some relative pros/cons of Go vs Erlang/Elixir when it comes to their approach to concurrency?
- bmitc 3y ago
  I don't really know about Go. I favor functional languages, and so I am drawn to Erlang and Elixir. I recommend watching Sasa Juric's talks on YouTube to best understand Erlang and Elixir's concurrency features. One of his talks is posted elsewhere in this thread already.
- ramchip 3y ago
  I replied more in details elsewhere in the comments, but in a nutshell Erlang/Elixir processes are a tool to contain errors, and they make some opinionated design choices to achieve that. Goroutines are a pure concurrency primitive, they don't contain errors. A goroutine crashing will take down the entire program. Elixir would be absolutely beautiful for a trading program - you could run each strategy (trading algorithm instance) in a separate process, so that a bug in one of them can't take down the whole system, and use monitors to guarantee orders are cancelled if a strategy crashes. I actually started learning it because I worked on such a system, and it was hard to sleep at night when any small coding error in the giant C++ codebase could send the whole thing crashing. It would definitely be too slow for HFT though :)
  - ak_111 3y ago
    This is great, really appreciate your insight as you seem to have good experience with both.

cpursley 3y ago

Build a POC in both and go with what you like working with the most.

sethammons 3y ago

Having used both, I think Go has better performance and due to its static typing you can reason about functions since their parameters are explicit. This scales better as the org grows. Elixir lets you define a spec but it is not enough. I routinely had to go several callsites up the stack ti understand the parameters. However, I heard static types are on their way and that is huge. Elixir has GenServer and BEAM niceties which is something you'll have to replicate, likely poorly, in another environment. As for learnability, meh. Have a senior on staff and new employees will be able to learn either. Elixir has Phoenix, liveview, and Ecto. You'll just have to look into them, but they are good. The game changer is iex, you can terminal into any running process in the cluster and interact with it. For me, I'm much more experienced in Go and would leverage managed kubernetes if I needed to cluster. I think it scales better for larger orgs. If it is a core group of one small team, Elixir is pretty rad.

ak_111 3y ago
Thanks, this covers all the angles quite well. What would be the closest equivalent to Phoenix/liveview for Go (as in best django-like stack).
- sethammons 3y ago
  Nothing really; and nobody has a thing like liveview that I'm aware of. For Go, I use a request router (chi) and some helper packages for mundane things like reading env configs. I write the backend as an http api and then have a separate frontend, currently learning svelte for that. Go is very batteries included.
icedchai 3y ago
I recently started learning Elixir and find it super interesting (along with Erlang.) The paradigm is so different. Mostly I am looking at it for hobby projects. It reminds me a bit of OpenVMS, where the OS had built in clustering facilities, processes had mailboxes, etc. I've done a bit of Go in the past and it definitely has its place, too. It feels more mainstream. We converted a Python app to Go a few jobs back and the performance increase was incredible.

jerf 3y ago

Comparison on concurrency: https://news.ycombinator.com/item?id=34564228 https://news.ycombinator.com/item?id=34564228 On scalability, given that high-frequency financial applications are generally super performance sensitive, or at least have a reputation of such, I would probably consider the BEAM VM disqualified (not the slowest language but definitely not the fastest) and even still have some serious questions around Go. I like to characterize it as the one of the slowest members of the fastest class of languages; yes, it's compiled, and that means it generally beats interpreted and VM-based languages, but it's definitely on the slower end of compiled languages due to its prioritization of compile speed over optimization time. In the case where I ported a system straight out of Erlang into Go, without a rearchitecture, pretty much a straight port, the Go system was 5-10x faster than the Erlang system, and I'd expect that to hold. BEAM made some decisions back in the 90s that give it some significant performance headaches nowadays... not fatal for all uses by any means, it's completely possible to build a reasonable system on it, but if raw computational performance is high on your list of needs it's got some nontrivial disadvantages.

h0l0cube 3y ago
> if raw computational performance is high on your list of needs it's got some nontrivial disadvantages. That's what Rustler, Zigler, and Numerical Elixir (Nx) solve. It doesn't mitigate issues around deep copies when passing messages between processes, but the absence of shared memory means that race conditions aren't a problem to worry about, and the memory model is such that garbage collection is never going to be a performance issue even if you scale up to millions of processes per node. It also means you can trivially scale horizontally across multiple nodes because your code doesn't (more accurately can't) depend on sharing memory.
- jerf 3y ago
  I've been hearing "You can use this slow language and just plug in to a faster one when you need more speed" for over two decades now, and it still has yet to impress me in practice. It's still too easy to accidentally stray back into the slow language for extended periods, and it's virtually guaranteed when it's the "glue layer". Rust straight-up solves race conditions on its own terms, it is not hard to program Go in a way that doesn't have them, etc. It's easier just to write in the fast language in the first place. Also, I think the BEAM GC is widely misunderstood. Per process it's kinda neat that it can GC without having to consider the others. But globally it's actually kinda slow. Like I said, I've straight-up ported Erlang programs into Go, network clustering and all, and Go was quite significantly faster, even with the not-so-great GC Go had in the ~1.6 era. (I suspect if I ran the same code now it would just work with no GC problems.) BEAM GC is more "hey, look at this neat trick!" than "better than anything around". I actually wouldn't consider it very good at all in modern terms. The Erlang community has a huge problem with thinking it's still 2003 and comparing Erlang to all the other competition in 2003, but unless you're still living in 2003, you need to be comparing to what's around in 2023.

h0l0cube 3y ago

This was in a top level comment on this post. It perfectly articulates what sets Erlang/BEAM/Elixir apart from other runtimes/languages. Essentially performant, fault-tolerant parallelism by design. https://www.youtube.com/watch?v=pO4_Wlq8JeI https://www.youtube.com/watch?v=pO4_Wlq8JeI If you need to break out into SIMD, you also have NX at your disposal. And Rustler/Zigler provide you an escape hatch to low-level languages, with the latter you can code in Zig inline https://github.com/elixir-nx https://github.com/elixir-nx https://docs.rs/rustler/latest/rustler/ https://docs.rs/rustler/latest/rustler/ https://hexdocs.pm/zigler/Zig.html https://hexdocs.pm/zigler/Zig.html

rramadass 3y ago

This top-level comment in this thread links to a excellent case-study which presents an architecture that may answer your question - https://news.ycombinator.com/item?id=37418015 https://news.ycombinator.com/item?id=37418015 For performance, drop down to C/C++ (carefully); 1) https://stackoverflow.com/questions/1811516/integrating-erlang-with-c https://stackoverflow.com/questions/1811516/integrating-erla... 2) https://news.ycombinator.com/item?id=14771658 https://news.ycombinator.com/item?id=14771658