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

11–20 of 340 posts

Re: Ask HN: Who regrets choosing Elixir?

#11

Post by brenden2 »

michaelcampbell wrote: post #8
brenden2 wrote: post #5

Earlier quoted context omitted.

I'm not a genius, but I found the opposite to be true. Go and Python seem non-intuitive to me, whereas Elixir felt natural and easy to grok.

I feel there are dimensions to "ease" and Go and Elixir went different directions on them. Go is very "simple" in that you can look at it and generally easily understand what it's doing . Elixir and its ilk tends to make it easy to do what you want to do . In Go you have to re-write things over and over because the abstractions are low, but they're easy to do. In Elixir you can use the built in libs/abstractions, but…

Go is a language that always felt painfully obtuse to me. It always seemed hard to do basic things. To be fair I've only used it begrudgingly and never on my own work. The only thing I ever enjoyed about Go was the fast compilation.

Re: Ask HN: Who regrets choosing Elixir?

#12

Post by brenden2 »

nojito wrote: post #9
brenden2 wrote: post #5

Earlier quoted context omitted.

I'm not a genius, but I found the opposite to be true. Go and Python seem non-intuitive to me, whereas Elixir felt natural and easy to grok.

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

Maybe, but that's hasn't been my experience. The Erlang monitoring/debugging tools that you get out of the box are pretty good.

Re: Ask HN: Who regrets choosing Elixir?

#13

Post by james-mcelwain »

kerkeslager wrote: post #4
59nadir wrote: post #2

I've used Elixir since 2015 and I find Elixir to be unusable for any kind of intelligent domain modelling, but that's primarily because it's dynamically typed and has no concept of real sum types, etc., not necessarily because it's any worse at this than Ruby. 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 t…

I'm a bit confused by this comment. Having used both Ruby and Elixir (more Ruby) both languages have type systems which are quite capable of modeling domains[1]. They lack static type checking , but I find that a thorough test suite catches most type errors anyway. And while creating a thorough test suite is costly, static types in most languages [2] don't reduce this burden much: there isn't an alternative to thorou…

When people refer to "typing", it is almost certainly reasonable to assume they are referring to static typing, as implemented by most languages. I don't think this should be confusing.

Specs/contracts are cool but ultimately don't afford the same kind of descriptive and expressive power that a static type system does.

> static types in most languages[2] don't reduce this burden much: there isn't an alternative to thorough testing.

However, there definitely is a burden about how much testing you have to write. I generally don't want to have to test every branch of my program to make sure a string doesn't slip through where an int should be or that variables are initialized and not null, etc.

Re: Ask HN: Who regrets choosing Elixir?

#14

Post by 59nadir »

kerkeslager wrote: post #4
59nadir wrote: post #2

I've used Elixir since 2015 and I find Elixir to be unusable for any kind of intelligent domain modelling, but that's primarily because it's dynamically typed and has no concept of real sum types, etc., not necessarily because it's any worse at this than Ruby. 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 t…

I'm a bit confused by this comment. Having used both Ruby and Elixir (more Ruby) both languages have type systems which are quite capable of modeling domains[1]. They lack static type checking , but I find that a thorough test suite catches most type errors anyway. And while creating a thorough test suite is costly, static types in most languages [2] don't reduce this burden much: there isn't an alternative to thorou…

> I'm a bit confused by this comment. Having used both Ruby and Elixir (more Ruby) both languages have type systems which are quite capable of modeling domains[1]. They lack static type checking, but I find that a thorough test suite catches most type errors anyway.

Most of this is incorrect, both for and against your argument. Elixir has a very incapable and incomplete type system. It's optional but can be checked via `dialyzer` but never confidently and exhaustively checked because `dialyzer` will sometimes plain not work, sometimes be foiled by bad library specs and sometimes fall back to "Everything must be OK because I can't prove this incorrect".

All in all it's not a useful substitute for a real type system used to model things.

Type specs aren't useful for domain modelling but serve mostly as extra documentation more than anything.

Testing is important no matter what language you use (except maybe dependently typed ones, I don't know?). It's not a substitute for a good type system. Even disregarding type-directed property tests with automatically generated test cases, there's a lot of value to be had in tests that actually just test logic, not basic types.

Re: Ask HN: Who regrets choosing Elixir?

#15

Post by neilwilson »

kerkeslager wrote: post #4
59nadir wrote: post #2

I've used Elixir since 2015 and I find Elixir to be unusable for any kind of intelligent domain modelling, but that's primarily because it's dynamically typed and has no concept of real sum types, etc., not necessarily because it's any worse at this than Ruby. 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 t…

I'm a bit confused by this comment. Having used both Ruby and Elixir (more Ruby) both languages have type systems which are quite capable of modeling domains[1]. They lack static type checking , but I find that a thorough test suite catches most type errors anyway. And while creating a thorough test suite is costly, static types in most languages [2] don't reduce this burden much: there isn't an alternative to thorou…

Type systems are really a set of comprehensive tests you don't have to write yourself that cover a subset of the things you need to test for.

Static languages fell out of favour last time round the dynamic/static merry-go-round because the typing started to get in the way. You ended up writing more type boilerplate than actual code - and not breaking your methods/functions down into smaller functions to avoid having to write out even more type boilerplate.

I often wonder whether type annotations that allow a processor to generate tests that can integrate into your test suite would be a useful thing to have. Sort of like a C preprocessor.

Then you could add ML type headers to Elixir functions and get a set of ExUnit tests back.

Re: Ask HN: Who regrets choosing Elixir?

#16

Post by neilwilson »

ed25519FUUU wrote: post #10
kerkeslager wrote: post #4

Earlier quoted context omitted.

I'm a bit confused by this comment. Having used both Ruby and Elixir (more Ruby) both languages have type systems which are quite capable of modeling domains[1]. They lack static type checking , but I find that a thorough test suite catches most type errors anyway. And while creating a thorough test suite is costly, static types in most languages [2] don't reduce this burden much: there isn't an alternative to thorou…

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

"Feeding an unexpected type into a function, and having it carry on as normal, is really scary."

That is how duck typing works. Generally you shouldn't use "is instance" but more use a set of "callable" checks to make sure the structure has the required functions.

Things like Go Interface types are, of course, a formalisation of duck typing and is what has helped static typing come back into fashion.

Re: Ask HN: Who regrets choosing Elixir?

#17

Post by 59nadir »

neilwilson wrote: post #15
kerkeslager wrote: post #4

Earlier quoted context omitted.

I'm a bit confused by this comment. Having used both Ruby and Elixir (more Ruby) both languages have type systems which are quite capable of modeling domains[1]. They lack static type checking , but I find that a thorough test suite catches most type errors anyway. And while creating a thorough test suite is costly, static types in most languages [2] don't reduce this burden much: there isn't an alternative to thorou…

Type systems are really a set of comprehensive tests you don't have to write yourself that cover a subset of the things you need to test for. Static languages fell out of favour last time round the dynamic/static merry-go-round because the typing started to get in the way. You ended up writing more type boilerplate than actual code - and not breaking your methods/functions down into smaller functions to avoid having…

> I often wonder whether type annotations that allow a processor to generate tests that can integrate into your test suite would be a useful thing to have. Sort of like a C preprocessor.

We already have this in things like `Arbitrary` type classes, `QuickCheck`, `Hedgehog`, etc.. Hundreds of automatic test cases generated so that you don't focus only on "I thought of these 5 test cases" type of testing.

There is a PureScript compiler called `purerl` for the BEAM which can be used to write BEAM code in a ML derivative. It works and I personally would use it if I had to deliver BEAM code next week. For the most part it's the answer to the "you can only write BEAM code in bad languages" issue.

Re: Ask HN: Who regrets choosing Elixir?

#18

Post by triskweline »

Our Ruby / Rails agency tried implementing a project in Elixir. After 3 weeks we stopped the experiment and re-did everything in Ruby.

What stopped us was not so much the lack of libraries, but programming ergonomics. E.g. when using keyword lists for function options, callers need to pass the keywords in the exact same order. Also mocking was difficult in tests.

Elixir is a great project with a friendly community, it just didn't work for us. YMMV so by all means try it out if you're interested!

Re: Ask HN: Who regrets choosing Elixir?

#19

Post by dnautics »

nojito wrote: post #9
brenden2 wrote: post #5

Earlier quoted context omitted.

I'm not a genius, but I found the opposite to be true. Go and Python seem non-intuitive to me, whereas Elixir felt natural and easy to grok.

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 next biggest was elixir_ls, which had used typespec analysis and highlighted the error for me in my ide.

Re: Ask HN: Who regrets choosing Elixir?

#20

Post by crazydoggers »

kerkeslager wrote: post #4
59nadir wrote: post #2

I've used Elixir since 2015 and I find Elixir to be unusable for any kind of intelligent domain modelling, but that's primarily because it's dynamically typed and has no concept of real sum types, etc., not necessarily because it's any worse at this than Ruby. 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 t…

I'm a bit confused by this comment. Having used both Ruby and Elixir (more Ruby) both languages have type systems which are quite capable of modeling domains[1]. They lack static type checking , but I find that a thorough test suite catches most type errors anyway. And while creating a thorough test suite is costly, static types in most languages [2] don't reduce this burden much: there isn't an alternative to thorou…

I agree, but I think it’s a common misconception. Having used many languages, both for very large and small projects, languages with compile time static type checking and run time dynamic type checking, I find it’s easy to rely too much on static type checking. I think what happens for a lot of programmers is that static type checking uncovers a lot of basic bugs and typos, so they feel like it has a major advantage over dynamic. The problem though is that it’s a false sense of security because you’ll always end up with complex logic bugs that no compile system is ever going to catch, so you end up needing test suites anyway.

Static type checking does have some advantages, it can ease some of the low level testing burden. For instance, using a tool like Dialyxir (dialyzer) is helpful in elixir to give you that extra security of static type checking.

For me it’s always ended up being that I’m more productive with dynamically typed languages and the flexibility they offer.

Post reply on HN