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

21–30 of 155 posts

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

#21

Post by mrkeen »

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…

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

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

#23

Post by ThimbleWeed »

anonyfox wrote: post #10

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 thought around 80% of big tech companies are still maintaining giant Java monoliths that are attached to a giant Oracle database that nobody understands. Because it was all written 20 years ago, and there's no money in completely changing the architecture.

I've never been able to use serverless at work. I've always wanted to, but it's too risky for most companies. In my experience, they prefer to stick to tried and tested methods that have an easily predictable budget.

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

#24

Post by mikl »

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 cores with no trouble at all, handles massive amounts of concurrent requests without breaking a sweat. The programming techniques it enables with projects like Phoenix LiveView are unique and powerful.

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

#25

Post by Joel_Mckay »

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.

OTP allows multiple versions in concurrent upgrades across a cluster.

Additionally: testing, performance profiling, and debugging are natively supported.

Recommend reading:

"Designing Elixir Systems with OTP: Write Highly Scalable, Self-Healing Software with Layers" ( James Edward Gray, II, Bruce A. Tate)

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

#26

Post by bongobingo1 »

MrBuddyCasino wrote: post #15
anonyfox wrote: post #10

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.

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!

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

#27

Post by KronisLV »

ThimbleWeed wrote: post #23
anonyfox wrote: post #10

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 thought around 80% of big tech companies are still maintaining giant Java monoliths that are attached to a giant Oracle database that nobody understands. Because it was all written 20 years ago, and there's no money in completely changing the architecture. I've never been able to use serverless at work. I've always wanted to, but it's too risky for most companies. In my experience, they prefer to stick to tried and…

> I thought around 80% of big tech companies are still maintaining giant Java monoliths that are attached to a giant Oracle database that nobody understands.

I may or may not know lots of people who even develop new systems that way. In part due to them not knowing better, in part due to it being an okay fit for the problem that they want to solve and in part because they haven't and won't be fired for picking what has historically been a "safe" option.

More people have probably gotten burnt in the process of developing microservices and failing at it, than have been by their monoliths rotting over time and failing to scale, unless it's in an org with a strong ops culture and the support to do microservices right (with all of the tooling, like service meshes, tracing, orchestration and so on).

I reckon that many out there have done nor microservices, nor serverless, nor have any interest to. They're just the silent majority: https://vadimkravcenko.com/shorts/the-silent-majority/

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

#28

Post by ramchip »

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…

> And this explains why Erlang hasn't conquered the world.

I suspect the reasons are less technical than marketing, timing, etc. It takes some experience to appreciate what it does - it's not an obvious sell like "get a webapp going in 30 min" can be for Ruby. Although Elixir/Phoenix are doing some amazing things to fix that :)

OS processes are a fine way to isolate concurrent processes if they're quite granular. It works less well when there's 10000 of them (e.g. websocket connections), and they want to share a DB connection pool, metrics, etc.

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

#29

Post by recuter »

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…

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://12factor.net/disposability

> None of the other programming languages seem to have learned much of anything from Erlang--and that's kind of sad.

Learn you some very basic devops and you can collect on those erlang-y benefits using whatever languages/tooling/paradigms you want. A lot of it is flat out built into and managed by ye cloud providers.

Infra people squint at something like Beam/OTP and see a "control plane".

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

#30

Post by recuter »

Joel_Mckay wrote: post #25
mrkeen wrote: post #21

Earlier quoted context omitted.

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

OTP allows multiple versions in concurrent upgrades across a cluster. Additionally: testing, performance profiling, and debugging are natively supported. Recommend reading: "Designing Elixir Systems with OTP: Write Highly Scalable, Self-Healing Software with Layers" ( James Edward Gray, II, Bruce A. Tate)

Fargate allows multiple versions in concurrent upgrades across a cluster.

Additionally: testing, performance profiling, and debugging are natively supported.

Recommend reading:

"Amazon CloudWatch Container Insights for Amazon EKS Fargate using AWS Distro for OpenTelemetry" (https://aws.amazon.com/blogs/containers/introducing-amazon-c...)

Post reply on HN