[haolez]

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.

[brightball]

IMO people represent what they know.

People also overestimate what “the new” is, constantly. Otherwise, PHP would be dead by now rather than flourishing.

Serverless is essentially PHP in CGI mode, with a lot of marketing behind it. There are certainly places where it’s beneficial.

Servers and databases are not going away anytime soon. They are simply too effective for what they do.

The “everything is legacy crowd” hasn’t been correct about almost anything in my lifetime. Mainframes are still going strong. SQL databases are better than ever and the NoSQL crowd has largely died out.

90% of the cloud ecosystems of today are just doing what Java app servers were doing in the late 90s.

Erlang and the BEAM offer a set of trade offs that happen to be ideal for a lot of server based use cases to make hard things really simple. Probably not going to take over the world but if it fits what you do you probably won’t want to go back.

[deckard1]

> NoSQL crowd has largely died out.

yeah, that was rather curious. Similar to how XML died out. Not with a bang but with a whimper. Not that NoSQL or XML are completely gone today, just like PHP. But suddenly one day you recognize these topics are no longer appearing on HN or elsewhere. Then you realize you're getting old and... oh my god... we're actually stuck working in a fashion industry and nothing matters, life is meaningless, and all this is dumb dumb dumb.

When HN and other techies find a new hammer they end up beating that hammer against every problem they see. Right now it's SQLite. I love SQLite. But man. Can we quit talking about it for one fucking day already? This is probably how it felt to be an Erlang fan when Facebook bought WhatsApp. I remember the decades of Joe Armstrong talking about Erlang on Usenet and no one caring. It's just cargo cult with no thought behind it. WhatsApp was successful using X, so if we use X we must be successful. People have this perception that Python is new and modern despite being, relatively speaking, the same age as Perl. Erlang was cool long before WhatsApp. It's really quite old tech.

[rawoke083600]

>Then you realize you're getting old and... oh my god... we're actually stuck working in a fashion industry and nothing matters, life is meaningless, and all this is dumb dumb dumb

Yup I know what you mean ! There is no zen. As I mentioned some time ago, the 'final zen state' is coding on a mountain top for yourself in a LISP with Emacs on an ultra book charged by happy sun rays :D - only somewhat joking here...

[ungamedplayer]

If its any consolation, i pretty much do the same, on a T490s in the desert, its actually pretty neat.

[rawoke083600]

:) It is the way.

[pjmlp]

Between XML, JSON, YAML and TOML, I would rather my configuration files served in XML, with schema validation and graphical IDE tooling, thank you very much. :)

[innocentoldguy]

I personally prefer JSON to XML. I've seen XML abused in some pretty terrible ways. For example, I worked at an education start-up several years ago and the education company Pearson delivered bubble test questions to us in XML where half of the questions' text were in tag attributes and the other half was in the body of the tag. JSON (and YAML/TOML) make it a lot harder to do stupid things like that. They're also easier to parse, in my opinion.

[justbaker]

> SQL databases are better than ever and the NoSQL crowd has largely died out

Especially with json types in Postgres for example. I can store data that’s suboptimal to use traditional databases to access (think complicated and varying form data) but retrieve it and reference it from table relationships traditionally.

[mattbaker]

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 :)

[haolez]

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

[mattbaker]

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 :)

[dmix]

New Relic is using Elixir?

[mattbaker]

Yep, it’s by no means the most common stack but it does power a few critical services. We’re actually hiring for an elixir role right now (non-senior/mid-career, prior elixir not required).

[Errrrrt]

Hmmm I looked for this position and couldn't find it. Could you link it? I would like to see if I can apply

[mattbaker]

Yep: https://jobs.jobvite.com/newrelic/job/oTbyjfwF

[dragonwriter]

> 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 institutional knowledge needed for nontrivial work, relying on the foggy memories of a high priesthood increasingly, over time, working through ritual without understanding, (2) software with deep and fundamental dependencies on platforms or external components that are no longer supported or no longer available, and (3) software which doesn't meet the current arbitrary tech platform decisions of the organization using it, but which has no fundamental problem preventing maintenance or use.

In lots of places, software that isn't adapted to a particular serverless architecture that the org has adopted is now the third type of legacy.

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

They haven't, though for some use cases, the parts of the stack Erlang would be most useful for implementing are the parts you are likely to just get from a cloud vendor (that's not true of all use cases, though.)

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

Elixir is probably not the best bet if your concern is to direct the most focussed possible effort learning the things that are most likely to dominate the largest share ofnthr general software dev marketplace in the near future.

[isaacimagine]

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

[melony]

Problem is that outside of Fly, somebody still has to do the system admin. Erlang (used in an web application context) won't manage itself no matter how well designed it is. Stuff like serverless is meant to completely outsource DevOps.

[ricketycricket]

I mean, `mix phx.gen.release --docker` generates a nice dockerfile for packaging up a release (which is all Fly does). At that point it's essentially no different than any other containerized application. I've shipped Elixir apps to Heroku, Fly, Render, and Azure with basically no devops on my part.

[mrdoops]

Serverless systems in almost every implementation are still stateless or limited stateful-serverless (the best examples are probably Microsoft's Durable Functions or Flink's Stateful Functions - there's also solid attempts by the Akka folks).

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.

[Kototama]

This is one of the best answer.

Also:

- the supervisor system in Erlang/Elixir is relatively complex. It goes much beyond the "restart my service" when it crashes but allow to restart some processes, without restarting the service, and in a specific order to keep the system coherent.

- local and remote calls behave the same in Erlang/Elixir, allowing to start with a monorepo having different Erlang "apps" than run on the same node, but then running the different apps on different nodes in the future, once the application, scales. This can be done very little changes to the application.

[toast0]

> - local and remote calls behave the same in Erlang/Elixir, allowing to start with a monorepo having different Erlang "apps" than run on the same node, but then running the different apps on different nodes in the future, once the application, scales. This can be done very little changes to the application.

I wouldn't really say they behave the same. They have the same interface, so it doesn't take much to send to a remote node vs the local node, but there are a lot of details in the behavior that are clearly different, as is the nature of the beast. With a local process, if you monitor it, and receive a kill signal, you know it's dead; with a remote process, you may get a process died signal or a connection died signal; if the connection died you can't know if the remote process is dead or alive. That's new behavior and can be tricky sometimes.

[Kototama]

Ok good point. When using GenServers thought, which is most of the cases, it is mostly transparent.

[haolez]

> - local and remote calls behave the same in Erlang/Elixir, allowing to start with a monorepo having different Erlang "apps" than run on the same node, but then running the different apps on different nodes in the future, once the application, scales. This can be done very little changes to the application.

This sounds very appealing to my context.

[preciz]

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/

[nickjj]

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.

[preciz]

I also worked with Rails before and I'm happy to see their progress, I however wouldn't go back to work with it if I can choose, for me Phoenix and LiveView doesn't feel like magic or too much convention unlike Rails does unfortunately.

[msbarnett]

> What's your feeling on this?

That anybody claiming serverless has "solved all the pain" is definitely trying to sell me something.

[numbsafari]

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.

[mattbaker]

I laughed and cried at that last sentence. 10/10

[tomjakubowski]

It helps to set up a supervision tree so one thing crashing and burning won't bring it all down.

[kemiller]

I'd actually characterize it the other way around: Elixir and Beam give you most of the benefits of serverless with better portability and lower costs.

Also, meta: don't worry too much about where people tell you the industry is heading. 1) They don't actually know, 2) it's much more conservative out there than you might think. Even when new paradigms do gain traction, they pretty much always augment rather than replace, for a good long while at least.

[yumaikas]

If you're wanting to use Elixir, it's not going to be nearly as mainstream as, say, Node, but fly.io has support for Elixir apps (to speak of cloud), and I think there's some cool stuff going on in Elixir myself.

Of other note is that Erlang seems to enable folks that use it to punch above their weight class when it comes to running services internally and such.

Serverless is far from the only valid way to run things these days.

[jlouis]

While Serverless does address some of the points which were the design goals of Erlang, it doesn't address them all. In no particular order:

Hardware interaction is more or less non-existent in the world of Serverless.

Timing/Latency is not really controllable. It's at the whim of your provider.

FaaS doesn't support very large systems well. It's far more about scaling down than up.

Erlang is functional for a reason: it minimizes faults. Quality follows.

Complex feature interaction is limited in the stateless serverless world.

Cloud providers tend to solve for a different set of problems, which is fine. But I'm going to claim that many of the things Erlang was designed to solve runs dual to the problems in the cloud space.

[rozap]

I will bet real money Erlang and elixir will be around and doing just fine in a decade. I would not make that same bet about any cloud services provider.

[jimbob45]

Serverless works super well for getting off the ground but the goal is to grow big enough that it’s no longer the best option, no?

Just because the industry is willing to waste money on tech they’ve outgrown doesn’t mean you need to.

[_huayra_]

One current advantage: FaaS is sold below cost by every cloud provider at the moment, so if you can design your app to take advantage of it, you'll save $$$.

Don't know how that'll hold up into the very long term though...

[etaioinshrdlu]

I highly doubt they are sold below cost - when I've checked, the costs are actually higher than a regular VM instance for the equivalent amount of compute.

[kristjansson]

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.

[pjmlp]

Serverless are rebranded CGI scripts for a new generation that buys into whatever developer advocates want to sell them this week.