Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Erlang: The coding language that finance forgot (2022)

efinancialcareers.com

Post reply on HN
Print view View original

101–110 of 155 posts

Re: Erlang: The coding language that finance forgot (2022)

#101

Post by toast0 »

aynyc wrote: post #81

Erlang isn't dying but not many people care for it in capital market. Looks at the traits of Erlang, it's designed for telecom environment which is almost opposite of capital market. 1. Fault tolerance is almost all hardware driven. Capital market participants spent billions of dollar building reliable private networks. 2. Distributed in trading doesn't mean what FAANG are doing. Trading systems for example usually r…

> 2. Distributed in trading doesn't mean what FAANG are doing. Trading systems for example usually run 2 hot-warm systems with real-time replication commits, that's about it. They don't run horizontally scaled systems because network time would kill their performance.

That's pretty close to Ericsson's use case for dist; they built it to run redundant computers in the same chassis for telephone switches. It just also happens to work fairly well at much larger cluster sizes too.

Re: Erlang: The coding language that finance forgot (2022)

#103

Post by toast0 »

bsder wrote: post #6
okaleniuk wrote: post #3

Erlang is designed to accommodate principles for building reliable systems in the presence of software errors, and in such capacity it is definitely a worthy instrument. It is one of the few concurrency oriented programming languages in the world. But as Joe Armstrong himself pointed out in his dissertation: "indeed concurrent programs can be written in languages which are not themselves concurrent". You can write co…

I strongly disagree that we learned much of anything. For example: hot upgrading. The fact that an Erlang process can tail call itself means that you can swap in a new process with the same signature at the tail call of the old process. Nobody else does this that I know of. I can go on further. The whole set of behaviors encoded by the OTP libraries is also something that nobody else seems to do. Erlang's bit syntax…

> For example: hot upgrading. The fact that an Erlang process can tail call itself means that you can swap in a new process with the same signature at the tail call of the old process. Nobody else does this that I know of.

You can do hot loading in C with dlopen and friends, but you've got to be a lot more intentional, and have the right shape of program. I did it once for a networking proxy type thing where Erlang was inconvenient (I'd need to make NIFs to get at the data and didn't want to deal with that), but I had state I didn't want to lose or serialize while making changes to the code. Of course, I then proceded to make only one or two changes. ;)

Edit: or you can do it in C the more exciting way, by updating your mmaped libraries on disk. That'd take a lot of intentional effort to not just crash, which is what tends to happen when you accidentally update instead of replace mmaped libraries. (There's a reason to use install instead of cp)

Re: Erlang: The coding language that finance forgot (2022)

#104

Post by toast0 »

recuter wrote: post #29
bsder wrote: post #6

Earlier quoted context omitted.

I strongly disagree that we learned much of anything. For example: hot upgrading. The fact that an Erlang process can tail call itself means that you can swap in a new process with the same signature at the tail call of the old process. Nobody else does this that I know of. I can go on further. The whole set of behaviors encoded by the OTP libraries is also something that nobody else seems to do. Erlang's bit syntax…

Hot upgrading is not a good example. There are infinity ways to do accomplish the same in other ecosystems, a very common example: Upgrade nginx live and without dropping any connections. Anyhow, instead of bolting that on to your project reinventing those patterns for the millionth time you can just adhere to ̶the c̶o̶n̶j̶o̶i̶n̶e̶d̶ ̶t̶r̶i̶a̶n̶g̶l̶e̶s̶ ̶o̶f̶ ̶s̶u̶c̶c̶e̶s̶s̶ the tenants of 12 factor apps: https://12f…

> Upgrade nginx live and without dropping any connections.

You can do that, but you won't get the new behavior on the existing connections, only for new connections. Some http servers will also curtail keep-alive requests while draining the old server processes, so you still get to pay the cost of reestablishing long lived connections, if your use case includes those.

Re: Erlang: The coding language that finance forgot (2022)

#105

Post by jjnoakes »

MattPalmer1086 wrote: post #53
jjallen wrote: post #32

Earlier quoted context omitted.

Do you think Rust will replace these over time? What are the blockers for this? Is Rust perceived as a "better" language by those in your profession but of cours e you can't rewrite everything every 5-10 years? Would finance apps be written in Rust today if all of the C++/Java applications weren't already written?

I personally like Rust a lot, but it isn't on our radar at all. Nobody has even mentioned it. Java and C++ are fine for what we do. What advantages (other than memory safety, which Java has too) do you see in Rust?

Not OP and not choosing a side in this thread on the RIIR topic, but I would like to address why I like Rust over those other language - in addition to memory safety, I really like the stronger types (specifically sum types), the move semantics, and the data-race safety.

Re: Erlang: The coding language that finance forgot (2022)

#106

Post by eggy »

college_physics wrote: post #82

Finance means different things to different people. Are we talking about trading "finance" (including high frequency trading), investment banking "spreadsheet" finance, consumer or corporate "database" finance or maybe even (the horror, the horror) "defi" cryptofinance? What is true is that finance in almost all its guises is a world apart in terms of information technology. Closed and proprietary, ultra expensive an…

The one big use case was RabbitMQ in a messaging app, not HFT. I doubt Elixir even with Nx can compete with low-level HFT code. Python DL/ML code libraries are just wrappers around C too. Maybe if BeamAsm and Nx are used Elixir could be used for more numerical or not just distributed applications.

I've programmed in Python and Julia, and when I worked at an engineering (mechanical, entertainment engineering) company, Julia was great for its similarity to Matlab. I am a self-taught engineer, so I did not get pulled into Matlab in college.

Personally, I took to Erlang, so I could write plugins for Wings3D back in the early 2000s, but I never stuck with Erlang, or Wings3D (Blender3D was my choice and I even contributed to have it go opensource way back when). I like Erlang's syntax better for some reason, although Elixir's is beautiful too. I was not a Ruby programmer, and I had delved into Haskell and Prolog, so I think Erlang made more sense to me. I think Elixir has a lot more momentum behind it than Erlang, but at the root it's Erlang, so I think I'll stick with Erlang for BEAM apps. My favorite language is April[1] (APL in Lisp), and given my love of J, would be a better fit for any finance apps I might write. I am trying to convert some of the Lisp code in this book, "Professional Automated Trading: Theory and Practice" to April.

Maybe I'll write some equivalent Elixir code to compare.

[1] https://github.com/phantomics/april

Re: Erlang: The coding language that finance forgot (2022)

#107

Post by newswasboring »

weatherlight wrote: post #97
jonhohle wrote: post #91

Earlier quoted context omitted.

Funny anecdote about one of the FAANGs: before the idea of service meshes and Consul and Envoy a similar idea was being rolled out to transparently proxy, encrypt, and authenticate traffic between services. The initial implementation was on erlang and didn’t cause any operational issues for our team, from what I remember. The project was moved to another team who decided for version 2 to rewrite in Java (high made se…

Everyone always talks/jokes about, "Rewrite it in Rust," think about all the business applications over the years that had been rewritten to Java, just because. Usually under the guise of, "Kids coming out of college will have an easier time wrapping their heads around Java," than some other lang. In my time as an engineer, I've seen quite a few Scala and Clojure apps, get rewritten in this manner. This is all antido…

I sometimes wonder if this logic makes sense. I'm currently leading a fully inexperienced team where my main challenge isn't delivering products but qualified people. I have to make them learn so many company specific and codebase specific things that feels like learning a new language would be a least of it. This is of course colored by my language learning loving lens, so I can't be sure about this.

Re: Erlang: The coding language that finance forgot (2022)

#108

Post by toast0 »

mrkeen wrote: post #21
bsder wrote: post #6

Earlier quoted context omitted.

I strongly disagree that we learned much of anything. For example: hot upgrading. The fact that an Erlang process can tail call itself means that you can swap in a new process with the same signature at the tail call of the old process. Nobody else does this that I know of. I can go on further. The whole set of behaviors encoded by the OTP libraries is also something that nobody else seems to do. Erlang's bit syntax…

> swap in a new process Very technologically cool, but I'd much rather inject the new functionality into the source code. From there it can it make its way through the unit tests, integration tests, deployment, health/readiness checks, and if all that passes then I'll allow it to be called.

> Very technologically cool, but I'd much rather inject the new functionality into the source code. From there it can it make its way through the unit tests, integration tests, deployment, health/readiness checks, and if all that passes then I'll allow it to be called.

Generally, you do make the changes in source code, compile it, do all your pre-flight checks, and then hotload it. Honestly, sometimes the pre-flight check is just 'does it compile', but that's philisophical; you can put whatever process in place you want. But from my experience, it's much nicer to upgrade in place than start new, move traffic, drain old (not always in exactly that order). Sometimes, it's not realistic to avoid starting new and moving traffic, but it's nice when you can.

Most people aren't patching the VM bytecode by hand (to my knowledge).

Re: Erlang: The coding language that finance forgot (2022)

#109

Post by freedomben »

innocentoldguy wrote: post #94
aynyc wrote: post #81

Erlang isn't dying but not many people care for it in capital market. Looks at the traits of Erlang, it's designed for telecom environment which is almost opposite of capital market. 1. Fault tolerance is almost all hardware driven. Capital market participants spent billions of dollar building reliable private networks. 2. Distributed in trading doesn't mean what FAANG are doing. Trading systems for example usually r…

The company I currently work for switched from Java to Elixir/Erlang because developer productivity was so much higher. Being able to turn around features and fixes in a fraction of the time has been quite valuable for us.

I would love to hear more about this if you're willing! Java shops (In my experience) have been the most unlikely to switch shops there are. Some questions:

What pain were you feeling?

Who came up with the idea/proposal to switch and how did they deliver it?

Was it hard to get people on board?

How difficult was it for people to learn Elixir?

Did people take to it quickly and/or were there people who had a hard time?

How long did the transition take to complete?

Re: Erlang: The coding language that finance forgot (2022)

#110

Post by amalgamated_inc »

mikl wrote: post #24

The reason Erlang (and Elixir) are interesting are not the languages themselves (although Elixir is a very nice language in my opinion), but the runtime behind them, BEAM. The BEAM is the brainchild of the excellent engineers at Ericsson, the product of decades of R&D into building performant, scalable and reliable software for their telephony products. It scales like a dream, runs your application on all available c…

While the BEAM is the real magic, the languages (Erlang and later Elixir) are designed specifically to enable that. You can't just decouple the two.
Post reply on HN