Live data from Hacker News

Ask HN: Who regrets choosing Elixir?

news.ycombinator.com

151–160 of 340 posts

Re: Ask HN: Who regrets choosing Elixir?

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

A good engineer will prefer some language(s), but be able to figure out anything should the job require it. This career track shift stuff is complete bullshit.

The workers are settled and and don't want change. And there's nothing wrong with clocking in and out and not giving a shit about your "career". But there is something wrong with the managers falling for this.

Re: Ask HN: Who regrets choosing Elixir?

#152
post #129

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.

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.

Re: Ask HN: Who regrets choosing Elixir?

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

Yes that. But also only use paradigms which the company can support.

For example good static typing is not just about adding type declarations but about taking advantage of the type system to the right degree. (Like don't ever overdo it, it's killing productivity most times).

But what degree falls into the productivity boosting spot and from which point on it will hinder productivity depends a lot on the team.

The problem often starts when the team changes and e.g. a pure scala/rust/C++/Ocml team get people cross entering from languages without any usefull static typing.

What had been reasonable and useful might now be a hindrance to the team!

I ran into a situation where this caused massive delay. (Well through the actual root cause was miscommunications, people not complaining about problems and instead trying to find ways to fix them behind the back of other people force pushing nice looking simple solutions which just happen to fail many edge cases, killed the write, refactor, test cycle and increase maintenance cost longtime :( )

So well 1st never overuse type systems. 2nd communicate problems, especially if you have problems understanding anything even if it just takes longer then you think it should.

Re: Ask HN: Who regrets choosing Elixir?

#154

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…

That's funny you say that - I've been following Kotlin a long time and lately have been getting interested in it again; somehow my thoughts keep leading there.

If anything holds me back its my experience with Scala. I used Scala for awhile (actually it was my introduction to functional programming) and I like the language but everything about it that seemed to make me unhappy was related to the tooling and JVM ecosystem in general. I should give Kotlin a real chance on a small project though as I haven't done that yet, I've just read the language guides.

Re: Ask HN: Who regrets choosing Elixir?

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

Yup pretty much. Esp when it’s something like Erlang that passes the sniff test as something that likely will expand your knowledge in a meaningful way, and be a long lived technology.

Re: Ask HN: Who regrets choosing Elixir?

#156

Right tool for the right job, I think. I’ve had absolutely wonderful experiences with Elixir doing web apps (both LoB style and SaaS style). Probably the best one, and it’s such a canonical example, is a group chat app using Websockets. It just feels so good, and with libcluster, multiple nodes in K8s can autodiscover and join each other. No problems at all having chats where the members are connected to websockets o…

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.

Not at all, "let it crash" is simply a way of phrasing "consider reset in your flow of control".

In embedded systems, certainly safety-critical ones, you have to consider the possibility of a reset path at all points in your flow of control. Your code resetting is a valid flow of control.

This is absolutely necessary to get a properly robust system.

Your drone system needs to be able to handle a reset at any point and still maintain adequate control of the aircraft. This is "Let it crash".

"Let it crash" is essentially the same thing. Take account of the necessity of reset, because you can't stop it happening.

Re: Ask HN: Who regrets choosing Elixir?

#157
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 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 individual engineer to an organization or project.

Re: Ask HN: Who regrets choosing Elixir?

#158
post #146

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.

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.

Re: Ask HN: Who regrets choosing Elixir?

#159
post #157

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

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.

Re: Ask HN: Who regrets choosing Elixir?

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

I'm interested in real arguments were Erland would be better fitted than java/kotlin
Post reply on HN