Live data from Hacker News

Ask HN: Who regrets choosing Elixir?

news.ycombinator.com

211–220 of 340 posts

Re: Ask HN: Who regrets choosing Elixir?

#211
I really like Elixir and want it to be even more popular than it is but...

My only real complaint with Elixir (and this covers Phoenix and Live View too) is that things tend to get announced WAY before they're anywhere near being production ready, so you may find yourself postponing building anything because you're waiting for the announced thing to be ready to use.

For example Live View was talked about in the later months of 2018 but there's still some things missing today that make it pretty sketchy to really use it in a non-trivial production app, and the docs leave much to be desired. Things like LV based file uploads as being part of the library was in the "near future" or "on the horizon" a year ago, etc..

I only spent a weekend using it for a project to play with about 6 weeks ago and ended up uncovering some bugs and even some feature requests that quickly ended up making its way into the master branch of LV after reporting them. But these are for things that seemed very basic to me in the sense that if the folks who were developing it were using it in larger production apps, there's no way those things wouldn't have made it into the library sooner.

In other words, I don't feel comfortable or confident at all to use it in production because I'm afraid if I spend some real time working with it, I'm going to end up being patient zero for so many bugs and edge cases. I want to focus on building my apps and trust the libraries I use, not be a pioneer (software is already difficult enough without bugs!).

On the flip side, Rails is a champion here and IMO it's very much why it's so popular and will remain popular 5 or even 10 years from now. It's because most of the things in Rails come from tech focused businesses using it to drive their services and the core team also use it to drive their business. Everything feels like it's really battle hardened, production ready when features are talked about and was carefully designed based on months of real world usage.

With Elixir, Phoenix and LV that feeling isn't there -- at least not to me. It sort of kind of feels like the libraries are being built from a theoretical point of view. I mean, I know the creators of those libraries do consulting work, but it's super behind closed doors. There's never any talk about what drives the development of practical features and it's kind of a bummer to get glimpses of things on the horizon, but then years later they aren't ready for production.

That's the thing that worries me about the future of the ecosystem. I also think it's partly why it hasn't exploded in popularity. It's a nice ecosystem for sure, but it's missing critical components for it to be adopted by the masses.

That and I think generally speaking the language is very hard to pick up. I know I struggle hard with Elixir with ~20 years of general dev experience across half a dozen non-functional languages before touching Elixir. I still feel like I have trouble reading Elixir code I've written 2 months ago when it uses some "real" functional bits that I had to ask for help on.

I often feel like I hit 100% dead ends and have to ask another human for help. I don't think I would be using the language if it wasn't for the IRC / Slack channels. There's some folks going above and beyond to help people out there, including Jose himself (the creator of Elixir).

With Python and Ruby I rarely encounter situations where I had to ask for help like this. Google always had the answer for everything I couldn't figure out based on tinkering and reading the docs.

It's not just due to less blog posts existing for Elixir / Phoenix too. It's the language overall. I want to love it, but for whatever reason my brain won't accept it naturally. I get hung up so frequently. I know this is just my brain being an idiot, but I do wonder if anyone else feels the same.

My gut tells me yes because otherwise the language would already be one of the most popular choices for building web apps. There's a lot of great things surrounding the language.

Re: Ask HN: Who regrets choosing Elixir?

#212
post #159

Earlier quoted context omitted.

Well, that’s not how programmers are recruited in the real world though. Java shops will hire Java programmers, C# shops will hire C# hands, etc etc. Marketing yourself as a generalist problem-solver will get you, at best, in one of those nightmare scenarios where you’re the only programmer in a non-tech company.

That's why you don't market yourself as a generalist problem-solver. You market yourself as an expert in C# AND Python AND Swift AND... whatever else you know how to use. With appropriate signalling to communicate your experience levels with each. There are lots of senior roles that require oversight of multiple projects that are working with different tech stacks. Some companies specialise in a single language. But…

"Javascript" though isn't Javascript. I mean it could be, but it's worthless in that context because what you actually need to be productive is familiarity with the browser DOM, current frameworks for frontend or backend, and basic project structures.

For Java it might be enterprise Java, it might be Android, in which case you need familiarity with those frameworks to be productive. For Swift it'll be iOS.

No one's "diving into" the codebase for an iOS app starting from "I mostly do backend web app development in Golang".

Are you an "expert" in all those things? I doubt it. In fact the worst possible thing you can generally write anywhere is that you're an expert in C++ which at this point is oh-so-many subdialects.

Re: Ask HN: Who regrets choosing Elixir?

#213
post #92

TL;DNR, use a language your company can support. It doesn't matter how suited to the job a language is, if it's single Engineer or small team, what happens when they move on? How do you support it? Who's on call? Not Elixir, but a cautionary tale from our Erlang project. ~8 years ago a our IoT backend was written in Erlang, this was the early days of IoT, so sure it made sense as a technology, could scale well, handl…

Your "python engineers" couldn't do anything even touching Erlang? What

Re: Ask HN: Who regrets choosing Elixir?

#214

Earlier quoted context omitted.

This, twice. Back in the day people would balk at hiring Python programmers saying, "there are so many more Java programmers", and I used to say, "Why would you hire a Java programmer who was unwilling or unable to learn Python?" Same logic applies here: Why would you hire a Python programmer who was unwilling or unable to learn Erlang? (Especially if you're going to pay them to do it!) If you can't switch languages…

Regrettably, also back in the day and probably around the same time, companies who wanted to hire "outside of the box" asked for Python. Not because they were python shops, but because they figured that people who had an interest in a new but not-quite-commercially viable language must have some sort of intrinsic interest in programming, and would likely make for better programmers.

This is because those shops read the PG essays, and think that the the shibboleth is Python, it is not. The marker is that that someone is at the fringe and not in the middle of the flock.

I have met lots of engineers who are smack dab in the middle of the flock when it comes to tech stacks, or even _behind_, but they were more than capable. Hire for what you need. But what you think you need and what you actually need is probably not know to you.

Re: Ask HN: Who regrets choosing Elixir?

#215
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...

Eh. This blog post runs a single node process on a 36-core CPU. I'm not a fan of node but that's hardly a meaningful benchmark

Re: Ask HN: Who regrets choosing Elixir?

#216
post #158
post #146

Earlier quoted context omitted.

> The cases were Erlang shines are very hard to replicate in these languages. I'm just beginning to get interested in the Erlang ecosystem. Could you please add more color to this and give some examples where Erlang shines? IIRC, Whatsapp backend used to be on Erlang.

That would make sense that whatsapp backend is in Erlang. Erlang was developed for telecommunication systems where you need performance and the ability to hot swap code.

Erlang's hotswap and Python's hotswap are of comparable power, ie, both are crappy. Being able to do something isn't the same as doing it well.

You can hot swap all languages.

Re: Ask HN: Who regrets choosing Elixir?

#217
it was huge mistake for us, it was chosen for the wrong reason, to solve a non-problem, complicated everything without adding any value.

* cant find people for it and if you do they come because of the tech not because of the real world problems we are trying to solve.

* the no types thing makes people write tests that test for typos and make refactoring incredibly difficult because you have to fix gazillion pattern matching tests

* the tooling is just horrible, cant jump, because of pattern matching that makes it much more annoying

* phoenix was complete misfit for us as well, so i ended up hating it for no reason

so because of no-tooling and on-refactoring, accidental complexity only grows, and we ended up with much more fragile system with infinite failure domain.

i wrote briefly about why it was chosen at https://eng.rekki.com/kitchen/kitchen.txt and why we moved to go.

that being said, i am sad that this was my first real world experience with elixir, in a project where it was not a good fit, so now i am totally biased against it. when i tried it briefly for few hobby projects it seemed like a quite cool language.

-b

Re: Ask HN: Who regrets choosing Elixir?

#218

Earlier quoted context omitted.

> If you're an up-and-coming Golang developer, how happy are you going to be when your company takes you off of a Golang project and makes you the new Erlang person? In my mind good developers are not developer, they are engineers that solve problems with the right tools.

> In my mind good developers are not developer, they are engineers that solve problems with the right tools. Given infinite time and no deadlines, sure. But in the real, you can't expect your engineers to learn entire programming languages and associated ecosystems on the fly as they debug issues in production. If your Erlang-based cloud backend starts going down, you can't afford to wait around while engineers teach…

Even Andrei Alexandrescu and Jon Skeet haven’t spent their entire careers focused on their favorite languages.

Re: Ask HN: Who regrets choosing Elixir?

#219
post #158

Earlier quoted context omitted.

That would make sense that whatsapp backend is in Erlang. Erlang was developed for telecommunication systems where you need performance and the ability to hot swap code.

Erlang's hotswap and Python's hotswap are of comparable power, ie, both are crappy. Being able to do something isn't the same as doing it well. You can hot swap all languages.

If you're claiming that Erlang is no better at hot-swapping code than "all languages", you haven't seen Erlang's hot-swapping abilities.

"All languages" provide you the ability to run arbitrary code, and thus theoretically support hot-swapping, but if you try to put it into practice you'll soon run into real obstacles you hadn't considered that either bite you or at the least make your job a lot harder. Erlang provides those practical solutions that make hot-swapping easy (in other words, practically possible).

TL;DR: On the question of buy vs. build when it comes to hot-swapping abilities, Erlang falls on the left while "all languages" start at the right.

Re: Ask HN: Who regrets choosing Elixir?

#220

Erlang/OTP is really cool and I found the Elixir language pretty reasonable and even nice but: 1. Elixir is still a pretty leaky abstraction over Erlang. In my experience it's not enough to learn just Elixir, I regularly had to dive into Erlang library source code to debug or answer questions. This somewhat negates the benefit of a small, stripped down syntax when you often have to learn another one in conjunction. 2…

I've hit number 4 quite a bit. If there's a system that's entirely Erlang/Elixir it tends to work well, and is generally very pleasant to work with. This afaik is the actual usecase? ie not big distributed systems, but small(ish) self contained and self sustaining systems. And then you start layering these systems together with containers and ugh

I've certainly found it to be much more specialist than I think many cheerleaders would have it. It can do most things out of the box (and that I guess is the point of OTP), but to make it do those things requires quite a deep understanding of the platform (and that it is a platform, that the language is just a way to interact with that platform). Elixir is my favourite of any language I've worked with, so I'm not down on it, but it's not general purpose

Post reply on HN