61–70 of 125 posts
Earlier quoted context omitted.
> 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.
Earlier quoted context omitted.
> 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". There's, as I see it, three different kinds of legacy: (1) code that has an inordinately costs to maintain and especially update to changing requirements because it lacks tests, documentation of existing business intent and/or design, or otherwise has lost institution…
To that end, cloud platforms like fly.io[0] provide first-class support for Erlang/Elixir and related frameworks. If the industry is converging on Erlang-like solutions, it makes sense that Erlang is a natural fit. [0]: https://fly.io/phoenix-files
https://youtu.be/rRbY3TMUcgQ 2013 and still totally relevant Outlaw Techno Psychobitch FTW
Earlier quoted context omitted.
It is very much that. The Erlang team have not been too proud to steal good ideas from Elixir. Elixir has been a good source of fresh thinking for the BEAM ecosystem which has helped both the Erlang and Elixir side.
I hope to think that it's just that the bar to make significant changes to Erlang is very high. Stability and backward compatibility over time is something worth valuing. For me, this is a property that makes Erlang a great ecosystem.
Turns out you can have stability and innovation!
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 :)
https://youtu.be/rRbY3TMUcgQ 2013 and still totally relevant Outlaw Techno Psychobitch FTW
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.
These are largely built on top of either a stream processing (in case of Flink) or some flavor of Actor model based on event sourcing for peristence.
What I'm getting at is that you'd build a serverless system on top of Elixir/Erlang/OTP and be served well by its mature actor model implementation and excellent distribution options. See https://eigr.io/ .
The cloud provided options are interesting for some experimental / tactical use cases but I don't yet trust their abstractions to not be leaky and they typically come with vendor lock-in trade offs.
> The JIT now works for 64-bit ARM processors. Does this mean mobile apps in Erlang is not far off ?
Could be repurposed for Android development. I don't see it happening soon. Binding to Erlang is pretty difficult, see https://github.com/joshnuss/elixir-ffi.
If it did happen it would be useful, just... take some time.
** Warning: Turns out this is a really bad idea, do not use! When the BEAM calls native functions it needs to know how many reductions should be used. Otherwise calling a long running function can break the scheduling completly, because with this approach a long running function is considered 1 reduction **
Is Elixir running on OTP 25?