Ask HN: Who regrets choosing Elixir? • Hacker News Board

Re: Ask HN: Who regrets choosing Elixir?

#41

Post by dnautics » Sat, May 23, 2020, 4:50 PM UTC

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…

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

Re: Ask HN: Who regrets choosing Elixir?

#42

Post by regulation_d » Sat, May 23, 2020, 4:51 PM UTC

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.

I rarely find that I have to "go into Erlang" but it is true that Erlang error messages can be a bit obtuse initially.

Re: Ask HN: Who regrets choosing Elixir?

#43

Post by AlchemistCamp » Sat, May 23, 2020, 4:52 PM UTC

dnautics wrote: post #41

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…

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

Re: Ask HN: Who regrets choosing Elixir?

#44

Post by kerkeslager » Sat, May 23, 2020, 4:52 PM UTC

james-mcelwain wrote: post #13

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…

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

> 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 that's a reasonable assumption at all. Even if, as you assert, the average person doesn't understand that types exist in dynamically-typed languages, I don't think that means I have to conform to common misconceptions.

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

True, but not what I was talking about.

Could you explain what descriptive and expressive power is missing here?

    class Square(Rectangle):
        def __init__(self, side_length):
            self.side_length = side_length

        @property
        def height(self):
            return self.side_length

        @property
        def width(self):
            return self.side_length

Re: Ask HN: Who regrets choosing Elixir?

#45

Post by regulation_d » Sat, May 23, 2020, 4:53 PM UTC

flaque wrote: post #3

One counter point to elixir is that there's a significant learning wall to onboard new developers, more so than simpler a language like Go or Python.

To me learning Elixir felt like a two stage process: learning the language and learning the OTP.

The language itself is pretty small and I felt like the first stage was pretty easy.

Learning the OTP is a much bigger challenge.

At the same time, I think you can gain a lot of the benefits of Elixir and the BEAM without needing to be an OTP expert, because frameworks like Phoenix leverage it for you.

In my experience, things like pattern matching and immutable data really contribute to a more maintainable code base, whether you find you need the actor model or not.

Re: Ask HN: Who regrets choosing Elixir?

#46

Post by mapcars » Sat, May 23, 2020, 4:53 PM UTC

brenden2 wrote: post #7

I've done a fair bit of both Ruby and Elixir. My impression is that Elixir leaves a lot of the legacy cruft behind, and it has a much smaller language feature set (which is IMO big bonus). The language is pretty easy to grasp quickly as a result. There isn't much in the way of quirky syntax or backward compatibility weirdness. Probably the biggest advantage of Elixir over Ruby is the runtime. The Erlang VM has proper…

>somewhat slow runtime (compared to C, Java, Rust, Go, etc).

It's only slow if you are comparing a single-threaded operations, Erlang VM is designed to scale horizontally, not to be fast with one thread.

Re: Ask HN: Who regrets choosing Elixir?

#47

Post by wnevets » Sat, May 23, 2020, 4:53 PM UTC

I've found elixir easy to write but a pain to read, especially when it comes other people's code.

Elixir is also dynamic but with annotations that gives the illusion of types. It's really the worst of both worlds.

Re: Ask HN: Who regrets choosing Elixir?

#48

Post by 59nadir » Sat, May 23, 2020, 4:56 PM UTC

triskweline wrote: post #18

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, i…

> E.g. when using keyword lists for function options, callers need to pass the keywords in the exact same order.

This would've been fixed by creating a map from the passed in list, which would remove the order dependency but still keep the ergonomics of a keyword list, or just querying the keyword-list with `Keyword.*` functions. Not that big of an issue, to be honest, and not a showstopper. There are much bigger issues with the language, but Ruby doesn't offer any upsides in those cases either.

Re: Ask HN: Who regrets choosing Elixir?

#49

Post by kerkeslager » Sat, May 23, 2020, 4:56 PM UTC

_t0du wrote: post #31

james-mcelwain wrote: post #13

Earlier quoted context omitted.

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

I see that language parroted all the time - "With thorough enough testing a dynamic language shouldn't be a problem", and I have never understood it. Arguing to build what is essentially a build-time type checker in the form of automated tests seems twice as cumbersome for half the benefit. Instead of building tests that check each branch of a program's types, why not use a language that forbids dynamic typing? You s…

> 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 occur in situations where you don't care.

Re: Ask HN: Who regrets choosing Elixir?

#50

Post by kerkeslager » Sat, May 23, 2020, 4:57 PM UTC

59nadir wrote: post #14

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…

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

Modeling your domain using types and checking your types are two different things.

Could you explain where you think the Elixir type system falls short for modeling domains? Your post only gives examples of problems with type checking.