Live data from Hacker News

Ask HN: Who regrets choosing Elixir?

news.ycombinator.com

241–250 of 340 posts

Re: Ask HN: Who regrets choosing Elixir?

#241
post #9

Earlier quoted context omitted.

Because of it's magic. Debugging it it a nightmare especially when you have to roll up your sleeves and go into Erlang.

This is not my experience. Just yesterday I had to debug an error in staging that had cropped up because erlang had changed its public API for ssh_file in OTP/23. Despite being three private libraries down (and in an obscure option, and being not well documented) I had the bug identified in 30 minutes and the patch rolled out on all three library levels in another hour. The biggest help was IO.inspect, and then the n…

As one of the contributors to ElixirLS this makes me happy :)

Re: Ask HN: Who regrets choosing Elixir?

#242

Earlier quoted context omitted.

Can you expand what you mean re: large projects in Python?

Yeah, thanks for asking. I've been a happy Python programmer for over fifteen years, so this comes from a place of love and respect. Beyond roughly 150k LoC you start to run into difficulties keeping everything straight over time, especially if you use a lot of indirection or other magic. The aspects of the language that help you go fast when you're prototyping (is "RAD" still a thing? Rapid Application Development)…

from personal experience with mypy, the great thing about gradual typing in a dynamic language is that, well, it's gradual! when I want to do something extremely dynamic, there's no horrible reflection API in my way. but most of the time I can live happily inside the walled garden mypy provides.

Re: Ask HN: Who regrets choosing Elixir?

#243

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.

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 y…

I'll be the first to admit... I'm a little conflicted by this..

I've almost exclusively worked on the usual procedural /OO languages professionally (java /c#)..I like to experiment and I've picked up a bunch of languages along the way (perl, python, coffeescript, f#, nim etc).. And its usually because I want to see what's different and spend enough time to do something useful (but not large) with it. Also, it helps you become a better programmer IMO. otoh, if I'm hired for my skills but then have to work on js( don't actually like the js eco system) or haskell (I gave up after trying and I doubt I'd become very good at it anytime soon if I were forced into it) I'd be not happy either (and IMO, with valid cause that doesn't reflect on me or my abilities)

Re: Ask HN: Who regrets choosing Elixir?

#244

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…

If I had a Python job (a language I enjoy) and I was forced to work in a language I don't (say, Perl), I'd start complaining about it and looking for something else to do. I personally wouldn't mind working with Erlang, but that isn't the point. Many developers "can" do these things but it doesn't mean they want to.

It's pretty much how we treat our Python projects. All of us hate it, but data science is done in Python so we still need some percentage of the engineering team fluent enough in it to sustain operations with it (on-call, maintenance, bugs, eventual decommissioning).

The moment we can get rid of it, you bet we will. But it's much easier tearing it down when you understand it enough to discern designs driven by the limitations of the tech vs requirements for the product. Black box ground up replacements are hard and expensive compared to ports. Also, thankfully it's Python and nothing something more difficult/complex.

At the end of the day, it's a job, and there's an expectation of professionalism to do what's necessary. A lot of people on HN like treating tech jobs like a paid hobby which I think is detrimental to career development.

Re: Ask HN: Who regrets choosing Elixir?

#245

Earlier quoted context omitted.

Yeah, thanks for asking. I've been a happy Python programmer for over fifteen years, so this comes from a place of love and respect. Beyond roughly 150k LoC you start to run into difficulties keeping everything straight over time, especially if you use a lot of indirection or other magic. The aspects of the language that help you go fast when you're prototyping (is "RAD" still a thing? Rapid Application Development)…

from personal experience with mypy, the great thing about gradual typing in a dynamic language is that, well, it's gradual! when I want to do something extremely dynamic, there's no horrible reflection API in my way. but most of the time I can live happily inside the walled garden mypy provides.

I have adopted this attitude for personal projects & small companies, and it was mostly great.

There was at least 1 really large error that slipped into production because we were mocking an untyped service incorrectly (a mistyped property name), and the test passed, but prod exploded. It was embarrassing, and I certainly would have caught it with more mypy discipline, but overall the pros outweighed the cons.

At big companies that use mypy, however, this is problematic. If teams only define types for the straightforward parts of the system, then the types become less useful, especially as the company scales. From what I’ve seen, individual teams use an all-or-nothing approach with MyPy, so it’s unusual for an individual dev to sparsely type anything.

Re: Ask HN: Who regrets choosing Elixir?

#246
post #236

Earlier quoted context omitted.

This kind of sentiment come up every so often on HN and I'm just sick of it. Sure, programmers should strive to improve their craft, just like professionals in every industry. But there are plenty of ways to improve yourself and learning a new language is hardly the most effective choice (and in fact could be counterproductive).

How does learning a new way to think about a problem become counterproductive? Each language you learn gives you a new angle from which you can approach a problem. Is it counter productive to learn a second spoken language? I haven’t come across an argument against that, even learning a dead language like Latin or Ancient Greek has benefits.

Perhaps counterproductive is too strong a word, but there could definitely be problems in the short term. Programmers love to apply things they learned in their work, and taking a concept or pattern from language A and applying them to language B is a natural reaction. The most common culprits are monads and actors. Ergonomics (readability, cognitive cost, debugging, IDE support, etc) became afterthoughts in the midst of excitement, and the long term health of the codebase (and teammates) suffers.

I have made mistakes like that (introducing monads/future and making the team learn guava) and I still regret it. Its not to say futures are useless - there were a lot of async logic in the codebase and futures solve a real problem, but its not clear if the benefits outweigh the cost.

Re: Ask HN: Who regrets choosing Elixir?

#247

Earlier quoted context omitted.

Can you expand what you mean re: large projects in Python?

Yeah, thanks for asking. I've been a happy Python programmer for over fifteen years, so this comes from a place of love and respect. Beyond roughly 150k LoC you start to run into difficulties keeping everything straight over time, especially if you use a lot of indirection or other magic. The aspects of the language that help you go fast when you're prototyping (is "RAD" still a thing? Rapid Application Development)…

This is true of all dynamic languages. Rails codebases become a nightmare beyond a certain LOC. It’s taken a long time but now that we have languages with strong static typing but good type inference like Kotlin, Swift, Typescript etc the old fully dynamic languages are obsolete technology and will eventually be replaced.

Re: Ask HN: Who regrets choosing Elixir?

#248

Earlier quoted context omitted.

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 ecosys…

Though I prefer Scala the language, Kotlin is really nice and has pretty straightforward tooling (seriously why is sbt what I'm stuck with), as well as really awesome (unsurprisingly) Intellij support.

I may prefer Scala in theory but it seems to me that Kotlin would work better in practice. And my thinking has shifted to where I've started preferring languages that I prefer in practice in theory too.

Re: Ask HN: Who regrets choosing Elixir?

#249

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.

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…

Well, a Java developer isn't going to want to give up the JVM, their type safety, and great tooling, for a start.

I get being interested in Erlang if you're doing Python. But interested in doing Python as a Java dev? Probably not.

Re: Ask HN: Who regrets choosing Elixir?

#250
post #80

I work for a Ruby on Rails shop and we used Elixir for two projects about a year or two ago when it was getting a lot of good press. The first project was an API that was intended to serve as a middleman between a few legacy services. Basically the company that hired us was building a new JSON API but didn't want to rewrite all their old code and our job was to consume the output from their ugly legacy APIs and produ…

You experience pretty much match mine.

My boss really wanted to use Elixir. Our CTO said he could only if he could convince 3 senior engineers and one ops person to agree to work on and support it. So he flew a whole team of us to ElixirConf. He organized a hackathon team around it. We rewrote some non-critical some services in it. All on company time and money.

At the end, none of the engineers could sign off on using it professionally at the company. Elixir is a cool language and it was a fun learning experience, but it's such a shoddy abstraction over Erlang and that's not a pleasant language. The operational complexity is really high, and it didn't solve our problems better than our current core languages did. The ecosystem was also really lacking in unavoidable ways for us, which meant we spent more time developing libraries that would've existed in any other ecosystem than actually writing application logic.

Post reply on HN