Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?

Here's a few of the highlights for me:

1. It makes me want to write more tests.

In other languages, I always defaulted to opening up a terminal to quickly hammer out something before implementing it and usually came back to the tests as an after thought. Sure with an IDE integration you can highlight and execute just the test you're looking at, but in many cases I found it clunky.

With Elixir, the entire test suite executes so fast that it's easier and faster to just work with the tests than hammer through things in the console.

For the situation where the console works better, you can copy the iex lines above your method as a code comment and that will run as a test when you run your test suite (so tests as documentation essentially).

Lastly on the test front, the assert_value library is incredibly helpful for hammering out first versions of unit tests.

2. After taking the Coding Gnome course from Dave Thomas, I love the approach to code structure.

Dave emphasizes thinking of the functionality of your application independently from the interfaces which access it. For example, the HTTP layer, a REST API, a Websocket layer, the command line, and an IEX terminal are all different interfaces.

Thinking of my code that way and developing around an internal API rather than doing something like REST first testing, etc has made things a lot cleaner for me. I'm also a big fan of the defdelegate approach for that internal API layer.

The libraries I've needed so far have been really solid, but I generally don't pull in libraries unless I really need them anyway. If I'm connecting to an API, I'd rather write the connections directly in most cases as I need them rather than pull in an API library directly for it. Gives me more control and better understanding of things and I like that. YMMV.

3. Tooling wise, VSCode has been great for me.

I've considered reaching for IntelliJ with the Elixir plugin, but as it stands right now I'm very happy with VSCode. It's been a great experience and all that I need on a day to day basis.

There's a lot more to say than that, but these are my biggest things that I'm liking so far.

Engineers at both unicorn companies consider Elixir one of the reasons they were able to grow the way they did, both in terms of customer count and engineers. Sure, it was hard to find people who had production experience with the language. Didn't really matter; deploy it with Docker (and eventually Kubernetes) the way you would anything else, and if you need clustering then libcluster can manage most of that for you.

Learning OTP is a nice-to-have, but 98% of the time your devs don't actually need in-depth understanding of it (assuming you're a typical web-based startup). Web servers hitting a database is naturally pretty scalable as long as you design your database decently. Scaling your database is _way_ more important to scaling technical systems than your choice of programming language.

Even if your team doesn't need a deep understanding of OTP, _you_ should have a good understanding of GenServer, GenStatem, Application, and Supervisor so you can evaluate 3rd party libs or develop in-house libs. Most devs who are working in product need to focus more on how to write well-factored code to interact with data services like Postgres, Redis, or Kafka.

Yeah, there's a lot of hype around hot code loading, ETS, Mnesia, and the like. Don't use them unless you absolutely have to. ETS is fine for a local cache once you have a generic garbage-collector as long as you don't care about losing that cache on deploy. You probably care, so just use Redis most of the time.

The claim that it's impossible to hire Elixir devs is way overblown. Just hire smart people; software engineering principles are applicable across languages even if the languages have different paradigms. You might have to find new ways of implementing those principles, but discussions around good boundaries and extensible code are more important than "when should I use if vs case vs cond vs pattern-match in a function head?". Podium hired a _lot_ of engineers right out of dev bootcamps. They paid for that in code quality for sure, but even the most green engineers were able to get going in Elixir pretty quickly. As long as you have one or two "seed" engineers who are willing and able to teach others, the hiring problem isn't really a problem.

I'll get a lot of flack for this one, but if your company has a monolithic codebase, Umbrella Applications are a great way to enforce internal boundaries if you're on Elixir 1.11 and have warnings-as-errors set up. Keep splitting any sub-apps that start getting large and the warnings-as-errors will prevent circular dependency hell for you.

If you're doing a service-oriented or microservices architecture, Elixir is pretty great. Synchronous communication is pretty easy to set up if you want synchronous communication; Absinthe makes a great API gateway, gRPC support is decent on both the client and server sides (though testing still needs to be improved with the gRPC lib...)

If you're using plain ol' HTTP, there are a plethora of HTTP client libs that scale well (and a number that don't without effort - some painful lessons at Divvy on that one). Phoenix is a great HTTP server framework, and LiveView is great if you don't want your team to have specialized frontend vs backend devs or get an MVP off the ground.

Kafka support is... fine, I guess. As long as you only need basic Consumer/Publisher capabilities, anyways. If you need anything more advanced, you have to go somewhere else to get the stateful processing capabilities that Flink or Kafka Streams or KSQL will give you.

Redis support is good, with varying options for high-level vs low-level implementations.

The hardest part of working in the ecosystem is the ecosystem itself. The built-in tooling is amazing, but Ruby/Java/JS/ will always have a larger selection of libraries.