Live data from Hacker News

Erlang: The coding language that finance forgot (2022)

efinancialcareers.com

61–70 of 155 posts

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

#61
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 companies were doing distributed systems even before Internet existed. Yes, finance has a lot of numerical work but it has a lot more data pipeline work. The reason for this is to move market data from one geographical location to another. To make profitable investments, finance companies need accurate market data from all over the world available and processed at its datacenters as quickly as possible. For this reason in the early 1980s finance companies were laying down their own cables and writing their own link layer protocols to move data from one location to another.

Now in the 21st century this has only got more intense. There is much more competition in this space. So finance companies that can make distributed systems right and reliable stand a good chance to the most money from the markets.

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

#62
post #2

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

Erlang and Haskell were never really the mainstream so not much changed for them, but Perl was "the language" at one point in time. It was everywhere, and now it's basically in the same box as Cobol - people who use it are 99% maintaining some old script. Very few young people choose to learn it nowadays, and the development got super slow due to the lack of developers. Perl 7 sounded great on paper, but I doubt it will get released anytime soon. So if not dead yet, Perl is definitely dying a slow death...

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

#63
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…

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.

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

#64

I really love Elixir (and somewhat Erlang) and all the mental models and how developing in the ecosystem feels like, especially with phoenix/liveview. Having said that, nowadays anything that can't really run on AWS Lambda is a nonstarter in any company tech discussions, no matter how cool/productive it is. The operational benefits of serverless are simply too great especially when trying to scale up.

I've run plenty of things in AWS Lamba using Erlang FWIW.

https://github.com/alertlogic/erllambda

It is interesting in as much as the lambda functions stay hot for a period of time.

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

#65

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…

> As soon as it has established the principles, as soon as it proved them feasible in practice, it has made itself redundant. The lessons we learned from Erlang were larger than Erlang I made a blog post around this very idea, that new languages never get the adoption that they need, because existing languages simply incorporate the best ideas from the new languages. At which point, why will anyone change the the new…

Those languages tend to die relatively quickly (zoomed out on a timescale, obviously), languages like CoffeeScript. When it first appeared, it was a god-send, but the good ideas were integrated into the core language, and itself went on to "die".

But then you have languages that have features that you cannot replicate to other languages. You might be able to add arrow functions from CoffeeScript to JavaScript, but you won't be able to tack on homoiconicity from lisps (and macros) to JavaScript, because it simply won't match with how JavaScript is written.

I guess my own conclusion is that languages that don't really invent much can be useful in the short term (like TypeScript), they go on to die when best ideas are integrated, but languages that are really inventive (like lisp-derivatives) end up on a different branch where ideas simply cannot be borrowed to other languages, so they stay around for the long haul.

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

#66
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…

> 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.

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

#67

Earlier quoted context omitted.

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

We should not have to live like this.

No one has to, there are 1000s of alternatives but some people chose to. Don't ask me why.

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

#68
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…

Sounds like a good old foldl may or may not have brightened up your day (with the "functional style" you mentioned) e.g.

  Pipeline = fun(Functions, Initial) ->
    lists:foldl(
      fun(Function, Acc) ->
        Function(Acc)
      end,
      Initial,
      Functions
    ),
  Initial = SomeFunc(),
  Pipeline = [Func0, Func1, Func2, Func3],
  Result = Pipeline(Pipeline, Initial).
At a certain point I grew to not mind the punctuations `; , .`

I often miss language itself given how verbose things are in elixir by comparison.

The language ecosystem is pretty good with LFE for the Lispers https://lfe.io/ and https://gleam.run/ for the OCaml inclinded.

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

#70

Earlier quoted context omitted.

> As soon as it has established the principles, as soon as it proved them feasible in practice, it has made itself redundant. The lessons we learned from Erlang were larger than Erlang I made a blog post around this very idea, that new languages never get the adoption that they need, because existing languages simply incorporate the best ideas from the new languages. At which point, why will anyone change the the new…

Those languages tend to die relatively quickly (zoomed out on a timescale, obviously), languages like CoffeeScript. When it first appeared, it was a god-send, but the good ideas were integrated into the core language, and itself went on to "die". But then you have languages that have features that you cannot replicate to other languages. You might be able to add arrow functions from CoffeeScript to JavaScript, but yo…

> But then you have languages that have features that you cannot replicate to other languages. You might be able to add arrow functions from CoffeeScript to JavaScript, but you won't be able to tack on homoiconicity from lisps (and macros) to JavaScript, because it simply won't match with how JavaScript is written.

Yeah, but I specified "best features" and "important features", not "all features".

Maybe homoiconicity simply isn't that important to developers?

For example, I can guarantee you that, right now in todays development climate, there is no team anywhere that is going to allow code which has Lisp-like self-modifiying ASTs to pass code review[1].

So why would Javascript, C#, Java, etc developers bother to a) request those features, and b) implement those requests? They aren't going to use the feature anyway, no matter how powerful.

[1] Except those places who already use Lisp, because they presumably already understand it, and those teams are tiny.

Post reply on HN