Erlang: The coding language that finance forgot (2022) • Hacker News Board

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

#41

Post by dzonga » Thu, Feb 02, 2023, 11:38 AM UTC

xmcqdpt2 wrote: post #40

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 don't think Rust is really suited to replace the million LOC java apps that are found everywhere in finance. (The C++ ones probably ought to be rewritten in Java also, IMO. Or C#.) The reason that such enormous software exists at banks is because the business rules are immensely complicated. All this code basically exists to deal with the complexity of the financial world, not the complexity of interacting with com…

would Golang have a role in finance ? pros and cons of java vs golang in finance besides java being widespread ?

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

#42

Post by codesnik » Thu, Feb 02, 2023, 11:44 AM UTC

loftsy wrote: post #38

I've written some Erlang and found the syntax awkward. One example of this is that variables can only be bound once. This means you end up writing: Val = SomeFunc() Val1 = Func2(Val) Val2 = Func3(Val1) Yes I know you can use the functional style to minimise having to do this but you still end up seeing this pattern in real code. Kubernetes has done a good job of replacing OTP. That said I think Erlang is still an int…

I personally don't find this binding once behaviour problematic in any way, but Elixir specifically addresses this (it creates another variable with the same name, though)

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

#43

Post by kaptainscarlet » Thu, Feb 02, 2023, 11:45 AM UTC

loftsy wrote: post #38

I've written some Erlang and found the syntax awkward. One example of this is that variables can only be bound once. This means you end up writing: Val = SomeFunc() Val1 = Func2(Val) Val2 = Func3(Val1) Yes I know you can use the functional style to minimise having to do this but you still end up seeing this pattern in real code. Kubernetes has done a good job of replacing OTP. That said I think Erlang is still an int…

Why do you need the extra variables when you can pass function expressions into other function calls?

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

#44

Post by codesnik » Thu, Feb 02, 2023, 11:48 AM UTC

haspok wrote: post #35

Maybe the title would have been better like this: "PROLOG: The coding language that finance forgot." Erlang (the language) is rooted in Prolog, and many of its best traits can be traced back to this fact. That everything is a pattern, and you can pattern match pretty much anything is rarely found in other languages, for example. Elixir made a mistake in my opinion when it went with a Ruby-like syntax. Also, there are…

backtracking isn't hard to implement, though. Depth-first search is more or less what it is. But erlang lost most of the prolog ancestry, backtracking isn't there, for example. BEAM has a lot of concurrency neatness though, hard to reimplement or even mimic in languages not specifically tailored for from ground up.

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

#45

Post by gjvc » Thu, Feb 02, 2023, 11:49 AM UTC

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…

Does "BEAM" mean anything / is an acronym?

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

#46

Post by loftsy » Thu, Feb 02, 2023, 11:50 AM UTC

kaptainscarlet wrote: post #43

loftsy wrote: post #38

I've written some Erlang and found the syntax awkward. One example of this is that variables can only be bound once. This means you end up writing: Val = SomeFunc() Val1 = Func2(Val) Val2 = Func3(Val1) Yes I know you can use the functional style to minimise having to do this but you still end up seeing this pattern in real code. Kubernetes has done a good job of replacing OTP. That said I think Erlang is still an int…

Why do you need the extra variables when you can pass function expressions into other function calls?

It just turns out you can't always do that in a real codebase. For example see here:

  https://github.com/apache/couchdb/blob/23efd8e5b1aa96ef01640fec03a5fedc945ba8b9/src/couch_mrview/src/couch_mrview_http.erl#L228

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

#47

Post by glenngillen » Thu, Feb 02, 2023, 12:04 PM UTC

gjvc wrote: post #45

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…

Does "BEAM" mean anything / is an acronym?

Originally “Bogdan's Erlang Abstract Machine”, but then the subsequent maintainer was named Björn so you could sub that in too.

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

#48

Post by sodapopcan » Thu, Feb 02, 2023, 12:14 PM UTC

glenngillen wrote: post #47

gjvc wrote: post #45

Earlier quoted context omitted.

Does "BEAM" mean anything / is an acronym?

Originally “Bogdan's Erlang Abstract Machine”, but then the subsequent maintainer was named Björn so you could sub that in too.

And the predecessor to BEAM was JAM (Joe’s) which is a bit of a shame we didn’t end up with that acronym… or not, I guess.

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

#49

Post by MrBuddyCasino » Thu, Feb 02, 2023, 12:15 PM UTC

bongobingo1 wrote: post #26

MrBuddyCasino wrote: post #15

Earlier quoted context omitted.

This has it backwards - lambda is only suitable for the cloud equivalent of shell scripts, anything more complex and it becomes an unmaintainable rats nest that cannot be debugged.

Just hook up Amazon™®© X™®©-Ray™®© into Amazon™®© Redshift™®© then use Amazon™®© Athena™®©! Simple!

We should not have to live like this.

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

#50

Post by brightball » Thu, Feb 02, 2023, 12:23 PM UTC

haspok wrote: post #35

Maybe the title would have been better like this: "PROLOG: The coding language that finance forgot." Erlang (the language) is rooted in Prolog, and many of its best traits can be traced back to this fact. That everything is a pattern, and you can pattern match pretty much anything is rarely found in other languages, for example. Elixir made a mistake in my opinion when it went with a Ruby-like syntax. Also, there are…

Elixirs syntax is only Ruby like in that it’s very readable IMO. Any similarity with Ruby stops there.