Hacker News Reader

Comment by preommr | Hacker News Reader

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.

View on HN

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

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.

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.

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.

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?

> 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

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.

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!

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.

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.

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

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.

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

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.

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.

Reply on news.ycombinator.com