Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Who regrets choosing Elixir?

news.ycombinator.com

Post reply on HN
Print view View original

141–150 of 340 posts

Re: Ask HN: Who regrets choosing Elixir?

#141

Post by dnautics »

bluesnowmonkey wrote: post #126
pavel_lishin wrote: post #94

My employer has chosen it, and while it was fun to learn and is very neat, I don't think I'd ever write Elixir code for anything but a hobby project, especially if a large team is working on it. 1. Dialyzer is just a huge piece of shit. It's an incredibly impressive piece of shit, and makes it possible to pretend that Elixir supports typing, but it has so many edge cases that we've run into them writing even trivial…

With regard to mocking, I’ve found that it works better to swap in a fake process rather than a fake module. If you have a FooClient genserver that makes RPC calls to a service or database, make a FakeFooClient that responds to the same kinds of genserver calls and returns canned responses. Or even implement a simplified version of the external service in the genserver.

I did this and I found that as I increased the paralellism of my tests, the genserver got bottlenecked and the test suites started throwing heisenbugs, which is not what you want. You should really be using the Mox library, which I don't believe suffers from this problem.

Re: Ask HN: Who regrets choosing Elixir?

#142

Post by jrumbut »

briansteffens wrote: post #62

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…

This has always been what kept me away from Erlang/Elixir (which I gave serious consideration as both a project technology and a career path in it's 2010 era revival).

I've gotten to the point I can adapt to missing libraries but what it does at runtime is very different from anything else.

I don't do a lot of server side node.js but I have a lot of confidence if someone called me at midnight saying their node service was down I could jump in and start making progress fast. I think it would take some time running Erlang in production to get there.

Re: Ask HN: Who regrets choosing Elixir?

#143

Post by mrlatinos »

brazzy wrote: post #129
PragmaticPulp wrote: post #122

Earlier quoted context omitted.

Because engineers don't take kindly to companies changing the direction of their career development. 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? Now how happy are you going to be when you're informed that you're learning Erlang to maintain an old, flakey codebase written by 2 guys who left the compa…

So how about don't be stupid about it and instead make three engineers devote 1/3 of their time to this? That way it's a broadening rather than a redirection of their career, they can help each other, the on call duties are shared, and the business isn't dependant on a single person.

Dedicating a third of my time to a language I had no previous intention of learning is going to be a hard sell, even if you label it as "broadening."

If I'm a python developer, I'm now spending less time on my core competency, giving other python developers an edge. Seems like you're actually narrowing my career, unless I wish to apply for jobs seeking mediocre Erlang programmers...

Re: Ask HN: Who regrets choosing Elixir?

#144

Post by bluesnowmonkey »

Been paid to write mainly Elixir full time since 2017. Still quite positive about it overall but I can talk about some constraints in an enterprise environment.

In a large company with lots of services in many languages, avoid putting business logic in your Elixir code. Business logic adds coupling to related code in other systems that often all need to change together, or get changed in a hurry. Either way, the engineer trying to do the change probably won’t know Elixir. Likely they were appointed to make the change by a PM who doesn’t know or care much about which systems were built in which languages and who knows those languages. And that engineer won’t know Elixir, and they’ll complain about being unable to work on your Elixir system, and it will give Elixir a bad reputation at your company in the eyes of managers and PMs. It won’t matter much if your system has high uptime or low tail latency or whatever.

The solution to this is to only use Elixir for building infrastructure. Nobody cares much what language PostgreSQL or RabbitMQ or Kafka are written in. You don’t modify the source code for those things typically, you just use them through some kind of API. Similarly if your company needs a notification delivery system, you can build that in Elixir. You just have to do it in such a way that nobody will ever be blocked trying to launch a new kind of notification because they need to learn Elixir first. Make it fully accessible and extensible through its API so they never need to know what language you used.

Re: Ask HN: Who regrets choosing Elixir?

#145

Post by DevKoala »

ajkjk wrote: post #116
eshyong wrote: post #111

Earlier quoted context omitted.

Probably cost of training. You'd have to hire consultants to teach best practices and that could cost significantly more than hiring a new engineer. Plus there are other risks to maintaining two codebases in different languages.

You have to hire consultants to teach best practices?

I had the same reaction. However, I work for a small team with driven developers. It is expected from our engineers to learn “best practices” on their own time when we introduce new technologies. We are also compensated extremely well according to these expectations. If you have a team of engineers with a different mindset, you will need consultants.

Re: Ask HN: Who regrets choosing Elixir?

#146

Post by nell »

rlander wrote: post #125
as-j wrote: 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…

To be fair, if you’re rewriting an Erlang system in Python/JS and you don’t feel like you’re losing much, Erlang was the wrong choice from the beginning. The cases were Erlang shines are very hard to replicate in these languages.

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

Re: Ask HN: Who regrets choosing Elixir?

#147

Post by eropple »

dnautics wrote: post #132
gedy wrote: post #63

Earlier quoted context omitted.

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…

I don't agree with this at all. I am about as hardcore a static-typing advocate as you'll find--and I love tests. I write tests before I write code whenever I can do so.

But I also like writing tests to prove logic and rules, and not tests for data validation--because computers are incredibly good at nitpicky stupid shit, they can and should and must do it for me, and I have more important things to care about than "did they pass an int when I wanted a string?".

Modern statically-typed languages elide a great deal of that boilerplate you refer to, while still providing protection against foolish errors. And given that the rest of it acts as a runtime-introspective set of documentation for what you're doing, the rest of what you're describing as "boilerplate" provides other value as well. (The web framework I use, for example, uses your declared data types both as HTTP validation and to generate OpenAPI documentation for both humans and other computers. In a dynamically-typed language I'd still need to define these things as JSON Schema or the like--which is what happens under the hood here, it just actually provides for me dev-time and not just runtime benefits.)

Re: Ask HN: Who regrets choosing Elixir?

#148

Post by niels_bom »

nell wrote: post #146
rlander wrote: post #125

Earlier quoted context omitted.

To be fair, if you’re rewriting an Erlang system in Python/JS and you don’t feel like you’re losing much, Erlang was the wrong choice from the beginning. The cases were Erlang shines are very hard to replicate in these languages.

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

Afaik it still is.

Re: Ask HN: Who regrets choosing Elixir?

#149

Post by bryanrasmussen »

mrlatinos wrote: post #143
brazzy wrote: post #129

Earlier quoted context omitted.

So how about don't be stupid about it and instead make three engineers devote 1/3 of their time to this? That way it's a broadening rather than a redirection of their career, they can help each other, the on call duties are shared, and the business isn't dependant on a single person.

Dedicating a third of my time to a language I had no previous intention of learning is going to be a hard sell, even if you label it as "broadening." If I'm a python developer, I'm now spending less time on my core competency, giving other python developers an edge. Seems like you're actually narrowing my career, unless I wish to apply for jobs seeking mediocre Erlang programmers...

>If I'm a python developer, I'm now spending less time on my core competency, giving other python developers an edge.

so this argues against the theory that learning other languages and other programming paradigms makes you a better programmer in the languages you already know.

Re: Ask HN: Who regrets choosing Elixir?

#150

Post by dnautics »

eropple wrote: post #147
dnautics wrote: post #132

Earlier quoted context omitted.

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…

I don't agree with this at all. I am about as hardcore a static-typing advocate as you'll find--and I love tests. I write tests before I write code whenever I can do so. But I also like writing tests to prove logic and rules, and not tests for data validation--because computers are incredibly good at nitpicky stupid shit, they can and should and must do it for me, and I have more important things to care about than "…

The sorts of errors I'm talking about that typing will never help you with are object ownership (in non-rust, non-gc languages), use-after-free (ok rust helps with that too), array bounds-checking, use of optionals, incorrectly labelling functions (fn add(a, b) = a - b), race conditions, non-pointer resource cleanup (e.g. file descriptors, connection objects), paralellism errors (noncommutativity of operations), mutex deadlocks.

Basically all of these things (or their rough equivalent) are easily testable in Elixir.

Your point is taken in the large (I wrote a zig NIF library that reads zig types and automatically generates the code that performs the data deserialization from erlang terms), but in the specific case you noted, if you're using type annotations to create your OpenAPI spec, you're doing it backwards. Best practice is to OpenAPI spec to generate endpoints that you code for. (I'm aware that phoenix-openapi does not do this correctly)

Also, I want to point out that I wrote a generalization, not an absolute statement about typing zealots. I think you're rare. I like types and even wrote an (unpublished) typing library for elixir (proof: https://github.com/ityonemo/typed_headers) that engaged during tests, with the intent to make it compile time checks. But almost every typing zealot I have worked with absolutely hated tests.

Post reply on HN