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

Re: Ask HN: Who regrets choosing Elixir?

#31

Post by _t0du » Sat, May 23, 2020, 4:45 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…

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 should still have tests, but IMO tests that are just checking that a string is a string are A.) Time consuming, and B.) largely useless beyond type validation.

Re: Ask HN: Who regrets choosing Elixir?

#32

Post by ianamartin » Sat, May 23, 2020, 4:45 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.

Really? You're going to go with "most languages implement static typing"?

That seems like a bold statement.

Re: Ask HN: Who regrets choosing Elixir?

#33

Post by out_of_protocol » Sat, May 23, 2020, 4:46 PM UTC

treis wrote: post #21

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…

How close does it come to matching the Ruby/rails gem ecosystem?

IMO

+ Phoenix _better_ than Rails, which is very surprising

- less packages available, though almost everything covered by at least one package. ( hex.pm vs rubygems.org )

Re: Ask HN: Who regrets choosing Elixir?

#34

Post by mapcars » Sat, May 23, 2020, 4:46 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…

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

What exactly dialyzer type checking lacks compared to static type systems?

Re: Ask HN: Who regrets choosing Elixir?

#35

Post by crazydoggers » Sat, May 23, 2020, 4:46 PM UTC

eropple wrote: post #29

crazydoggers wrote: post #20

Earlier quoted context omitted.

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…

This may sound like a dismissal, and in a way it is, but: get a better type system, and really understand it. The kinds of logic problems that you describe can be greatly limited—without wasting one’s time —with a more expressive type system. This is one of the reasons I lean so heavily on TypeScript today; I can express my data in the forms it actually should be expressed in, pretty easily, and use that to constrain…

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 programmers using static type checking that have turned out horrible bug ridden code. It’s just not a cure all.

So can we please accept each other’s choices about type systems. “Can’t we all just get along”

Ultimately if it matters to you, then choose what works. But don't assume or try and tell everyone it makes one language definitely better than the other, because things aren’t that simple.

Re: Ask HN: Who regrets choosing Elixir?

#36

Post by JohnBooty » Sat, May 23, 2020, 4:47 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…

    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.

This has not been my experience!

I've been writing Ruby full-time for about six years (including one of the largest Rails apps in the world) and I don't find this particular aspect of Ruby to be a problem whatsoever relative to statically-typed language.

Ruby is famously easy to write tests for. Creating mocks in a dynamic language is such a breeze. There are plenty of problems with Ruby but an increased test suite burden is NOT one of them. "Confident Ruby" by Avdi Grimm is a great read in this vein; not about testing specifically but writing confident Ruby code in general.

Part of it is simple, human-friendly code hygiene. Give your arguments descriptive names and use keyword params when possible. If you have a method:

    foo(user_name:, height_cm:)

...then you'd really have to be asleep at the wheel to write something like this elsewhere in your code:

    foo(user_name: 157, height_cm: "Smith")

And so you don't need to write your code or your tests with any real extra level of paranoia. If somebody does pass a string to `height_cm:` it will return a runtime exception, just like it should.

Of course, I do get type errors all the time in Ruby, but that's when I'm parsing JSON or something and that's generally not something static typing's gonna help you with anyway.

Now... there ARE places where I miss strong typing in Ruby.

One, I miss having extremely intelligent IDEs like you can have with Java or C#. I absolutely loved Visual Studio and Resharper in the C# world. The amount of reasoning it can do about your code and the assistance it can give you is absolutely bonkers.

Two, obviously, there is a price in runtime execution speed and RAM usage to be paid for dynamic typing. I don't find raw execution speed to be much of a bottleneck in a Ruby app because Postgres/Redis/etc are doing all my heavy lifting anyway. RAM usage and app startup times with large applications is more of a real-world issue.

Re: Ask HN: Who regrets choosing Elixir?

#37

Post by [deleted] » Sat, May 23, 2020, 4:47 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…

[deleted]

Re: Ask HN: Who regrets choosing Elixir?

#38

Post by tomc1985 » Sat, May 23, 2020, 4:49 PM UTC

tonyarkles wrote: post #25

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…

That seems odd given that the BEAM was designed for reliable real-time telephone switching

Re: Ask HN: Who regrets choosing Elixir?

#39

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

tonyarkles wrote: post #25

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…

Just curious -- were you using Nerves[0] for the drone flight controller?

[0]: https://github.com/nerves-project/nerves

Re: Ask HN: Who regrets choosing Elixir?

#40

Post by mapcars » Sat, May 23, 2020, 4:50 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…

Erm, you can setup dialyzer to be as strict as possible. This might not catch all the errors because of the nature of messages, but this is a pretty small part of a system usually and can be covered by tests.

>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

Can you give me some examples?