Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Erlang/OTP 25.0 Release

erlang.org

Post reply on HN
Print view View original

41–50 of 125 posts

Re: Erlang/OTP 25.0 Release

#41

Post by numbsafari »

msbarnett wrote: post #40
haolez wrote: post #26

I've seen more than once recently an engineer saying that software solutions outside of the Serverless ecosystem (FaaS, DB, etc) is "the new legacy". And that cloud providers have solved all the pains that Erlang was supposed to address. What's your feeling on this? Elixir sounds very compelling to me, but I worry that I might be going in a direction that's not where the industry is going.

> What's your feeling on this? That anybody claiming serverless has "solved all the pain" is definitely trying to sell me something.

Anybody claiming that anything has "solved all the pain" is definitely selling you something after having bought a load of it themselves.

State is suffering, and life is stateful, even after you're long dead and garbage collected.

Re: Erlang/OTP 25.0 Release

#44

Post by kristjansson »

haolez wrote: post #26

I've seen more than once recently an engineer saying that software solutions outside of the Serverless ecosystem (FaaS, DB, etc) is "the new legacy". And that cloud providers have solved all the pains that Erlang was supposed to address. What's your feeling on this? Elixir sounds very compelling to me, but I worry that I might be going in a direction that's not where the industry is going.

One good business cycle in the XaaS spaces might disabuse those people of that notion. Even on more stable providers, the whateveraaS products are a good solution for some cases, but far from panacea.

Re: Erlang/OTP 25.0 Release

#45

Post by bo0tzz »

haolez wrote: post #28

I've seen more than once recently an engineer saying that software solutions outside of the Serverless ecosystem (FaaS, DB, etc) is "the new legacy". And that cloud providers have solved all the pains that Erlang was supposed to address. What's your feeling on this? Elixir sounds very compelling to me, but I worry that I might be going in a direction that's not where the industry is going.

> cloud providers have solved all the pains that Erlang was supposed to address.

Assuming this is talking about tools like Kubernetes, they operate on a different level. The OTP's failure tolerance model operates on a (relatively) very small scale inside your application, whereas Kube operates on a whole-application level. Rather than obsoleting OTP, Kubernetes actually complements it.

Re: Erlang/OTP 25.0 Release

#46

Post by haolez »

mattbaker wrote: post #39
haolez wrote: post #26

I've seen more than once recently an engineer saying that software solutions outside of the Serverless ecosystem (FaaS, DB, etc) is "the new legacy". And that cloud providers have solved all the pains that Erlang was supposed to address. What's your feeling on this? Elixir sounds very compelling to me, but I worry that I might be going in a direction that's not where the industry is going.

My thinking is Erlang’s been powering massive systems since the early 90s, I’m feeling pretty good about its longevity. Many of Elixir’s strengths are Erlang’s strengths. I wouldn’t hesitate to learn some Elixir if it’s interesting to you. It’s not as pervasive as other languages but it’s not niche either. Full disclosure, it’s been such a wild success for my team at New Relic the last 5 years that I’m very biased :)

Wow! I've just subscribed to New Relic for my company (I'm the CTO) and couldn't be happier. What a coincidence :)

Re: Erlang/OTP 25.0 Release

#47

Post by lvass »

lenkite wrote: post #43

> The JIT now works for 64-bit ARM processors. Does this mean mobile apps in Erlang is not far off ?

I don't see any serious attempt at UIs with erlang. I think erlang processes would provide a great foundation for UI components, but has it even been tried?

Re: Erlang/OTP 25.0 Release

#49

Post by mattbaker »

haolez wrote: post #46
mattbaker wrote: post #39

Earlier quoted context omitted.

My thinking is Erlang’s been powering massive systems since the early 90s, I’m feeling pretty good about its longevity. Many of Elixir’s strengths are Erlang’s strengths. I wouldn’t hesitate to learn some Elixir if it’s interesting to you. It’s not as pervasive as other languages but it’s not niche either. Full disclosure, it’s been such a wild success for my team at New Relic the last 5 years that I’m very biased :)

Wow! I've just subscribed to New Relic for my company (I'm the CTO) and couldn't be happier. What a coincidence :)

Well if you try out the GraphQL API its API gateway is Elixir! The fields themselves provide data from a multitude of services downstream, but the gateway unifies it and sits in front.

I hope you like product :)

Re: Erlang/OTP 25.0 Release

#50

Post by nickjj »

preciz wrote: post #38
haolez wrote: post #26

I've seen more than once recently an engineer saying that software solutions outside of the Serverless ecosystem (FaaS, DB, etc) is "the new legacy". And that cloud providers have solved all the pains that Erlang was supposed to address. What's your feeling on this? Elixir sounds very compelling to me, but I worry that I might be going in a direction that's not where the industry is going.

I'm not sure where the industry is going but the innovations around LiveView are really convincing (I'm using LiveView in my work). Some great innovating Elixir projects: Oban: https://getoban.pro/ Oban Demo: https://getoban.pro/oban Livebook: https://livebook.dev/

A lot of popular web frameworks have their take on how to arrive at the same goal which is to be able to create responsive feeling sites without writing a lot of JS and creating API backends.

Rails has Hotwire Turbo (which is technically back-end agnostic), Laravel has LiveWire, there's also HTMX which is a bit lower level and back-end agnostic. There's also Django Unicorn and Rails Stimulus Reflex.

All of these solutions let you return HTML back from your server and partially update areas of a page while writing no-to-little JS. They're all implemented differently but for a huge classification of web apps the implementation doesn't matter.

After jumping between Phoenix and Rails for quite some time (years), personally I find Hotwire Turbo's implementation and overall using it extremely intuitive, it "just works". It's been legit one of the best development experiences I've encountered. The best part about it is that it works with any back-end too, so you're not even limited to Rails. DHH and the Rails team never cease to amaze me in what they release to the world.

Post reply on HN