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

171–180 of 340 posts

Re: Ask HN: Who regrets choosing Elixir?

#171

Post by tarsinge »

PragmaticPulp wrote: post #122
nicoburns wrote: post #107

Earlier quoted context omitted.

Why not get your existing engineers to learn erlang if you have such a need?

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…

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

Re: Ask HN: Who regrets choosing Elixir?

#172

Post by PragmaticPulp »

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.

> 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 point is: If you're going to write critical pieces of your infrastructure in a specific language, it's a requirement to have at least one person full-time dedicated to that piece of infrastructure.

When things go wrong at scale, you can't depend on a group of people for whom this is a part-time side project.

Re: Ask HN: Who regrets choosing Elixir?

#173

Post by nicoburns »

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

That depends what you learn. Spending 3 months working on a Rust project has done a lot more for my ability as a JavaScript developer (my strongest language) than spending those 3 months working on a JavaScript project would have.

Re: Ask HN: Who regrets choosing Elixir?

#174

Post by maxwindiff »

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?

Whether you hire an outside consultant or not doesn’t matter. You have to pay the cost one way or another, either by your employees spending time learning the language + experimenting + making mistakes, or by going through some training and hopefully making less mistakes (not guaranteed).

Re: Ask HN: Who regrets choosing Elixir?

#175

Post by nicoburns »

toyg wrote: post #159
gfodor wrote: post #157

Earlier quoted context omitted.

If you see your identity as an engineer to be one grounded in the languages you use, you have commoditized yourself, or are at least very junior. Programmers solve problems, usually with a mix of deep skill sets revolving around domain knowledge or knowing how to use computation, systems, etc to solve them. Competency in a specific programming language is far down the list of what defines the value of a specific indi…

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 lots of companies have say 2 or 3 backend languages (say C++, Go, and Python), plus a website in JavaScript plus mobile apps in Java/Kotlin and Swift/Objective-C. Being able to dive into all of those makes you incredibly valuable to this kind of company.

Re: Ask HN: Who regrets choosing Elixir?

#176

Post by [deleted] »

craigsmansion wrote: post #164
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…

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

[deleted]

Re: Ask HN: Who regrets choosing Elixir?

#177

Post by bitwize »

cplanas wrote: post #79
dnautics wrote: post #41

Earlier quoted context omitted.

> Any codebase beyond fairly small will be harder and harder to work with to an unreasonable degree, in my experience, and any perceived "velocity" gained from the dynamic nature of it is paid for doubly so by the lack of safety you get beyond toy projects. How does pagerduty deal with it, I wonder.

Or Shopify. Or Zendesk. Or GitHub.

Unit tests. Lots and lots and lots and lots of unit tests.

Re: Ask HN: Who regrets choosing Elixir?

#178

Post by tuxcall »

kenhwang wrote: post #152
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.

To me, this is the sniff test of a good engineer. All the good engineers I've known would've jumped at the opportunity to learn a new technology on company time/money. The engineers that refuse to learn generally don't grow.

Yes, it doesn't matter if it's a programming language or another technology. That's engineers not worth keeping around, stuck in their old ways, sooner or later they'll make themselves obsolete.

I'm not a programmer. I'm a programmer period.

Re: Ask HN: Who regrets choosing Elixir?

#179

Post by [deleted] »

toyg wrote: post #159
gfodor wrote: post #157

Earlier quoted context omitted.

If you see your identity as an engineer to be one grounded in the languages you use, you have commoditized yourself, or are at least very junior. Programmers solve problems, usually with a mix of deep skill sets revolving around domain knowledge or knowing how to use computation, systems, etc to solve them. Competency in a specific programming language is far down the list of what defines the value of a specific indi…

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.

[deleted]

Re: Ask HN: Who regrets choosing Elixir?

#180

Post by scarmig »

PragmaticPulp wrote: post #122
nicoburns wrote: post #107

Earlier quoted context omitted.

Why not get your existing engineers to learn erlang if you have such a need?

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…

I can kind of get this if we were talking about COBOL or MUMPS or something. But being paid to learn Erlang isn't really in the same category, or the same universe, really.

Maybe the emphasis should be more on the disappeal of your role being changed to maintain an old, flakey codebase than on the language.

Post reply on HN