[erlang-questions] Is Erlang ideal for a global exchange?

[Garrett Smith]

On Mon, Jan 5, 2015 at 10:28 AM, xu xiut <xiut.xu@REDACTED> wrote:
> I am looking at using Erlang for an exchange. If I'm lucky, my transaction
> volume will be 100 - 150k day or about 4000 transactions/hour, about 1.5/sec
> At this rate, maybe Erlang wouldn't be necessary, however, would it be the
> case that Erlang provides better semantics surrounding failure compared to
> other languages and their ecosystems, and so, even then it would be a great
> tool choice?
>
> Is Erlang ideal for scaling out such an exchange? I wonder what is the
> minimum number of trades a second that would be difficult for erlang to
> process. I realize it's difficult to answer given the trade execution path
> isn't described, but it's the first question that comes to mind when I
> started thinking about the language of choice.
>
> Any thoughts or suggestions are welcomed, and thank you for letting me share
> this here!

>From my point of view, Erlang is *the* platform to use for iterative
and experimental development of back-end/server-side applications. If
you know *precisely* what you need to build and you're fairly certain
that its scope won't change over time, other languages could give you
some advantages, especially in terms of latency and throughout - and
even concurrency, provided again you know *exactly* what you're
building ahead of time and how they'll perform in production, over
time.

It's hard to know all this. Maybe if this is the fifth exchange you've
built of this exact type.

The reason Erlang is great when you don't have god knowledge about
what you're building ahead of time is that it's "process oriented".
You write code that runs sequentially in separate fully isolated
processes (one can't corrupt another). This makes your application a
system of small, independent threads of logic. Each process can fail
(and likely will given enough time) and your system of a whole will
keep running.

The result is that you can move fast with experiments, new code,
changes, etc. and not fubar your entire app. Ask around and you'll
hear from others that this is a material savings in time. You go
faster. You tend to write code that evolves more gracefully with more
isolated effects. You also tend not to run into the tangled,
impossible-to-truly-fix mess that is multi-threaded code at high
levels of concurrency.

If you've ever worked with (or written) code that just stops working
at some level of scale because of threading issues and concluded,
"OMG, this code will never actually work" you will be happy with
Erlang. It's very hard to get into that situation with Erlang. You
just don't have the length of rope needed.

Apart from my touchy-feely reply here, I know a number of trading
companies that are using Erlang to build exchanges and are very happy.

Erlang is more politically risky than technically risky. It you have
some autonomy in making that decision, I'd recommend writing a small
kernel of an app in Erlang that does something you think is
interesting (related to your problem) and get a feel for things. If
you need any specific help about where to start, approach, etc. this
is the right place to ask. The more specific you are in your problem
definition, the easier it will be to help :)

Garrett