Live data from Hacker News

Ask HN: Who regrets choosing Elixir?

news.ycombinator.com

181–190 of 340 posts

Re: Ask HN: Who regrets choosing Elixir?

#181
post #76

Earlier quoted context omitted.

> You should still have tests, but IMO tests that are just checking that a string is a string are The correct completion to this sentence is "irrelevant.", because that's not what anyone is proposing. The fact is, behavioral tests catch a lot of type errors even without intending to, and more to the point, if you test all the behavior you care about, then you don't care if there are type errors, because they only occ…

My personal real life experience with Ruby developers disagrees with you, but I accept that I could just have experienced a set of developers that weren't very good at testing.

Trust your experience.

It's impossible to defeat the claim that "with good tests you don't need static type checking", since every counter-example can be dismissed by arguing that better developers would have covered that test case.

I can claim just the same that "with correct code you don't need tests", and dismiss every counter-example by arguing that better developers wouldn't have made that mistake.

Obviously we know that developers sometimes make mistakes, and sometimes these mistakes are in the tests themselves. So trust your experience regarding how this all works out.

Re: Ask HN: Who regrets choosing Elixir?

#182

Earlier quoted context omitted.

> there was no one left who could support an Erlang system. If you have $200k "python engineers" on the payroll who wouldn't jump at the opportunity to do some additional Erlang, maybe it's time to reconsider your hiring practices and that is the real cautionary tale.

I want to downvote this comment so much.

Why?

Re: Ask HN: Who regrets choosing Elixir?

#183
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 comment was so spot-on that I suspected we worked at the same company for a minute. Erlang / Elixir are languages that are easy to begin learning, but difficult to master. In our case, the team was able to get the basics up and running quickly, but the service became increasingly difficult to manage as our product requirements expanded beyond the strengths of the Erlang ecosystem's core competencies. In our case…

> We're a Python shop

Who decided that your company's raison d'être was to write some Python?

Re: Ask HN: Who regrets choosing Elixir?

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

> So how about don't be stupid about it and instead make three engineers devote 1/3 of their time to this? If your product-critical cloud backend depends on people being knowledgeable in a specific programming language, you don't make it a 1/3 time side project for multiple engineers. Also, if you start giving people "1/3 time" responsibilities, you're one step away from "everything is top priority" territory. The po…

You don't give it to 3 random people. You give it to a team which depends on it. It's not a side project because if that breaks your project breaks.

Re: Ask HN: Who regrets choosing Elixir?

#185
post #109
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…

> Who's on call? Side note: Pagerduty comes with many hilarious sounds, including a very realistic meow. Thus we practice meow driven development: I don't want my phone to meow desperately.

I have personally always appreciated the barbershop quartet...

Re: Ask HN: Who regrets choosing Elixir?

#186

Doing Elixir since 2016, deployed multiple Phoenix Projects to Production. Of you want to build dynamic web applications, phoenix+LiveView is imo _the_ best Option currently. It also keeps the promises: reliable (zero-maintenance apps running for years on heroku), productive (prototyping things is really fast: like rails 2/3 days), fast (templates render fast even when complex). It is also great to have actor process…

From your remark about deployments, I'm assuming you're not using Distillery or Mix releases? If you use a release, you can deploy a tar.gz with "batteries" included (everything you need to run your app, including the BEAM). At work we have a dozen of elixir apps running smoothly in Production on plain Debian containers.

Re: Ask HN: Who regrets choosing Elixir?

#187
post #161

Earlier quoted context omitted.

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

FWIW I agree with you. I'm a Java dev and learning a language that's similar to it (C, C#, Python, whatever) does nothing for me but take away from learning more of my language. Other comments say an engineer is supposed to solve issues with the tools given to them. I can solve issues in other languages, I just don't want to. How does that make me a bad engineer?

For one, because you select your tools and reject others not based on their rational merits.

Second, because you are also likely to favor recruitment of other devs based on this cultural choice not on their merit, eventually creating a clique.

Re: Ask HN: Who regrets choosing Elixir?

#188
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…

> there was no one left who could support an Erlang system. If you have $200k "python engineers" on the payroll who wouldn't jump at the opportunity to do some additional Erlang, maybe it's time to reconsider your hiring practices and that is the real cautionary tale.

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 you're a kind of technician not a programmer.

FWIW, having done it professionally for ~15 years I'll never write another large project in Python again. Erlang's runtime is so much better than Python's it's just ridiculous. I feel stupid for not realizing this sooner.

Re: Ask HN: Who regrets choosing Elixir?

#189
post #76

Earlier quoted context omitted.

My personal real life experience with Ruby developers disagrees with you, but I accept that I could just have experienced a set of developers that weren't very good at testing.

Trust your experience. It's impossible to defeat the claim that "with good tests you don't need static type checking", since every counter-example can be dismissed by arguing that better developers would have covered that test case. I can claim just the same that "with correct code you don't need tests", and dismiss every counter-example by arguing that better developers wouldn't have made that mistake. Obviously we…

Yeah. You formulated my opinion much more elegantly than I could've - in my experience it's always the "Well if the tests didn't catch this, we just aren't testing enough." Which in my experience is a losing strategy, you'll never test "enough" in languages like Ruby.

In my experience this idea always brings a strawman, "Well in statically typed languages you still have to test", which is obviously true. But the type of tests and the content of the tests is very different.

Re: Ask HN: Who regrets choosing Elixir?

#190
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…

> there was no one left who could support an Erlang system. If you have $200k "python engineers" on the payroll who wouldn't jump at the opportunity to do some additional Erlang, maybe it's time to reconsider your hiring practices and that is the real cautionary tale.

Completely agree. I worked at a company on a Common Lisp project where the Python crew refused to learn Common Lisp because they thought it would look bad on their resumes. This should be a litmus test for programmer quality: If they don't want to learn something because it's not "fashionable", they're probably lousy programmers who lack confidence in their own abilities. Do you really want these people working for you?
Post reply on HN