Live data from Hacker News

Ask HN: Who regrets choosing Elixir?

news.ycombinator.com

131–140 of 340 posts

Re: Ask HN: Who regrets choosing Elixir?

#131
I've seen places regret Elixir, usually the following issues cause the biggest regret:

1. Hiring. Generally speaking, finding experienced Elixir engineers is not cheap nor easy. Also, chances of finding someone willing to work in an office is even more slim (very remote heavy talent pool)...

2. Deployment/monitoring. Shipping your first Elixir application to production will likely be one giant act of frustration if you're used to Ruby or other scripting languages. Compile time vs runtime settings and environment variables are a HUGE gotcha. Also, as fate would have it, BEAM is more like an operating system than a simple runtime and thinking you can toss it into container and be off to the races is a recipe for disaster. Hope you didn't want to use distributed Erlang... (though this has gotten better recently, tbh). A lot of common monitoring tools and methodologies have to be thrown out the window because of how BEAM works internally (there are great ones to accomplish most anything, but its just more to learn).

3. Distributed systems, make for distributed problems. Yes, Erlang/Elixir and BEAM give you some fucking amazing tools to build distributed systems... that doesn't make building distributed systems themselves "easy" or "quick."

4. Performance. Erlang/Elixir will probably take a hot-fast shit on most scripting languages when it comes to network requests; however, if you need to do any long-running number crunching or complex string manipulation, you'd be better off almost anywhere else. This could also be categorized as "use the right tool for the job, dummy."

5. Learning curve is real and vastly underestimated. You aren't just learning a language, you're sort of embarking on a quest to learn a new paradigm. Erlang/Elixir, BEAM, and OTP (I'm going to refer to them as the "Triforce") were designed together to solve a specific set of problems. The Triforce has been in-use, 24/7, 365 days a year, for 30 years, in real, critical, production systems. If you ever wanted to learn the "Actor" pattern, BEAM is the most metal implementation I know of... Also, really sit down and make sure you understand it's all "non-blocking" thanks to the scheduler being able to pre-empt processes.

----

With regards to 3rd party libraries, I find in Elixir and Erlang, I need and use way less of them... BEAM and OTP give you soooooooo much it's kind of absurd how little you end up missing or wanting.

----

Lastly, while a lot of the success stories here are great to read, a lot of them have bad code, or things that are just silly to the trained eye. And that's totally okay, the authors are learning, we all have do it, but I'd probably not recommend the code as study material. In general, try and find examples from people who have seem to have been using it for a few years.

----

Addendum (via edit):

FWIW, I've been writing Elixir for about six years now (just checked some commits), and have been employed full-time writing Elixir for five of those. I wrote Ruby before that, and have never looked back... If you want my number one selling point to any Rubyist :trollface: (but also very real), is in Elixir a "horrible, slow, wretched monolithic test suite" still will take less than 90 seconds to run.

Re: Ask HN: Who regrets choosing Elixir?

#132
post #63

Earlier quoted context omitted.

I agree, but I think it’s a common misconception. Having used many languages, both for very large and small projects, languages with compile time static type checking and run time dynamic type checking, I find it’s easy to rely too much on static type checking. I think what happens for a lot of programmers is that static type checking uncovers a lot of basic bugs and typos, so they feel like it has a major advantage…

This resonates with me as the first 10 years of career was using static typed languages, and saw that I and others in my circle were mostly using it as a very basic type of unit testing. This is helpful but at the cost of extra code and boilerplate. Some folks were incredulous that I shifted to languages like JavaScript and was fine with the weak typing, but tbh I'm a much better at unit testing than in the past. I'v…

I think there's a eye-poppingly large part of the community won't write tests unless they're dragged into it kicking and screaming and it gives them to "not have to write tests". I get it. Tests can feel like you're writing your code twice, and, they can add a bit of drag when it's time for refactor (a good thing IMO). If I am permitted to be cynical, a testing culture discourages "think about it really hard and then pull a solution out of your nether regions"-driven programming, which is a culture that is promoted by hiring practices at... Certain well known companies, which, in turn, is cargo-culted by startups.

Also most PLs/frameworks have very bad testing ergonomics, so that doesn't help.

You can't publically admit to "hating tests" because that has very bad optics. So, being a static typing zealot is the next best thing (after all, it will protect you from some classes of errors that are covered by testing). You pay for not writing tests in a bit of boilerplate, but boilerplate doesn't feel like you're writing code twice.

Re: Ask HN: Who regrets choosing Elixir?

#133

Earlier quoted context omitted.

I've seen this too, but I tend to think of it as an antipattern. The fact is, in most cases a Python function won't carry on as normal if you feed it an unexpected type, because while Python's type system isn't static , it is fairly strong . In general I am a fan of strong types and I would like it if Python's type system were a lot stronger. But ultimately this isn't what my post was about: I'm talking about modelin…

What do you mean it's fairly strong? Not challenging you, I'm just trying to get my head around all the type stuff.

Most of the time Python doesn't do implicit type coercion.

Re: Ask HN: Who regrets choosing Elixir?

#134
Here's some Elixir negatives from someone who's worked with it for four years, nearing five, and currently director of engineering at a startup where we use Elixir for 100% of backend code.

1. Expensive to find talent. 2. Deploy story was kind of shit until recently with mix release. 3. In Rails or .NET you can find a package for literally anything you can think of. In Elixir-land, it's not 100%. It's more like 80%. One example, there's a Twilio elixir lib, but bad luck one of the calls we need isn't supported by the package. In rails it's all supported.

---

But on the other end of this, it's all rainbows and happiness. It's fast, predictable, boring. I love that about the language.

I still use Nim for hobby projects, but anything professional I will write in Elixir.

Re: Ask HN: Who regrets choosing Elixir?

#135

Earlier quoted context omitted.

let it crash != robustness not required Let it crash is an engineering design for systems large enough that statistically unlikely failures occur regularly. Like a data center or the original use case, telephone switch centers. Even if let it crash worked, it seems philosophically inappropriate for a drone controller.

Yeah; the basic philosophy of 'let it crash' presumes that the issue is bad internal state, and you need to get back into a known good state. If your domain doesn't really have a way to get back to a known good state, or a way to determine a state is good and persist it, it's not going to help you.

[deleted]

Re: Ask HN: Who regrets choosing Elixir?

#136

Earlier quoted context omitted.

This is 100% correct, and a very huge pain point, and why you're supposed to use Mox, which solves that problem (arguably in a more conceptually "correct" fashion than ad-hoc Ruby Mocks). Admittedly there is a very steep learning curve, but it's worth it, because once do it you start to be able to do things you can't do in any other PL (not even erlang). It's a pity that the elixir community doesn't make this clearer…

It probably depends more on where they are coming from. Mox has more overheads for sure than options in Ruby or Javascript. Its more like mocking in Java or C++; where you declare an interface(behaviour), program against that, and then use dependency injection to load the mock or real code at the right time. I'd been working with Elixir for several years when I first tried using Mox and it still took awhile to get my…

> I would not be surprised to hear that newer teams really struggle with it.

I completely agree. Not having an expert Elixirist able to help me: It took me a full six months of fooling around with Mox (and a cryptic feature announcement in the 1.8 release) to really dig into and grok it. At this stage in my elixir experience, I have even PR'd a feature that's been integrated into Mox, so it's not completely incomprhensible, it's a super-well-written library.

Honestly, It's a totally (alien/from-the-future)-technology (in both the good and bad senses) library. The bad senses could be almost trivially fixed with an in-depth, free, online video masterclass or, hell, even a conference lecture on it, and blog posts. More people that really know how it works should blog about how amazing Mox is. Unfortunately, I suspect that the people who are using Mox to its fullest extent are too busy pushing code to prod, ha.

Re: Ask HN: Who regrets choosing Elixir?

#137

I've been developing Elixir since 2013, and professionally full-time since 2017. Honestly my only complaint is the lack of static typing. There is no way I'd prefer Ruby; Elixir gives you a lot more compile time checking and static analysis. As a project gets larger, it gets harder and harder to refactor because of the despair that sets in when contemplating fixing dozens or hundreds of broken tests that you can only…

Just throwing it out there because I've had similar thoughts - that is, I enjoy Elixir but would be uneasy embarking on a large project without better static analysis, and also wonder what better fits the bill of a statically typed server application language - maybe check out Kotlin. I was very pleasantly surprised when going back to Java from Ruby that I found it much nicer, and Kotlin looks very similar but with a few key ergonomics improvements. I haven't used it for anything sizable myself, but I will definitely evaluate it next time I start something new.

Re: Ask HN: Who regrets choosing Elixir?

#138
post #46

Earlier quoted context omitted.

>somewhat slow runtime (compared to C, Java, Rust, Go, etc). It's only slow if you are comparing a single-threaded operations, Erlang VM is designed to scale horizontally, not to be fast with one thread.

Elixir and Go both have similar performance (although Elixir tends to use a lot more CPU). Here's a pretty good blog post comparing Go, Node and Elixir: https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixi...

I hope I'm missing something here because that's an absolutely awful benchmark. Neither Go nor Elixir were stressed enough to start revealing failure symptoms, so Go could still destroy Elixir by 10x for all we know. Then Node was run single-threaded even though the test instances had 8 or 36 vCPUs.

But some people will still walk away thinking that Go and Elixir perform about the same while Node is 4x slower.

Re: Ask HN: Who regrets choosing Elixir?

#139
post #80

I work for a Ruby on Rails shop and we used Elixir for two projects about a year or two ago when it was getting a lot of good press. The first project was an API that was intended to serve as a middleman between a few legacy services. Basically the company that hired us was building a new JSON API but didn't want to rewrite all their old code and our job was to consume the output from their ugly legacy APIs and produ…

It sounds like the parsing you needed would not need to be generalized, as you were working on projects for which you knew the requirements. In this case, writing the custom parsers should have been a simple task, and not something that would have stopped or even deterred me from using a language. Frankly, in general, writing a JSON, or even an XML parser, is not challenging and should take little time.

These days there's a multitude of both XML and JSON libs for Elixir.

Re: Ask HN: Who regrets choosing Elixir?

#140
Recently was involved with an elixir backend being phased out in favor of python because of the following reasons:

* Not enough engineers can write/understand elixir which kept leading to people being blocked

* Library ecosystem for scientific applications is lacking

* The language itself is confusing and the macro capability causes code to be uniquely incomprehensible in each different module

It was a worthwhile experiment but you just can't beat the advantages of having extensive documentation and expertise in the more mainstream languages unless you have very specific performance requirements.

Post reply on HN