Hacker News Reader

Comment by cpursley | Hacker News Reader

I feel like 2/3s of posts on here are people spending tremendous amounts of effort recreating OTP (things Erlang/Elixir already does natively).

View on HN

I could be wrong but I don’t think OTP natively implements a load shedding strategy or concurrency controls or request hedging. You would implement a supervisor to do so if you don’t want to overload an external system like a DB or microservice (e.g https://github.com/fishcakez/sbroker).

Erlang/Elixir is an especially good language runtime for the type of problems you bring up (backpressure, etc)

Do you see the circular argument you are making

“these libraries are just what otp does natively”.

“Here are some things in this library that otp doesn’t do natively.”

“You could build a erlang library for that”

Having enthusiasm for erlang/otp is fine. It’s a pretty great stack. But there are lots of reasonable reasons not to use it and lots of distributed systems knowledge we’ve picked up since it was designed. Some of which are encoded in libraries like these.

> recreating OTP

Imitation is the sincerest form of flattery that mediocrity can pay to greatness...

Im guessing that pretty much sums up how you feel. "Why isn't my tool more popular" is really the subtext of your question here.

A lot of GO devs came from java,ruby,python,php ... For 3 out of 4 of those static typing is an upgrade. For all of them compile to executable is a massive change and a good one. We're not moving code and runtime to a box to execute...

Its a breath of fresh air that if I need a tool I can quickly write it in go, compile it, throw it on to the server its needed on and be done with it. I dont have to instal vm/runtime/server to make that code work.

Dont think that matters? I have a Rpi camera server that is just a go binary running... All I did was wget it and turn it into a service.

Furthermore every one who is coming from those languages has seen upgrades go all sorts of directions.. php 4-5-6-7 were somewhat smooth but evolved the language, there is a way. Python 2 v 3 you can evolve a language and there is a BAD way. Python venvs are a pain... and ruby gems have their issues... Go's no breaking promise and packaging choices speaks to all the things that these devs lived through.

And the laments of "go lacks" or "too much boiler plate" are features not defects. Write dead simple, easy to read code. Deal with your errors on the spot in a pattern that everyone will recognize. Im not sure that I qualify Erlang/Elixir easy to read or "simple" (effective I will give it).

So yes, people are stealing OTP... take the compliment and go out and invent something else cool that we can "borrow".

But what about go slices?

https://news.ycombinator.com/item?id=39477821

I write a lot of GO? Do you think I'm unaware of its warts? Do you think I'm not sick of typing err != nil? Do you think I dont sometimes cut corners and NOT deal with that error on the spot or just _ it cause it's a throw away chunk of code?

Pick a language, any one, and there's probably a post by someone complaining about a bad design decision or a wart on its fuzzy ass... Nothing is perfect.

Yes go has flaws... I find that first class, high speed, testing makes the fact that I screw these things up all the time moot. Test, fix move on to the next project.

And for those who come from .NET it's a big downgrade :)

There's a usability lesson in there. If it works so well but most people can't figure it out, then it doesn't help them.

Exactly, this is why I prefer OTP over k8s.

And it's why people prefer damn near anything over Erlang. I have been knee deep in RabbitMQ code trying to solve a massive performance issue in a production system and all I was able to learn from that experience is that I hate Erlang. Trying to learn something in anger isn't a great way to do things but using a language that looks nothing like most languages in common use is a recipe for niche status and a reason for people who need the things they run to be understandable to choose a different tool.

Similarly, if there is a god-sent feature in your application, but the end-user don't know how to use it, or find it, there isn't god-sent feature.

I suspect it's easier to apply a pattern to a language than it is to learn and introduce a new language to use a pattern.

Erlang has been around since the 80s and OTP the early 90s. Elixir for a decade.

And yet people are reinventing parts of OTP in other languages and through tooling and infrastructure (e.g. Kubernetes). What does that tell you?

It tells us that people aren’t aware of OTP.

Or that people find OTP/Erlang/Elixir hard to use.

OTP has either a usability issue or a marketing issue

It doesn’t even necessarily say that. People may reasonably evaluate OTP/Erlang/Elixir[/other BEAM languages] and find them appealing, but elect to use another stack because it appeals more for reasons beyond OTP/etc’s appeal. I made that choice once, but I wouldn’t hesitate to consider OTP/etc again the next time I’m working on a problem they solve well.

Thanks for proving the whole point of this thread (No snark meant). People are indeed recreating parts of OTP in other languages because there are all kinds of reasons to pick a different language than Erlang/Elixer and still want some of the advantages of those languages

As someone who adhores OTP in the abstract but uses mostly Go, I can tell you why I don't use it.

Static typing: I've worked for years with dynamically typed languages and won't go back. Dynamic typing was a big mistake that have wasted years of developer time. Dialyzer isn't an option.

Syntax: Erlang's syntax is not great. Enough said. I think Elixir isn't better, or at least doesn't offer enough of a value proposition over straight Erlang.

Native compilation: Erlang works well for control systems. It's absolutely subpar for anything requiring compute performance or I/O. This means you may find yourself in a sticky position if your backend app has hotspots needing very low-latency, high-performant logic. You may have to write bits in C or some other natively compiled language.

Friction: Erlang is hardly used anywhere. It is sufficiently weird (functional, Prolog syntax, immutable, the process model, antique tooling, not to mention OTP itself) that it's not just something most developers are going to pick up in a day. Forcing Erlang on a team not consisting of a monoculture of Erlang developers is a huge ask in any company. It's hard to hire for. You can't just reassign a random "full stack" developer within a company to a team that uses Erlang, if all they know is JavaScript/TypeScript or Go for that matter.

I think fans of Erlang have to realize that no matter how much they post comments like yours, it's just not going to take off. Sometimes superior tech just doesn't pan out (Amiga, BeOS, QNX), but we move on.

I am optimistic about Gleam, though. A much better language that I would actually want to use, and there's interop with Erlang/OTP, which is a great way to bootstrap a language.

> Native compilation: Erlang works well for control systems. It's absolutely subpar for anything requiring compute performance or I/O. This means you may find yourself in a sticky position if your backend app has hotspots needing very low-latency, high-performant logic. You may have to write bits in C or some other natively compiled language.

This is mostly accurate, but I think Erlang is a good fit for network I/O, especially network I/O with lots of concurrent clients.

> Friction: Erlang is hardly used anywhere. It is sufficiently weird (functional, Prolog syntax, immutable, the process model, antique tooling, not to mention OTP itself) that it's not just something most developers are going to pick up in a day.

At my Erlang job, almost nobody we hired had Erlang experience. It certainly took longer than a day, but IIRC, my first big Erlang server stuff deployed (and mostly worked) a month in, and I was focusing on a PHP service. I probably did some minor stuff earlier, but I no longer have changelogs to reference.

Yeah, some of the OTP philosophy takes a while to understand. As for antique tooling, we just used Make, and that's what I continue to use for my Erlang projects, and well Make is Make... once you learn it, it works. Figuring out how to get dist running and pop debug shells when and where you need them is work, but if you're dropped into a place that already has that, you don't need to figure it out yourself, either.

Kuberentes does most of what OTP does but better and completely language agnostic.

Lol have you ever actually used k8s?

I have, and I agree with the sentiment that k8s does it better.

Okay then, do you have experience with deploying and operating distributed Erlang?

I do, at somewhat medium scale. My experience was similar to other posters here, where we ran into production issues that were incredibly difficult to pin down.

If you'd like, you can attribute that to lack of Erlang experience or skill on my part. But in practice, we instead replaced that system with Go running on a Kube cluster and it's now been rock solid.

I've run high scale, high availability Go clusters involving thousands of nodes, dozens of eng teams, and it leveraged k8s. I've also worked at an Elixer shop with a few dozen engineers at a low scale ecommerce solution. The Go system was doing around 100k api calls a second, the Elixir system peaked at about 3k rps.

I would choose Go every single time. It has a better story for teams working together, largely due to better typing. Lacking types (and specs don't cut it), I still found I had to go up multiple function calls to understand what the parameters were, how they could be used, etc. so much state has to stay in your head, which I did not expect from a functional language

Plot twist: Kubernetes is written with Go

Common trend in Go circles, I would say

Recreating programing language stuff, after telling us we don't need them.

It was like that with java too in 2000/2010

What came to your mind? Not sure what Java said wasn't needed in 2000 but added in 2010? Lambdas?

They might be referring to generics, released with Java 5 in 2004, 5 years before Go 1.0.

Ah yes. But it looks like Java had lots of discussions about generics in 1998, I can't find a quote of "Not needed."

https://wiki.c2.com/?JamesGoslingOnGenerics

One would expect that a language designed in 2009 would have taken some lessons out of it.

I guess something like this will slowly be added to the Go stdlib.

Just as adding more routing functionality recently.

I've always heard a lot of good things about elixir - I feel like if it was statically typed, the landscape for network oriented programming langauges would be a lot different. And with how popular microservices have become, how big and complex a lot of cloud architecture has become, that could've been a big difference.

To some extent golang fills that void because of net, it's application in projects liks k8s, and it's concurrency dx through goroutines. But it's also had problems that I don't want to dive into here that I think make it more divisive than would be expected.

And that's my point, a lot of these things like microservices, "severless" and k8s are just poor and overly complex imitations of OTP. Many of these problems have already been solved by this humble stack which has been around since the 1980s.

- https://medium.com/coryodaniel/from-erverless-to-elixir-4875...

- https://elixirforum.com/uploads/default/original/2X/f/fdd70a...

and yet we barely see any production software from elixir

This is absolutely not true and you know it.

Perhaps you’ve heard of Discord, Pinterest, WhatsApp, Spotify, Moz, PepsiCo? I’m sure I’m missing a whole bunch of names as I’m in the bootstrapped world where you’re seeing a lot of Elixir (especially now that LiveView is stable).

Those are all not using Elixir? Maybe for some obscure cronjob

Tell me, why would you pick something that needs 8 servers to do the job Go or Rust could do with only 1?

For one, Phoenix is a great web framework (especially with LiveView) and Ecto data layer. Show me any tooling in Rust or Go that is as productive for full stack.

> Show me any tooling in Rust or Go that is as productive for full stac

Allow me to introduce you to this language called PHP.

Well PHP is certainly neither of those languages

I’m sure Phoenix is great, but in real-world experience, my former startup tried to use it, found the ecosystem and tooling extremely lacking, encountered severe problems with the learning curve, and pivoted to Rails.

Strange. I've dropped into several different startups and gotten people up to speed in days if they were experienced devs. One case was more painful, but much of that was due to engineering being outsourced to a team of contractors and management being from a non-tech industry.

Usually the hardest thing for devs I've seen learning Elixir is just getting used to immutability. What were the severe problems with the learning curve your former startup encountered?

The most productive web framework is

https://laravel.com/ (or Django or Rails)

because it brings most of the things you need to write in other frameworks by yourself. Too many reject it, because, PHP!

C# with ASP.NET Core + EF Core, AvaloniaUI or Uno or GTK bindings if that's your preference, Unity or Godot, and more.

Can build for Linux, macOS, Windows, Android and iOS, either JIT (better for servers, sometimes GUI/Games) or AOT (better for phones, CLI, serverless).

Its build system and CLI tooling is very productive and easy to get started with.

My biggest issue with C# is around communicating with other platforms/systems.

In PHP:

    return base64($myText);

is all I need (or sha1(), etc). The standard library (with it's bizarre inconsistencies that you stop noticing after half a decade) is quite complete.

In C#, it's much more involved to do these "easy" things. Even reflection is easy in PHP:

    $class->$dynamicMethod(...$props);

I moved away from C# about 3-4 years ago, and I don't miss it.

Reflection is notoriously problematic in regards to type safety in many languages and often isn't the right tool for the job, including C#.

The base64, in most languages, requires importing the right package or namespace.

Converting bytes to Base64 is just Convert.ToBase64String/CharArray(bytes).

I can't believe someone would seriously and unironically suggest PHP. It does not even compete at the only area it's applicable at being back-end or server-side rendering.

It wasn't always that easy in C#, fwiw.

> It does not even compete at the only area it's applicable at being back-end or server-side rendering.

I'm not sure what you mean here. I've deleted my blog, but I once published benchmarks showing PHP was faster than C# in some cases. I'm currently working on a reimplementation of some C# stuff in PHP and competing with C# quite well.

PHP is written in C; it's quite fast.

PHP is an interpreted dynamically typed language. It would always be slower and would always have strict performance ceiling. Given sufficiently competent compilers of similar level of engineering effort, that would always be true. PHP is within the same performance weight category as JavaScript. C# is in the same weight category as Kotlin ad Java, sometimes Rust and C++. It is guaranteed in the same category as Rust and C++ for performance-oriented code (struct generics and spans).

To think that an interpreter, where each single instruction is, in the very best case, a computed goto jump with args evaluation, would execute the code faster or comparable to code that is compiled to CPU instructions, is insanity. Even when/if PHP gets JIT compiled, it still has the same language constraints where even something as sophisticated as V8 has to contend with language spec so it cannot optimize away e.g. property access.

It might be best to re-evaluate prior assumptions and knowledge which do not correspond to reality.

> It might be best to re-evaluate prior assumptions and knowledge which do not correspond to reality.

heh, right back at you dude. Opcache JIT is running on an actual CLR just like C#, it can even AOT compile.

Phoenix and especially Ecto are fantastic, and liveview is really cool. Having worked in a couple Go organizations and only one Elixir one, I don't agree that this is what makes one productive. These tools save some time. What really saves time is being able to jump into unfamiliar code and be productive. Go is best in class for this after the team can no longer keep the entire code base in their head.

Or C# if you would rather use a nicer language but the use case is not critical enough to justify the cognitive price of Rust :)

Spotify backends are written in Elixir? Link? Would love to read about that.

https://prograils.com/elixir-phoenix-liveview-spotify

"Spotify backends are written in Elixir?"

From the article: Spotify is using Elixir for an internal ad debugging portal.

So no. Spotify backends are not written in Elixir but:

"The listener-facing backend services are done with Java."

My impression has always been that they’re a Java house: https://mvnrepository.com/artifact/com.spotify

But of course most large orgs have a little bit of everything.

The ecosystem around Elixir/Erlang is just not comparable to what Python/Ruby/Go/Java/.NET/Node even PHP have.

Elixir is promoted by enthusiasts a lot but once you start writing a project in it, you’ll realize after a couple of months you are writing a lot of things yourself, popular tools don’t have bindigs, lot of libraries that do exist are abandoned etc.

I worked on a Phoenix project that had a Graphql API, we couldn’t integrate it with Apollo Graphql because the Elixir library didn’t support some features, had them in the backlog for years. The company had 20+ other services in different languages, none had this issue.

There is a delightful new language if you are really insistent on having static typing while using the Erlang runtime: https://gleam.run/

Though I am not buying the idea that lack of static typing would hinder adoption as many of the most popular backed languages are traditionally dynamic with gradual typing only becoming popular in recent years.

I've worked in companies that used Java and companies that used Elixir. No (noticable) difference in availability, performance, bug count or business success (perhaps the Java ones were more successful).

We need to drop this fight around tools. Discussions are fine, but "My tool is better than your tool" doesn't get us anywhere (not saying you're doing this).

In general there is not a lot of innovation (in the mainstream), the only recent thing that comes to mind is Rusts borrow checker.

Is it though?

It's been painful to see how much Java has squandered it's potential. Putting aside something like OTP, just the concurrency in Java has been confusing - project loom has been on the horizon for a long time, and it makes it difficult to invest in something reactive like Reactor/Webflux. Or, having quickly reviewed elixir, since it uses the actor model, something like Akka - which words don't even describe how much of a dumpster fire that whole thing became (which I feel like I dodged a bullet because my old boss was super gung-ho about how Akka was the next big thing a few years ago). And if we're talking about things on a platform level, then... spring is not it. Others have mentioned K8s, what takes a simple yaml config there takes like huge guides, a wing and a prayer on Baeldung articles, and a soul crushing soup of XML for config (yea I know Spring supports other formats, but it's roots are in XML and old guards just copy that stuff over).

It doesn't seem like Erlang/Elixir community have these problems. Idk if it's because I am not invested in it so the grass looks greener on the other side, but it really does seem like they've got a productive and focused solution.

You might be right, I don't know. I got off the Java train some years ago, sadly by moving to Scala (what a mistake!) - so I have no clue about the things you are talking about. As the companies I worked for were making hundreds of millions of yearly revenue and lots of profit based on Java, not sure they needed that.

I only have some experience with Scala/Akka. Not sure if Akka was bad or it's the actor model, I found it hard to debug and understand code written by others.

I'm now 50+ and I use Go. It's so simple it even works for old people.

A company I was working for was acquired by a larger company that was a Java stack. I reimplemented our entire Rails app in Elixir into their stack in about a year. Eventually they decided to port it to Java. Took 2 seniors and a junior a year and it still doesn't perform as well as the Elixir app (soft realtime websocket stuff).

Whatever someone does, some other jumps up: But Lisp! But Erlang! But Haskell!

While others nod and think, "I did choose Go for some valid reasons, great library."

I’m not talking about language syntax, but actual out of the box runtime capabilities.

I think @KingofCoders is too. Lots of reasons to choose a language. Runtime capabilities are definitely among them but there are plenty more.

I see comments like these all the time Haskell/Erlang/Elxir/Elm/Ocaml are the greatest thing ever. However basically no one uses them for work. There was a post on HN about how OP has given up on using Haskell in production after 10 years of trying to do so because its just not feasible. (I couldn't find the story on a quick search.) But they still use it in all personal projects. They appear every now and then and have scared me away from non popular languages for the most part.

I just see too many comments on HN from people that have decades more experience than me that say that the theory of these amazing languages simply does not survive contact with the real world most of the time. I'm sure there are great things built with them somewhere out in the world. I just don't think its worth it for the vast majority of developers to worry about.

I don't know if I have decades more experience than you but I can confirm that the amazing language Haskell survives contact with the real world. Here's what I made with it: https://groq.com

(amongst other languages!)

Not trying to start a war but are you using an example of a personal project that basically proves the point I just said?

The other people that comment on it say the same thing. They use it for personal projects but can never make it work at a corp job.

I was a little bit unclear though in my previous comment. I mean production as in at work with lots of people besides yourself.

On that, and slightly further off topic, if there’s a tutorial, cookbook, or worked example of using OTP but written in Gleam, I would lap it up. Enjoyed learning the language but kinda got stuck there. I didn’t want to have learn Elixir or Erlang just for that.

A small disclaimer - proceed with Gleam only if you are okay with its and overall BEAM’s poor performance compared to compiled languages.

Mostly an issue if you are doing number crunching.

What aspects of BEAM perform poorly? (Genuinely asking. I’m not very familiar with it.)

I would expect if the problem is reducible to that argument, Prometheus and Kubernetes would have been written in Erlang.

You just made my point. K8s is a poor mans OTP.

And there's some Elixir based loggers: https://logflare.app

My budget does not run to people who can write or maintain Elixir.

What do you mean by budget?

Cash. I can't even afford to hire people who are moderately competent because FAANGs keep herding them away.

One perspective is you can get more done in Elixir with less people, at least that's been my experience vs say Rails + React.

This has been my experience too.

That would be fine if I could hire one person, which I can't.

Also, we shot ourselves historically with Scala which had the same promises.

Working in go stack is objectively simpler. So it's easier to hire ppl

Is it in terms of hiring? Try posting a fake but real sounding job in the Elixir Slack group. You will get a ton of interest from people dying to use Elixir professionally.

Yeah anecdotally I see tons of developers who are looking for Elixir work. How can a language simultaneously be hard to hire for _and_ hard to get hired in?

Reply on news.ycombinator.com