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

131–140 of 155 posts

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

#131

Post by EdwardDiego »

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…

Porting Clojure and Scala to Java can also have performance advantages, but yeah, Java was an industrial language before Golang made it cool.

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

#132

Post by heywherelogingo »

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…

But with none of the elegance of Erlang/Beam.

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

#133

Post by adenozine »

vineyardmike wrote: post #129
adenozine wrote: post #84

Earlier quoted context omitted.

Have you seen gleam.run? It’s pretty neat. I preferred the alpha syntax, which was ML-inspired, but it’s decent in its current incarnation. I’ve always though the beam was really nice for building programming languages, and clearly that is true, as there are now more than a dozen targeting it.

Thank you for this! I love elixir and Erlang but I hate elixir’s syntax, so Gleam looks really cool! Are you aware of other beam-targeting languages?

Have I got a link for you!

https://github.com/llaisdy/beam_languages

See you down the rabbit hole!

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

#134

Post by qohen »

jjtheblunt wrote: post #126
djtango wrote: post #89

Earlier quoted context omitted.

Wasn't WeChat built in Erlang as well?

I think WhatsApp was Elixir

I think WhatsApp was Elixir

Erlang, actually; and they're still using it -- here's a paper-abstract[0] from Sept.2022 (and video of a talk[1]) about their open-source "EqWAlizer" tool[2] for statically-typing Erlang (as-is).

(EqWAlizer was discussed on an Erlang-related podcast[3], including its relationship to Dialyzer -- the original Erlang type-checking tool -- and it was briefly discussed on HN[4]).

[0] https://dl.acm.org/doi/10.1145/3546186.3552537

[1] https://www.youtube.com/watch?v=do9f2FKsKxM

[2] https://github.com/WhatsApp/eqwalizer

[3] https://www.beamrad.io/35

[4] https://news.ycombinator.com/item?id=32330284

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

#135

Post by qohen »

eggy wrote: post #106
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,…

Given your love for Lisp, and your knowledge of Erlang, perhaps Robert Virding's Lisp Flavored Erlang (LFE) might be of interest?

http://lfe.io -- among other things, the site has tutorials and some edits of Lisp books (e.g. SICP) rewritten to use LFE.

(And, from what I've heard, LFE is being used in financial apps, though perhaps more along the lines of expert-systems than regular financial apps? (Sadly, my knowledge is at best second-hand)).

P.S. Nice to finally run into someone who has actually used Wings3D -- it gets brought up as an example of a significant Erlang project, and I know there's a community of people who were/are using it, but, since it's not a technically-oriented tool, even at Erlang conferences one is unlikely to run into Wings3D people.

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

#136

Post by qohen »

crymer11 wrote: post #92
rvirding wrote: post #87

Earlier quoted context omitted.

I think the thing to remember that it all started as an interpreter written in Prolog in which we could develop our ideas on what the real problem was and the right semantics of a system for solving them. As we went along our "language" evolved as well and became less and less Prolog and more functional as we removed much Prolog semantics, added functional "stuff" and developed the final syntax. We had along the way…

It’s really delightful that we’re able to get the thoughts of someone who was there and involved in the genesis of the language. Thank you for all the time you’ve taken to explain the “why” of Erlang! (For those unfamiliar, go check out “The Erlang Rationale” and some of rvirding’s posts elsewhere, e.g., on the thread at https://elixirforum.com/t/the-erlang-rationale-by-robert-vir... )

If you want more, from someone else who was there, check out Joe Armstrong's "History of Erlang" paper:

https://dl.acm.org/doi/abs/10.1145/1238844.1238850 -- canonical link and has a video of the related talk (streamable and downloadable).

(Sadly, without ACM membership, the paper itself is paywalled; there are copies of it online though, e.g. https://www.labouseur.com/courses/erlang/history-of-erlang-a... ).

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

#138

Post by adenozine »

amalgamated_inc wrote: post #120
adenozine wrote: post #116

Earlier quoted context omitted.

I’m not sure the word for it, but brackets only ever mean two things, to my knowledge. Hash or Block, in Ruby. I spent many years in perl, so I’m of the opinion visual indicators for datatypes are actually a good thing at the point of instantiation/composition. Not sure how to properly word it

Oh, are all the paren/bracket types interchangeable in Perl? I've never used Perl. Yea, each set of them ([], (), {}, ) has a very distinct meaning in Elixir.

Well in perl there’s a concept of sigils.

my @num = (1, 2, 3);

my $num = 25;

say $num[1];

So that last line prints 2, which is obvious by looking at it, but can be difficult in more complex code when you’re overloading names by the way the variable is accessed.

Everything in perl is a rabbit hole of details, as an aside.

Anyhow, I just appreciate that the symbols always mean the same thing. Takes a load off of my brain. Like a single character type annotation, kinda.

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

#139

Post by qohen »

Terretta wrote: post #96
djtango wrote: post #88

I heard on the grapevine once that Goldman Sachs have a proprietary distributed database built in Erlang. Can neither substantiate nor deny but did make me wonder about all the hidden proprietary tech out in the world...

> heard on the grapevine once that Goldman Sachs have a proprietary distributed database built in Erlang From the article, third paragraph: Goldman Sachs built its messaging system using RabbitMQ, which runs on Erlang, in 2018. Jonathan Skrzypek (who now works for Coinbase) was running the messaging engineering team at Goldman at the time. The system had to be fault-free because the messages it was transmitting could…

A comment to the posted-article, from "Frellus", who identifies as ex-Goldman, suggests RabbitMQ might not have been used so extensively:

Ex-Goldman person here. To the best of my knowledge, RabbitMQ was used in spots but not where reliability was critical. Instead the main message brokers were IBM MQ and TIBCO. RabbitMQ would certainly lose messages in the event of a crash, and I'm not sure it would have been used for the main message bus given the rate of events. Additionally, Erlang was used for SecDB queries quite heavily. This was the bread-and-butter of the firm (https://github.com/saleyn/secdb)

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

#140

Post by OkayPhysicist »

somekyle2 wrote: post #125
newswasboring wrote: post #107

Earlier quoted context omitted.

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.

I've been on teams responsible for components written in more niche, powerful languages by previous employees who were deep in that particular language community. The author was really smart, the code was good. It was a big headache. First off, different build setup, different runtime, couldn't use most of our standard libs, so it was an island. It being in a language most people didn't know well meant it mostly only…

I don't think "avoid otherwise-unused languages for secondary tools" is the same as "avoid less common languages for your main product". Every software developer at your company will likely work on your main product for a non-trivial amount of time. Any software developer who can't figure out a new language in a trivial amount of time isn't worth hiring. Thus, everyone you hire will eventually be competent in the language of your main product.

In contrast, for secondary products, there's a good chance most developers will never work on it at all, and of those who do a significant fraction will spend only a trivial amount of time. Adding the overhead of working in a new language to that balance is significant.

Therefore, the ideal is "Choose the best language for your main product, then write all supporting software either in that language, or a widely-used lingua franca like Python".

Post reply on HN