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

291–300 of 340 posts

Re: Ask HN: Who regrets choosing Elixir?

#291

Post by kerkeslager »

takeda wrote: post #73
ed25519FUUU wrote: post #10

Earlier quoted context omitted.

> They lack static type checking, but I find that a thorough test suite catches most type errors anyway. Maybe ruby is different than python in this regard, but with python I see a lot of “assert isinstance(arg, dict)” in functions which would not be necessary with type checking. Feeding an unexpected type into a function, and having it carry on as normal, is really scary.

This still produces a runtime error, to make code maintainable you want to be able to check the types without having to run the program. The type annotations help with that, they allow to spot bugs in the code and make an IDE to correctly refactor code and provide autocomplete.

> This still produces a runtime error, to make code maintainable you want to be able to check the types without having to run the program.

I strongly disagree. There are plenty of ways to write maintainable code. Static types can help, but it's quite possible to write maintainable code in dynamically typed languages.

And, for the record, running unit tests doesn't require me to run the whole program.

And, even if I never explicitly test types (assert isinstance(foo, str) is an antipattern anyway), behavioral tests of my code will turn up most type errors.

The obsession with checking types at compile time rather than 30 seconds later while running the unit tests doesn't serve anyone.

Re: Ask HN: Who regrets choosing Elixir?

#292

Post by 0peth »

A language is a tool. You are right with your analysis about the 3rd party libraries, it will absolutely slow you down.

Elixir is an okay language at best, if you look at it in comparison with let's say Python:

1. It is not any safer than python 2. Not any faster than python 3. Abstracts away a lot of things away from you "magically" just like python 4. It is harder to read elixir cause you will have people writing all sorts of random macros.

Where Elixir is good: 1. Concurrency (Processes!) 2. Based on BEAM but you won't care for your simple API project and you shouldn't have to. 3. Other erlang goodness supervisors, otp etc.

Personally I detest Python, but you would be better off writing your app in Python cause using Elixir you have gained nothing much substantially but lost on all ecosystem and community support Python has gained in its long history.

As a sidenote, I hope you use a strongly typed language.

Re: Ask HN: Who regrets choosing Elixir?

#293

Post by kerkeslager »

pavel_lishin wrote: post #99
kerkeslager wrote: post #49

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…

> if you test all the behavior you care about, then you don't care if there are type errors, because they only occur in situations where you don't care. If I test all the situations I care about, the one situation I thought I didn't care about is going to fuck me in production.

If you test all the situations you care about and statically type check, the one situation you thought you didn't care about and that wasn't caught by the type checker is going to fuck you in production.

It's not useful to talk about a binary "bugs versus no bugs", because "no bugs" isn't plausible in most codebases.

It's also not useful to talk about "more bugs versus fewer bugs" because that's only part of the picture: the other parts of the picture are how much development effort was necessary to achieve the level of bugs you have, and whether the number of bugs you have, and when you have them, is acceptable.

If it's a life or death application where any bugs at runtime are unacceptable, then of course we want static types, but static types aren't enough: I'd also want a theorem prover, fuzzer, a large number of human testers, and a bunch of other things that require way too much effort to be useful in an average software project.

The vast majority of software projects, runtime bugs are acceptable as long as they don't lose data, cause downtime, or expose private information. If you catch these bugs during unit testing instead of 30 seconds earlier at compile time, that's fine. Static types might catch a few more bugs, but it is very much not in evidence that the level of effort involved is lower than equivalent unit testing in situations where reliability requirements are typical.

Re: Ask HN: Who regrets choosing Elixir?

#294

Post by JohnBooty »

phtrivier wrote: post #271
theonething wrote: post #254

Earlier quoted context omitted.

> I wind up having 10 different files open at a time in my text editor so I can see what various methods are expecting. Huh, I thought this was normal. Not everyone does this?

No. Something like "intellisense" has existed for decades. It relies on the static type system to "guess" what functions make sense in a given context. You Ctrl-Space your way to writing the code , ans get Brain cycles back to actually think about stuff.

Yes. This is the scenario in which I truly miss a good old-fashioned static type system and a big ol' intelligent IDE. Specifically, because of what you said: it frees up brain cycles for me to think about the real problems.

My highly subjective belief and experience is that Ruby and its ecosystem has enough other perks to make up for this loss. But, I definitely accept others might feel otherwise.

Re: Ask HN: Who regrets choosing Elixir?

#295

Post by kazinator »

dreamcompiler wrote: post #279
enz wrote: post #261

Earlier quoted context omitted.

> 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. They can put only "Python" on their résumés, right?

One would think they could just avoid mentioning Lisp. I still don't understand their reasoning.

The reasoning is simple: if someone thinks something would look bad on their resume, they probably don't want to spend time on it, either.

For example, I wouldn't want PHP or Fortran on my resume, and, consistently with that, I avoid them. I don't have an opportunity to actively avoid them, but that defense mechanism would leap into action, if called upon.

However, I know a thing or two about these; I'm not simply applying "meme-based reasoning".

Re: Ask HN: Who regrets choosing Elixir?

#296

Post by _t0du »

kerkeslager wrote: post #283
_t0du wrote: post #189

Earlier quoted context omitted.

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…

> 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. Maybe someone is saying that, but I didn't say that. My question isn't whether you can test enough to catch all bugs. My question is whether time spe…

> My question isn't whether you can test enough to catch all bugs. My question is whether time spent wrangling types gets you more value than time spent writing tests.

Yes, by a tremendous amount, in my experience.

> Are they? How so?

Tests are only as good as the person writing them. I could see a model working where the person that wrote the code isn't the person that writes the test, but that's definitely not how most development orgs work. If a dev is good enough/capable of writing comprehensive enough tests to accurately test the correctness of their code, that's great, but almost none are (I say almost because I actually mean "actually none" but am leaving room for my own error). If you're an average dev, you'll write average tests (neither of these are insults), but that means you still won't catch everything (by a lot).

I think another comment of yours on my posts actually summarizes the core disconnect between your thinking and mine.

> But in the vast majority of modern software, it mostly just matters that you catch and fix bugs quickly--whether you catch those bugs at compile time or runtime is usually not as critical.

I couldn't possibly disagree more with this statement.

Re: Ask HN: Who regrets choosing Elixir?

#297

Post by crazydoggers »

eropple wrote: post #95
crazydoggers wrote: post #35

Earlier quoted context omitted.

At the end of the day, it’s about can you deliver that project on time and with limited bugs. Everyone’s experience will be different, so maybe accept that different programmers work better with different systems. I can tell you with 20 years of programming experience that static type systems don’t make me more efficient... and I’ve used them all. And just because I can see the reply coming, I’ve worked with programm…

Put frankly: I’m not going to “accept” that because I’ve watched programmers with twenty years of experience (woe betide me and my mere thirteen!) tank projects through this kind of arrogance. And it is arrogance, to dress up the limitations of a meatbag as a positive against the tireless specificity of the machines. Then those meatbags realize that they have to refactor their code and the world ends. The computer is…

Wow... talk about arrogance! I think you’re unclear about the definition of that word. I’m suggesting that developers have choice in what works for a given project. It’s arrogance to think only your choice is correct.

You’re the type of programmer that tanks projects because of that arrogance and an inability to work with other “meatbags”. Maybe for you it’s all about code perfection, but for the rest of humanity it’s about making a product that works, solves a problem, makes the world a better place, or earns a profit.

Too bad my suckers bet has paid off with success and money. Best of luck with your attitude in life.

Guess these Github meatbags have made a suckers bet on a dynamic language. No way they could be efficient or successful maintaining or refactoring a project of that scale. (Yes that’s sarcasm for the sarcastically impaired)

https://github.blog/2019-09-09-running-github-on-rails-6-0/

Re: Ask HN: Who regrets choosing Elixir?

#298

Post by mistyfud »

I've been using Elixir for three years in a production setting with a small team of engineers. I still love the language, the community, and everything it has taught me as an engineer. However, there are real downsides to moving forward with Elixir:

- If your engineers are used to the Ruby, JS, Python etc. ecosystems of finding a library for everything, they may become frustrated with the smaller Elixir ecosystem. In my experience, this is actually fine because it means you have fewer external dependencies to wrangle.

- Differences between compile-time and run-time configuration is a foot gun. We ended up moving almost everything to run-time configuration, which is not what you see recommended by many libraries and examples. This is slowly changing however.

- Deployment is a bit unique, and working with building releases can be confusing for those used to deploying dynamic languages that are not compiled.

- Functional programming requires unlearning many OOP best practices. This can slow down engineers new to the language.

A lot of these issues IMO comes from how Elixir was initially marketed as a "fast Ruby" and Phoneix "fast Rails". Once you get past the syntactical similarities you realize the semantics are very, very different. Elixir is much closer to Erlang and Clojure than it is to Ruby.

Elixir is an excellent language for motivated engineers solving novel problems. If you are building a standard CRUD app, I think you will find more success with Rails or Django in 2020.

Re: Ask HN: Who regrets choosing Elixir?

#299

Post by as-j »

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.

> If you have $200k "python engineers" on the payroll who wouldn't jump at the opportunity to do some additional Erlang

Ah, sure they might be willing, but as a lead I'm not willing to invest in it.

1. I'm not sure I want someone who's got 4 weeks of experience in a language working on system critical infrastructure. Pick your time, does it take 6mo?

2. They have existing work, learning and working on an entire new language _AND_ new project is a huge task. Especially for non-trivial projects.

We could, but in our case it was a better engineering decision was to retire the old system and move on.

Re: Ask HN: Who regrets choosing Elixir?

#300

Post by as-j »

PragmaticPulp wrote: post #119
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…

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…

You sure we don't work at the same place? :)

Hiring is nearly impossible, come support our legacy system, and what ever you do, don't introduce Erlang into any other part of the company. Why? We feel burnt on this one project, and god forbid we get any deeper than we are now. What this isn't appealing?

Post reply on HN