> good debugging workflow

Most of use use IO.inspect/2, pry, :observer, :recon, and Phoenix dashboard for that.

> if you deploy to Kubernetes then there is a lot of overlap with Beam/OTP for deployment management etc.

These things are complementary. Releases are great for multi-stage docker builds. Libcluster is nice for allowing different containers to talk to one another without any messaging glue. Supervision can crash and restart at a sub container level.

Yes you can also get breakpoints and some interactive debugging with the VSCode plugins. But its just not even close to the full interactive debugging of e.g a fully supported lang in Jetbrains. This is very much down to personal preference and I know that there is very powerful debugging and tracing facilities in Beam/OTP

For me, debugging was always too slow in JetBrains. I don’t know if it was a result of the IDE or the language (Python) but I would always end up using print statements instead.

With elixir reloading a single module is fast because of the functional architecture so I can at least drop down into the REPL instead.

I've had the same, as an on/off thing. I recently went deep into an interview process with an Elixir shop, but pulled out for a more stable tech.

I really like Elixir, and I think there is space for it. However, from a web app perspective I realised that what I really liked about Elixir wasn't related to BEAM, processes, or the actor model; but architectural. The consistent layout of Phoenix applications is simple and pragmatic, and as someone overly subjected to dependency injection I appreciate it. I've successfully replicated the architecture in other languages, but it's more of an uphill battle.

That's not to say the BEAM doesn't give advantages. Per process garbage collection and preemptive scheduling yields an exceptionally pleasant environment. There are almost no GC pauses, and you can literally spin up 1000 infinite loop processes on a Phoenix node without effecting your latency.

I'd like to see better tooling for Elixir before I'm ready to commit harder. Some simple things are missing. Notable to me: the language server can't use type specs to provide code completion, and doesn't have the refactoring actions of more advanced systems. I miss being able to rename a function without grep.

Google does provide elixir clients for most of their products: https://github.com/googleapis/elixir-google-api

Yes I was using them. But its just the repo and the documentation is quite lacking compared to the other languages. Like with most things it I referred to is workable but has just quite a bit more friction.

I learned functional programming first and I find it the opposite. And I find the context switch from functional to not is always difficult, namely because I can't just assume things are immutable and I have to go out of my way to make it so.

That's all to say that the mental overhead is just comfort more than anything.

I have a problem with a lack of static types. Was that an issue for you?

This is always a preference issue. You get strong types but the nature of hot loading and communication across clusters doesn’t leading to static typing being a practical trade off. The moment you add it, you end up with a need for contract enforcement across nodes that changes most of what the platform is designed around.

In practice, static typing just doesn’t add much other than headaches to a project of this style. Doesn’t mean you’re wrong for wanting them, just that the language might not be for you if you feel like you need them that much.

I understand why dynamic typing might be needed for code reloading and multiple nodes. However for an overwhelming number of uses a single erlang node is sufficient and code reloading itself comes with additional complexity that it is only useful for rare applications. On the other hand hand static types give you cheap and easy freedom from a large class of bugs. Erlang spends a lot of time bringing reliability through sophisticated patterns such a supervision trees etc etc but then totally fails by having dynamic typing. I love Elixir/Erlang but I would say that here (provocatively perhaps) the platform is penny wise and pound foolish: It spends a lot of time on sophisticated strategies while omitting the most elementary one: static types. I like the platform but like every platform it does have weaknesses. To me, personally, missing static types is a weakness.

You may want to take a look at https://gleam.run/

Gleam might be what you need then. The combination of strong types, dialyzer, guard clauses and pattern matching has been more than enough in my experience.

Fully static typing doesn’t bring its benefits without costs.

My biggest issue with the language. I make use of typespecs where possible but it's a far cry from anything enforced.

In fact yes. You can use Typespecs and I tried to make up for it with tests. However it did not really come close to the safety and convenience of static typing for me.

Same as you. The language looks nice but despite having tried Elixir multiple times this past 4 years, the tooling and lack of Jetbrains support always makes me stop and run back to Ruby.

Nix/NixOps has some similar issues with Kubernetes overlap IMO. The easy answer is "lol, our tooling is better, just embrace it entirely and forget Kubernetes."

But it's not that simple— Kubernetes is everywhere, especially once you're into things like short-lived CI environments. Kubernetes is by far the best way to do autoscaling Jenkins or GitLab CI runners; at this point it's kind of the obligation of the non-k8s systems to integrate and interoperate as best they can.

Yes exactly. The beautiful thing is, you can install a well designed phoenix app on some bare Metal servers and you will have the features of half of GCP. Monitoring, deployment management, rolling deployments, dashboards, PubSub, in Memory database, load balancing etc. but this made it feel like an all or nothing decision to me. (Slightly exaggerated)

> But I fear its not for me. At least not yet.

What do you mean not yet - what do you think is gonna change?

> pure functional programming is too much mental overhead for me

This means Elixir is just not for you, I don't think you have to be in an endless eternal debate about it. There is quite the disconnect between Hacker News hype and the real world sometimes.

As said. If the tooling and commercial language support would be better I might give it another shot. Also this was in the context of writing web software with deadlines. Given the time I would probably immerse myself deeper. I specifically wrote this post to give a bit of warning since I feel on HN it is considered tres chic and I would have liked to read a bit a of balanced criticism before discovering it myself. Not taking sides in functional vs OOP here.