Hacker News Reader

Comment by cpursley | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com