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

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

#71

Post by capableweb » Thu, Feb 02, 2023, 1:37 PM UTC

antonvs wrote: post #37

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’m a big fan of Rust, and am currently working on a major Rust project, but I don’t think it’s currently a viable replacement for most Java apps, nor is it really intended to be. If anything Go is closer to fitting that bill, if only because of its traditional garbage collection. Applications written in Java by definition aren’t too concerned with memory management, and Rust is objectively a step backwards for them.…

Although, "writing C++ in Rust with unsafe everywhere" does grant you the right to append "X written in Rust" when you finally do your Show HN, leading to a 26.7% increase in upvotes, so there is that.

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

#72

Post by worthless-trash » Thu, Feb 02, 2023, 1:41 PM UTC

okaleniuk wrote: post #4

qsort wrote: post #2

Who exactly claims Erlang is dead? The referenced article is SEO-infected garbage that also claims Haskell and Perl are dead.

Well, it's 21 century, nothing dies anymore but people. But you have to admit that it's not booming the way it deserves. I wrote in Erlang a decade ago and I thought that in ten years, surely, it will eat the world. Erlang got too many things right. However, as people from other domains started employing its principles, Erlang's value diminished. E. g., if we now write supervisors in Python that run servers, event ha…

Then you need 4 languages and each of them has slightly broken interactions. Hell is the code we write.

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

#73

Post by holsee » Thu, Feb 02, 2023, 1:43 PM UTC

codesnik wrote: post #42

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)

I wish they didn't tbh, it makes me sad.

Not allowing rebinding does provide a little bit of encouragement towards factoring things better, but I have seen manys a `X1` `X2` in my time :(

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

#74

Post by xmcqdpt2 » Thu, Feb 02, 2023, 1:50 PM UTC

dzonga wrote: post #41

xmcqdpt2 wrote: post #40

Earlier quoted context omitted.

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 ?

Yeah I mean in so far that Go is basically Java-like (GC-ed, statically typed, has interfaces, simple language) it could be used there too. Go targets very much the same kind of problem as Java. C# too.

I only have a passing knowledge of Go so I can't comment on it's advantages or disadvantages much, although one of the great strengths of Go (tooling) is also very much a strength of Java (at least in large companies where there will be dev env teams that set up the Java environment for you.)

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

#75

Post by davidjfelix » Thu, Feb 02, 2023, 1:51 PM 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…

> Kubernetes has done a good job of replacing OTP.

I feel like this statement alone demonstrates a wild misunderstanding of what OTP does and is. Kubernetes is at best a replacement for VM-level scheduling, but without a slew of additional functionality and application-level interaction with the kubernetes runtime, individual servers are basically running blind in a container, totally unable to do anything that OTP provides to gen_servers for free.

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

#76

Post by 4pkjai » Thu, Feb 02, 2023, 2:01 PM UTC

I wonder if rust will end up as a coding language finance forgets.

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

#77

Post by tempest_ » Thu, Feb 02, 2023, 2:01 PM UTC

capableweb wrote: post #63

TuringTest wrote: post #57

Earlier quoted context omitted.

What's the license for the BEAM runtime? I've found that Erland and Elixir are both Apache License, but I can't find out whether the bytecode they generate can be executed in a fully open source environment.

AFAIK, BEAM is developed within the erlang/otp, so the license is Apache License 2.0. Not sure why bytecode generated by a APLv2 project couldn't be executed in a fully open source environment.

I have no idea either but it has a whiff of Oracle to it.

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

#78

Post by sodapopcan » Thu, Feb 02, 2023, 2:09 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…

What's the mistake in going with a Ruby-like syntax? I don't necessarily disagree in terms of wider adoption (though I personally really really like the syntax) though the context is unclear around your statement.

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

#79

Post by stevan » Thu, Feb 02, 2023, 2:10 PM UTC

capableweb wrote: post #66

medo-bear wrote: post #9

Earlier quoted context omitted.

> 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 common lisp is in a league of its own when it comes to hot reloading and debugging

Question is if Common Lisp got the idea from Erlang, or vice-versa. Common Lisp first appeared in 1984 while Erlang appeared in 1986. If so, the original point of "None of the other programming languages seem to have learned much of anything from Erlang" might remain accurate.

In the 70s Ericsson programmed their telephone switches in a proprietary language called PLEX. It had hot code swapping, so when Joe Armstrong started working on Erlang to replace PLEX in the 80s this was a requirement. Dropping a few thousands of calls just to do an update simply wasn't an option.

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

#80

Post by mardifoufs » Thu, Feb 02, 2023, 2:15 PM UTC

oleks wrote: post #58

What does finance have to do with distributed systems? Finance is much more about mathematical modelling, which is an utter pain in a dynamically typed language with nothing but library support for state management.

Finance is a huge field. I'd say the need for mathematical modelling, in one form or another, is pretty universal no matter what you do in Finance. But there are also tons of other stuff you might need on top of that depending on what specific field of finance you work in. Distributed systems can provide the data that your model relies on, or even the platform where the model itself needs to run on.