[keithnz]

seems ironic that critics were saying, it needs typing, and all the elixir fans were saying you don't need typing, you don't get bugs related to typing because elixir is somehow magic, now they get typing and it finds bugs for them.... but you said you didn't need that to prevent bugs? But good to see! I spent a bunch of time trying out Elixir a while back, I enjoyed it, but just didn't agree with the lack of types.

[pdpi]

> you don't get bugs related to typing because elixir is somehow magic,

I've never followed Elixir particularly closely, but what I saw in some Erlang discussions was different. Discourse there was that you need to gracefully handle failure anyhow, so type errors can (should?) just get handled by the failure recovery machinery you're supposed to have anyhow. I disagree with that point of view, but it's much more defensible than "$LANGUAGE is magic".

[aeonfox]

OP might be referring to Jose Valim's 2023 ElixirConf talk where he's explaining why Elixir should go down the path of types.

He gives a lot more nuanced take than 'types are useless', which is more like 'types are less useful than people think in the context of Elixir development'. (Which makes sense because he's in the middle of implementing a type system for Elixir.)

https://youtu.be/giYbq4HmfGA?t=571

[bonesss]

> types are less useful than people think in the context of Elixir development

With no insights at all into Elixir this sounds like a reasoned and defensible, if not outright correct, position.

The proposition I'm working with is "types are more useful than people think in managing a horde of degenerate short-cut taking co-workers whose failures I will be blamed for openly and quietly regardless of actual fault". Gradual typing is an interesting and appealing compromise, I'm gonna have to give Elixir a serious try.

[abrookewood]

Yes, that is a great talk. He really does an admirable job of exploring all of the reasons why people think that they want a typed language and concludes many (but not all) are not that helpful.

[bad_haircut72]

you succumb to the fallacy that because the compiler let it through, the code wont have any error - the erlang mentality says that the compiler/CPU/everything has errors, how do you handle errors in the general sense

[pdpi]

I'm not succumbing to any such fallacy.

Compile-time checks don't obviate the need for runtime error handling, and I love the robustness of Erlang's runtime error handling. However, that doesn't change the fact that we should be catching and handling errors as early as possible, and there's a whole bunch of logic errors that you can easily catch at compile time.

[brightball]

It’s not so much language magic as it is “clustering preparedness” IMO.

Since any node in a cluster can be updated at any time and Elixir/Erlang code on the BEAM is designed make it easy to pass function calls to other nodes you don’t have any way of guaranteeing the Type contract between nodes. Types create a sort of false confidence in those situations where pattern matching handles everything very cleanly.

Example: You may not need to match on a full type, just a specific element name in a hash.

When people say Elixir doesn’t need types it’s not claiming that types are without value. It’s a claim that the mechanisms that already exist are enough without the added complexity.

I appreciate the gradual approach so that we can lean on both.

[munificent]

This is the Goomba fallacy.

https://en.wiktionary.org/wiki/Goomba_fallacy

[chabska]

The way to see if it's actually a fallacy, look for in-fighting between the two supposedly opposing camps of goombas.

I've seen internet commenters say China is overstating its economic numbers to look more intimidating, and that China is understating its economic numbers to receive more favourable WTO trading terms, but somehow these two camps never called each other out, which makes me think they're the same people believing that China is both overstating and understating.

[IshKebab]

It's the circle of life. Dynamically typed language has fans. Other people correctly say that it would be a lot more useful with static types. Fans take this personally and say it doesn't need static types because (they aren't useful anyway/it goes against the spirit of the language/it's only a scripting language anyway/you can just use a debugger/static types hurt productivity/etc. etc.)

Then eventually they add static types. Happened to Python, JavaScript, Ruby... I'm sure there are more.

[awesome_dude]

For my $0.02 - it depends where you want to put the onus

Statically typed languages put the onus on the caller to transform the data into the shape(s) required.

Dynamically typed languages put the onus on the called to handle anything.

That is, in a dynamically typed environment your function has to defensively code for every possible type it could be handed.

[IshKebab]

Nobody writes dynamically typed functions that can be called with any possible type.

It's not about that at all. Static types give you errors reliably at compile time instead of randomly at runtime, better documentation of what the code expects (people writing dynamically typed languages eventually resort to type comments), working IDE support, reliable refactoring and better code, all of which results in faster development.

The cost is a more complex language, occasionally difficult-to-write types, and very occasionally impossible-to-write types. But those are very very minor in comparison to the pros.

[OkayPhysicist]

> (people writing dynamically typed languages eventually resort to type comments)

This has never been an issue in Elixir, because instead of a comment, you'd just improve the pattern matching in the function definition.

    def blah(%{students: [%{firstname: firstname, lastname: lastname}|[]], count: cnt}) when is_int(cnt):
      fullname = firstname <> lastname

Is a valid function declaration, which specifies that blah takes a dictionary that contains at least 2 keys, :count, who's value is an integer, and :students, who's value is a length-1 list who's first element is a dictionary that contains the keys :firstname and :lastname

[awesome_dude]

is_int is doing the work of a type checker?

I mean I'm not an Elixer guy (not at all) so it's a bit opaque to me how that's not an enforcement of specific types (albeit the firstname, lastname can be anything?)

Once we get into the function itself, if two incompatible types, say a string and a filehandle.. (just random attempt, you may, if you choose, point to why the two types must have some alignment), what happens - the function dies?

That's my core issue with dynamic typing, you might argue that the function's explosion has a restricted blast radius, but that's not the point, the point is that the function was called, and was unable to compute whatever, and that's a bug.

[dpatterbee]

In elixir, processes (these are Erlang "processes", not OS processes) are designed to fail when they encounter errors, and the supervising process will restart it according to various rules you can configure. This isn't dissimilar to how kubernetes restarts jobs when they fail, but at a more fine-grained level.

It's actually intended that your function doesn't try too hard to validate it's input types, and just that it will malfunction and crash when it gets something it doesn't know how to handle, because the supervision tree will rescue it and your program can continue, albeit without whatever input caused the malfunction.

This obviously isn't ideal for many types of software, but for complex backend servers and other long-running operations it works really well.

Of course this is not a guarantee to eliminate bugs, but it's a factor that reduces them more than you'd think when coming from a different programming paradigm.

[isityettime]

How did Elixir manage to attach static type checking to a language after the fact without drastically revising the type system or incurring runtime validation costs? I don't know Elixir, but I have some impression that the BEAM's famous qualities played a role: immutability, "let it crash" philosophy, no inheritance malarkey, etc. Elixir itself had to have a type system that was already relatively orderly for it to be possible to write the relevant proofs way after the fact, right?

Maybe the things that made this transition feasible are the "magic" that used to make people say "Elixir doesn't really need types". Maybe what they meant was something like "Elixir is an orderly language in a bunch of ways that makes the lack of static typing less painful to me than usual".

And I guess we'll see how much people get out of this when they add type annotations later. Maybe the value add will be big after all, and then they'll really be proven wrong. But I can sort of imagine how the apparent contradiction fits together.

[sodapopcan]

It has heavy reliance on pattern matching. In fact, `=` isn't even technically assignment, it's the match operator. Assignment is more of a consequence of matching (though it doesn't have to happen, eg: `1 = 1`). All that to say, most Elixir codebases are written with types in mind, and many are written with pattern matching that would cause a type error at runtime. The new type system just builds off that and moves these errors to compile time (well, not JUST that but ya, this is just meant to be a quick answer).

[igsomething]

One important thing that is often not mentioned is the lack of operator overloading. In Elixir if you have "a + b" it means "a" and "b" must be numbers for the code to succeed, which narrows down the possibilities significantly. Compare that to Python, where "a + b" applies to numbers, string concatenation, and any object that implements the __add__ or __radd__ magic methods, it becomes a nightmare to type.

[h14h]

I don't think anyone serious in the Elixir community ever said "you don't get bugs". Maybe you do get fewer bugs as a result of immutability and pattern matching features, but "no bugs" is definitely not a promise I've ever heard.

The thing you DO hear a lot, though, is that you don't need to worry about bugs nearly as much as you do in other languages. But that's not because Elixir is "magic", rather, it comes from Elixir's runtime (Erlang/BEAM) providing best-in-class fault tolerance primitives like lightweight process isolation and supervision trees.

In practice that means the blast radius of bugs is generally tiny and any resulting crashed processes are often recoverable. The phrase you often hear is "let it crash", since the effort that goes into exhaustive defensive programming is usually more costly than the bugs you'd be trying to prevent.

[Xeronate]

It was the same thing with javascript/typescript and python. Sometimes you just have to let people think what they want.

[pjmlp]

The irony is that dynamic languages that predated them had optional typing.

BASIC, Smalltalk vs Strongtalk, Common Lisp, Dylan

It is the eternal September.

[jeremyjh]

Elixir predates set-theoretic types. Simon Marlow took a solid crack at typed Erlang 30+ years ago and couldn’t make it work and preserve what Erlang is. 9 years later Success Typings was published and Dialyzer happened. Not the best, but far better than what any other dynamic language had at that time, and Elixir had that available from the beginning.

So it is possible new theory was actually needed to preserve everything that was judged more valuable than types.

[pjmlp]

Fair enough, however given past experiences, there is probably value designing dynamic languages with optional typing from day one.

In any case, most of these questions are starting to become less relevant as we switch to having robots doing the programming instead.

Now the question is how to typecheck natural languages.

[jeremyjh]

I can’t swear I’ve never seen that claim - but I can’t remember seeing it if I ever did and certainly it would be a tiny minority position. The actual con arguments are basically “it is nice but has costs, maybe those don’t all get a good return”.

It’s possible that position was correct before set-theoretic type theory was developed.

[mrcwinn]

Please share that conversation you reference where the community said Elixir doesn’t need types because it is magic.

[zuzululu]

I think Elixir is interesting and there is real value but some stuff being sold as "all these libs/packages that haven't had any updates for over a year is fine because Elixir" I just don't buy it

and to that point around typing feels like the same wish-washy hand waving from the community that is very off putting

BEAM has genuine use cases but its not as wide as its made to believe. There are very good places where that is a perfect fit but it simply cannot upend Typescript.

Elixir feels very similar to how Clojure started getting traction and then ultimately forgotten apart from its die hard fans, I'm not saying Elixir will go the same way but seems very hard for something new and bold to replace what is popular and boring.

I do want Elixir to succeed (also Clojure as well and I advocated for it for a bit) but the low number of jobs still puts it in similar proximity to Clojure but BEAM I think would still provide uplift where Clojure simply could not

[josevalim]

> some stuff being sold as "all these libs/packages that haven't had any updates for over a year is fine because Elixir" I just don't buy it

I maintain more than 20 packages and, except for the major ones, like Phoenix and Ecto, they haven't been updated in more than a year and yes, they are all fine.

The language has been extremely stable. There has been almost no breaking changes in over a decade. Case in point: we introduced a whole gradual type system without making any changes to the language surface! The language is still on v1.x!

[jeremyjh]

So you prefer language communities where libraries have a constant stream of fixes, new breaking change releases every six months and entirely new framework ecosystems ascending every three years?

[hosh]

Not to mention language communities with constant supply chain attacks because its standard library story is poor, and everyone keeps reinventing new, often half-baked solutions?

Or even that, the very same ecosystem congratulates themselves on the typing system but still relies on linters because the language and runtime themselves allow whole categories of dumb ideas to be written?

[zuzululu]

Yes because it addresses security vulnerabilities and remains competitive.

You think all software breaks every 6 months, what happened Im curious

[dqv]

You can buy it if you use discernment. Obviously you'll run into compatibility issues in certain situations - like you aren't going to be able to use a library coupled to Phoenix 1.3 functionality in a Phoenix 1.8 project, but I continue to be surprised at how I can add a package like https://hex.pm/packages/deep_merge, which is 6 years old and it works just fine.

[arcanemachiner]

Phoenix is the exception to the usual rule. It's the only Elixir package where I've encountered substantial friction during upgrades.

Unfortunate, since it's one of the flagship Elixir packages, but I think the upgrades are worth the trouble. Better to improve something than to leave it broken solely for the sake of legacy compatibility IMO.

[NuclearPM]

Why would packages need to be updated?

[globular-toast]

Not really a contradiction. You don't need typing, but it can help.

[ramchip]

> you don't get bugs related to typing because elixir is somehow magic

Really? All the Elixir fans were saying that?