4 ms·

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

• Xeronate 4mo ago
  It was the same thing with javascript/typescript and python. Sometimes you just have to let people think what they want.
  • pjmlp 4mo ago
    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 4mo ago
      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 4mo ago
        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.
• zuzululu 4mo ago
  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 4mo ago
    > 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 4mo ago
    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 4mo ago
      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?
• pdpi 4mo ago
  > 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".
  • bad_haircut72 4mo ago
    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 4mo ago
      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.
  • aeonfox 4mo ago
    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 https://youtu.be/giYbq4HmfGA?t=571
    • abrookewood 4mo ago
      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.
• ramchip 4mo ago
  > you don't get bugs related to typing because elixir is somehow magic Really? All the Elixir fans were saying that?
• mrcwinn 4mo ago
  Please share that conversation you reference where the community said Elixir doesn’t need types because it is magic.
• jeremyjh 4mo ago
  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.
• globular-toast 4mo ago
  Not really a contradiction. You don't need typing, but it can help.
• IshKebab 4mo ago
  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 4mo ago
    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 4mo ago
      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 4mo ago
        > (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
• munificent 4mo ago
  This is the Goomba fallacy. https://en.wiktionary.org/wiki/Goomba_fallacy https://en.wiktionary.org/wiki/Goomba_fallacy
  • chabska 4mo ago
    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.
• isityettime 4mo ago
  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 4mo ago
    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 4mo ago
    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.
• brightball 4mo ago
  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.
• h14h 4mo ago
  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.