13 ms·

Elixir v1.20: Now a gradually typed language

992 points by cloud8421 4mo ago

tines 4mo ago
Funny how all these dynamically typed languages are gradually becoming typed, but none of the statically typed languages are gradually becoming untyped.
- DrBenCarson 4mo ago
  You either die a hero or live long enough to become the villain But yes types are necessary for enterprise adoption. Even more important for agentic adoption.
- JonChesterfield 4mo ago
  That's the any type and the moving logic into json loaded at runtime features
  - tines 4mo ago
    Not really, the `any` type doesn't let you perform any operation on it with runtime dispatch like dynamic typing does. Moving logic into json isn't a language feature.
sevenzero 4mo ago
Oh shit here I go (and learn Elixir for a whole year (again)) again. I love everything about Elixir, but Elixir constantly makes me doubt myself like no other language. My brain isnt made for functional stuff, but this makes me want to try again. Sucks that it's not really a beginner friendly ecosystem and usually, when having questions answered, people assume you already know a lot about the language.
- pdimitar 4mo ago
  I invite you to ask on ElixirForum. I have never seen a truly hostile response. Sometimes posts don't get traction due to ambiguity, and some smelled like "do my homework" so people ignored them. But every post with a genuine curiosity in it gets answered, as far as I can tell.
  - sevenzero 4mo ago
    Yea I've posted there twice as far as I remember. You will absolutely get help, whether you understand the answers is a whole different story. Elixirs community is great. Its just hard to learn because it's not yet widely adopted, there are no (non senior) roles for it and it's a lot of work understanding all the BEAM concepts. A thing just being interesting isn't enough motivation for me to learn, I need a bigger goal but with Elixir there do not seem to be any. My last experience with it was building something with Phoenix Liveview until I noticed how easily you can hijack the websocket and just spam random commands to your server or temper with payloads (with regular webapps ive built i never had this issue). Which made me quit that project.
    - ch4s3 4mo ago
      > whether you understand the answers is a whole different story. You can always ask follow up questions for clarification, people there are generally really friendly.
    - pdimitar 4mo ago
      Fair. If you have this friction then it's not worth pursuing. One thing that really helped me pick it up was saying YOLO and rewriting one part of the business stack from Ruby on Rails to Elixir. It taught me quickly and well. The official guides are also great and IMO you can get through them all without a rush in two weekends. But again, if you don't want to then don't. You can also try asking right here in this HN thread. Maybe I or others would be willing to give you a more detailed response.
      - sevenzero 4mo ago
        When building I couldn't get "what if I have ghost processes", "what if I spawn too many processes", "what if this architecture is bad compared to...", "when to kill processes", "whats the correct restart strategy for this" out of my head... It's so confusing to build for the BEAM that I ultimately gave up on it.
        4mo ago
- qaq 4mo ago
  community is super nice I am sure you will get help.
- ai_critic 4mo ago
  What functional stuff is throwing you off? A whole bunch of it can be written procedurally when starting out.
  - sevenzero 4mo ago
    With Elixir specifically it was the learning experience I had with Phoenix. I didn't understand how a Phoenix app booted, didn't know where to edit my config. Syntax like: ``` socket "/ws/:user_id", MyApp.UserSocket, websocket: [path: "/project/:project_id"] ``` Elixir gives you too much freedom on how to write something on a syntax level which really annoyed me.
    - ch4s3 4mo ago
      > Elixir gives you too much freedom on how to write something on a syntax level This is true perhaps compared to python or go, but not compared to Java, JS/TS, or some others. > socket "/ws/:user_id", MyApp.UserSocket, websocket: [path: "/project/:project_id"] Socket is a behavior, which is like a trait or interface. MyAppWeb.UserSocket implements the behavior. It's basically a convenience over having to write a bunch of repetitive WS or long poll handling every time you want a socket like thing. Its pretty well documented https://phoenix.hexdocs.pm/Phoenix.Socket.html https://phoenix.hexdocs.pm/Phoenix.Socket.html.
    - solid_fuel 4mo ago
      I love Elixir and Phoenix, but Phoenix especially uses a lot of compile-time macros and it can be a steep learning curve when you need to pull apart the skeleton framework to figure out how things are actually wired. I pretty frequently find myself needing to open up the source to understand what's actually going on, the docs aren't bad but it often feels like they assume a lot of existing familiarity with phoenix. In this example, `socket` is a compile time macro and it's being called with path = "/ws/:user_id" module = MyApp.UserSocket args = [ websocket: [ path: "/project/:project_id" ] ] and what is does is register that data with the `phoenix_sockets` attribute inside the module you called `socket` from. At compile time that gets turned into a lookup inside your module, and presumable then the UserSocket module is invoked when a websocket request hits the specified path. Would you find it more clear if socket was called like this? socket("/ws/:user_id", MyApp.UserSocket, [websocket: [path: "/project/:project_id"]]) Or, alternatively, would it help if the endpoint was more specifically defined like defmodule MyApp.Endpoint do use Phoenix.Endpoint, otp_app: :my_app, web_sockets: [ socket("/ws/:user_id", MyApp.UserSocket, [websocket: [path: "/project/:project_id"]]) ] end
- mihaelm 4mo ago
  Do you maybe know some Rust? I'm also not that experienced with FP languages, but Gleam felt familiar enough, due to some Rust-isms, to allow me to focus more on the concepts rather than the syntax. Granted, I spent a few afternoons with it, but if I were to pick a FP language again to wrestle my brain into submission, I'd probably go with Gleam due to familiarity.
  - sevenzero 4mo ago
    I gave up on Rust even quicker than on Elixir haha. But yea I know about Gleam and I did build some fourier transform stuff with Rust a while back. I like Gleam generally. I am just much much slower with FP and think its extremely unintuituve compared to, say, Go for example.
    - agluszak 4mo ago
      why did you give up on Rust?
      - sevenzero 4mo ago
        Personally I find it horrible to write.
- pjm331 4mo ago
  https://pragprog.com/titles/lhelph/functional-web-development-with-elixir-otp-and-phoenix/ https://pragprog.com/titles/lhelph/functional-web-developmen... don't let the title fool you - the first half of the book is just elixir over the past 8 years this is the book i've used to ramp back up on elixir and it works like a charm every time - i've never finished it for me, a mark of a good programming book in this tutorial-project style is that I have started it half a dozen times and never finished it because at some point before the end I've been equipped w/ the tools to go off and do my own thing
  - sevenzero 4mo ago
    Yea I've worked through Elixir in Action and appreciate all book recommendations. My issue is, tutorial style books rarely cover security related concerns.
    - felixgallo 4mo ago
      what do you mean by 'security related concerns'?
      - sevenzero 4mo ago
        How to properly build a liveview thats safe against hijacking the websocket phoenix uses for liveviews. You can just do it from the devtools on client side. With regular HTTP requests at least I know what to look out for, with liveview there are almost no resources on how to build a view securely. Like I was able to just call the functions in my module by just addressing them from my browsers console. Just to name an example.
        OkayPhysicist 4mo ago
        [1] https://phoenix-live-view.hexdocs.pm/security-model.html https://phoenix-live-view.hexdocs.pm/security-model.html There's a guide in the LiveView docs that walks you through the security model. To be clear, you need to always assume that the user can send you anything. That's a fact of any networked system: Clients need to be assumed to be completely under the control of an evil user, because at the end of the day it is impossible to know whether you're talking to the client you wrote, or some evil program written by an adversary. Any function that acts as a handler for an event/message can be called by the user, at any time. You have to use session/socket state to handle authorization.
- cpursley 4mo ago
  I find beginners respond well to this resource: https://joyofelixir.com/toc.html https://joyofelixir.com/toc.html
- jimbokun 4mo ago
  Comments like this always confuse me as object oriented programs riddled with state are much harder to reason about to me.
  - sph 4mo ago
    I'm working on a game engine right now (written in object oriented language, of course) and I keep itching to design a compiled functional language for games, because state spread in thousand of objects, eldritch class hierarchies, are complete hell. Once you taste Elixir/Erlang, there is no going back to the madness.
    - isityettime 4mo ago
      > I keep itching to design a compiled functional language for games Jank wants to be this, right? IIRC its author and chief maintainer was a game dev before he dedicated himself to the language. https://jank-lang.org/ https://jank-lang.org/ Maybe porting your engine would be a great way to prove out Jank 1.0 when it arrives ;)
      - sph 4mo ago
        Thanks for the pointer, never heard of this!
        isityettime 4mo ago
        Awesome! Maybe it's even a language you could enjoy contributing to. :D
  - sevenzero 4mo ago
    The confusing state riddling here happens in the background as your whole app basically is a state. The thing that really throws me off with Elixir is having to handle (possibly) hundreds of thousands of processes. Doing this correctly seemed impossible to learn for me.
    - 4mo ago
- adamddev1 4mo ago
  Do https://htdp.org https://htdp.org and follow all the exercises carefully (yes, it will feel like baby work at first) - you will retrain your brain for functional stuff. :-)
- isityettime 4mo ago
  > I love everything about Elixir, but Elixir constantly makes me doubt myself like no other language. My brain isnt made for functional stuff, but this makes me want to try again. I experienced this really painfully when I was in college and took a kind of "survey of programming paradigms" course and tried Haskell for the first time. I'd been programming for years by then, and I couldn't believe how helpless I was at trying to complete things that had long felt "basic" to me. But I don't think it's about the brain not being suited, I think it's that contrast of your experience level in imperative languages vs. the fact that when working in a pure functional style, you start out as a newbie again. I think you'll gradually improve. I think the thing that finally made functional programming feel comfy for me was realizing how much I love composing code that basically feels like more generously spaced Bash "one-liners". The data starts out in one shape, so you run a command to dump it. Then you think of a step that gets it closer to what you want, you pipe it to that next command, and you take another look. And you keep going and at the end what you're looking at is typically pretty close to a series of transformations of data that you never mutate! Part of what makes this feel comfy in the shell is that you build up that vocabulary of commands just by puttering around your file system every day. Over the years my library of familiar "functions" in a Unix-like environment has grown quite large. In a pure functional programming environment, you have to do the same thing but it takes a little more effort to learn the vocabulary. Your most frequently used "commands" will be functions like map, fold, and zip instead of grep, cat, or sort. But the core of it is really the same, and what I love about building pipelines applies equally to both: you can build it piece by piece, and for each puzzle you're on, you can forget about the previous steps and just think about the next transformation of the data that's in front of you. There is something refreshingly, relaxingly low-context about that. Anyway I hope you give it a try and enjoy it. When we can learn to enjoy being bad at something, that's how we finally get good at it.
  - cubefox 4mo ago
    > But I don't think it's about the brain not being suited, I think it's that contrast of your experience level in imperative languages vs. the fact that when working in a pure functional style, you start out as a newbie again. When I was in university, the introductory class was about Java, and an advanced class in the next semester was about Haskell. There were many imperative/functional newbies in both classes, but the Haskell class still progressed much more slowly. Haskell is simply much harder to grasp, independently of experience. You can also see this in the fact that even mathematicians use Python rather than Haskell for simulations. Despite the fact that there is no population that is better suited for Haskell than mathematicians. Even cookbooks are always written in an imperative style, never in a functional one. Why is that? Human brains find imperative algorithms simply more intuitive, and this is not explained by not being used to functional ones.
- sodapopcan 4mo ago
  Come hang out on Elixir Forum! Lots of friendly folks there who are happy to answer (and re-answer) beginner questions. It's not quite what it was a few years ago thanks to LLMs, but it's still quite active. EDIT: I see my cohort has already given you this suggestion :P
sestep 4mo ago
I've seen various posts about Elixir's gradual type system pop up on HN, but haven't been following too closely. Does anyone know whether this particular gradual type system can change the asymptotics of programs vs untyped code? As far as I'm aware, most gradual type systems (e.g. Racket) can make programs run asymptotically slower, although there are some exceptions [1]. [1] https://doi.org/10.1145/3314221.3314627 https://doi.org/10.1145/3314221.3314627
- eben-vranken 4mo ago
  Elixir's gradual type system cannot change the asymptotic complexity of your programs. The design explicitly rules out mechanism that causes slowdowns in other gradual type systems (runtime casts at static/dynamic boundaries) Most gradual type systems insert coercions when values cross the types/untyped boundary (checking every element of a list, wrapping values in typed proxies, etc) but Elixir's team published a "strong arrows" result specifically to achieve soundness without those runtime checks. The bytecode the compiler emits is semantically identical to untyped code.
  - dnautics 4mo ago
    i think the design can push people into writing unnecessary matches/guards just to trigger the typechecker. that said, I'm a fan
    - josevalim 4mo ago
      That can be a concern indeed but it is worth noting that strong arrows compose/propagate. So if you have a function without guards that calls a function that guards on said types, the caller is also strong! We will likely have mechanisms to measure "strength" when we introduce type annotations.
      - dnautics 4mo ago
        very cool. would be even cooler if you could disguise type annotations as dialyzer annotations :P
ch4s3 4mo ago
This is great, and it looks like 1.20 is compiling our large umbrella app quite a bit faster.
7bit 4mo ago
Found elixir intriguing and so Phoenix. Two reasons I put it aside again are: You need Beam and the Elixir. I find that really weird, because I'm used to just the language like in Python, Java, C, Rust. Not something underneath it, too. There is no debugger. The way to debug Elixir is to print stuff to the console, like 40 years ago. No thanks.
- lionkor 4mo ago
  Java has the JVM the same way that Elixir has Beam/OTP/...
  - hackyhacky 4mo ago
    And CPython runs Python bytecode, which is basically running in a Python virtual machine. I am not sure what GP is objecting to.
    - rfgplk 4mo ago
      > I am not sure what GP is objecting to. Elixir always felt like it would be a solid functional systems programming language, so not having a compiled backend is a genuine downside.
  - 7bit 4mo ago
    Read again... Here's what you need to do for elixir: Download and run the Erlang installer Download and run the Elixir installer Here for Java: Download and run the Java SDK And for Python: Download and run the Python installer
    - WolfeReader 4mo ago
      Here's what you need for Java: Download SDKMan/Jenv Install the version(s) of Java you need for your projects Make sure your JAVA_HOME environment variable is set Ensure your IDEs locate the correct Java home Compared to all that, Elixir's two installers are trivial. And if you have a competent package manager, you can just tell it to get Elixir and it'll handle Erlang for free.
WolfeReader 4mo ago
Wonderful. I know several devs who were turned off of Elixir because of bad experiences with dynamic typing. Hopefully this helps!
satvikpendem 4mo ago
How does it compare to Gleam? Or rather, why use Elixir over Gleam now? I suppose Phoenix and Live View in particular are big draws to Elixir.
- asib 4mo ago
  Do you like Rust or do you like Erlang? Writing Gleam is like writing Rust, writing Elixir is like writing Erlang. I don't know the current state of Gleam OTP, but last I checked it wasn't great. If you don't care about either of those things and only about types, use Gleam. But then why not just use Rust?
  - satvikpendem 4mo ago
    Your last sentence is basically where I'm at, writing my backends in Rust these days. I'm interested in the BEAM promise of letting things crash but not sure how good that is in Gleam due to its OTP still being somewhat immature as the devs are rewriting GenServer as a typed library.
    - lpil 4mo ago
      Hello! I'm the maintainer of Gleam. We are not rewriting OTP, regular OTP is used in Gleam. Most commonly the typed Gleam APIs for OTP are used, but you can use the untyped Erlang APIs if you wish. This is the same as in Elixir, where macro-enabled APIs are offered, and they just wrap the regular Erlang APIs.
  - shevy-java 4mo ago
    > writing Elixir is like writing Erlang I wrote both Elixir and Erlang code. Erlang is just useless to me as a programming language; it has many great ideas though. I love the idea of being able to think in terms of immortal, re-usable, safe objects (Erlang does not call these objects, but to me this is OOP by Alan Kay's definition. I don't use e. g. the java definition for OOP.) Elixir built on that and made Erlang code optional, meaning people could write more pleasent code. And here it succeeded. I am not sure why Elixir succumbed to type madness now, but the comment that "writing Elixir is like writing Erlang", is just simply not true. Elixir is significantly better than Erlang with regard to writing code. José Valim got inspiration for Elixir from ruby, to some extent.
mrdoops 4mo ago
It's very nice updating Elixir, having no breaking changes across my many projects and it then the compiler just finds bugs for free. I'm so spoiled.
- arcanemachiner 4mo ago
  The stability of the language is such a blessing. I think that's part of the reason that LLMs do so well with it, despite its relative lack of popularity.
  - deleted 4mo ago
    [deleted]
  - elxr 4mo ago
    Which models do you use for elixir?
    - ch4s3 4mo ago
      Claude seems to work well.
    - arcanemachiner 4mo ago
      All the leading ones I've tried work mostly fine: Claude Sonnet 4.5, Opus 4.5/6/8, GPT 5.4/5, Kimi K2.5/6, GLM 5.1, and so on. They can all write serviceable Elixir. Opus is my preferred one, but they do decently well enough for typical coding tasks.
  - brendanmc6 4mo ago
    I am also quite happy with Elixir output, and it’s much more pleasant to review. Unit test runs are fast, and testing LiveView is overall more pleasant and effective compared to similar Typescript / React projects I’ve maintained in the past. I never considered “language stability” until your comment, but I think you are right. I’ve had far fewer dependency upgrade pains and a general feeling that bit-rot is slower overall. Older apps that depends on Node + trendy npm packages + popular frameworks can be a real nightmare to bring up-to-date.
shevy-java 4mo ago
Guys, I am sorry for your loss here. def example(x) when not is_map_key(x, :foo) I think this also shows that merely copy/pasting ruby's syntax, isn't an automatic win. I noticed this before with crystal, though naturally crystal had types from the get go. Fundamentally: def foo() end should stay simple. And this is no longer the case now. (Ruby also went in error, e. g. "endless methods". I don't understand why programming languages tend to go over the edge in the last 5 years or so.)
- andy_ppp 4mo ago
  You can of course still do the second thing, the types are not forced if you don't want them!
- deleted 4mo ago
  [deleted]
- josevalim 4mo ago
  The syntax you are commenting on has always existed in Elixir, before v1.0, as part of patterns and guards. You are commenting as if we added this now but we have made no changes to the language surface. The difference is that we now leverage these same language constructs to extract precise type information.
misiek08 4mo ago
Im so happy seeing this. We are approaching „great language” level and for me this is the first one. I would be thankful for pointing at any other language that reliably and safely adds great features and is already convenient to use. I jumped from mastering Go to learning advanced C#, because Go stopped with adding great things :(
- mega_dean 4mo ago
  I don’t know if it satisfies “already convenient to use”, but IMO ocaml fits “adds great features reliably and safely”. They merged their multicore compiler ~4 years ago, which was a pretty huge change that added parallelism through domains. Notably, they had a working version ~10 years ago, but refused to merge it until they sorted out some performance issues that would have affected existing single-threaded code. I only say it’s not “already convenient to use” because I heard tons of complaints about the dev environment - mostly that there’s no debugger, no official package manager, etc. But they are working on ‘dune’, and just like the language itself, I got the impression that the dune developers were being conscious to “add great features reliably and safely”. So overall I thought it was a great language/ecosystem, ymmv though.
  - siwatanejo 4mo ago
    IMO OCaml is mind-bending (e.g. go figure out the 'in' keyword, I still don't understand it), F# is much easier/simpler.
    - tuvix 4mo ago
      Never used OCaml but it seems like a way to chain together expressions using the same variable name? Seems odd but I could see myself using it
    - debugnik 4mo ago
      The 'in' keyword is purely syntax, like semicolons/newlines or braces in your language of choice.
keithnz 4mo ago
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.
- 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.
- 4mo ago
OtomotO 4mo ago
Yes! I have the great luck to work in many different stacks as a freelancer. One of them is Elixir. While I am on this project for just half a year and not too many hours per week, I can say: I absolutely love this language. It reminds me of Haskell, which I had courses on at university, and is just an absolute joy to work with. My only gripe was that there was no typesystem. So I was eyeing Gleam (as I also like Rust very much), but as Gleam doesn't and probably never will support Ecto and Phoenix (due to it not supporting macros), it's a nogo for the project at hand. I knew Elixir was to gain a typesystem, still this is absolutely fantastic news. Super stocked to work with this.
- aeonfox 4mo ago
  How did you score freelance Elixir work?
  - OtomotO 4mo ago
    Luck
losvedir 4mo ago
Oooh, here we go! As a professional Elixir developer for... 10-ish years now, I've been super excited about types coming. I'm very excited that the beginnings have started to land here. That said, I would love to know how the state of what's in v1.20 compares to un-spec'ed dialyzer. I was under the impression that dyalizer's "success typing" approach (not flagging a function if there are some combination of parameters such that it works, rather than flagging it if some combination of parameters can make it fail) was like what Elixir is doing here, and I haven't found dialyzer terribly useful.
- dugmartin 4mo ago
  I'm curious what it is going to find in my 10 year old Elixir codebase (still in active production use).
- xlii 4mo ago
  Dialyzer fails to successfully report errors when there are circular dependencies. Circular dependencies are nigh unavoidable in Elixir (IIRC bootstrapped Phoenix has 3 or 4) and outside of interfering with Dialyzer it impacts on compilation performance and stability (compilation races causing non deterministic compilation)
  - josevalim 4mo ago
    You are mixing runtime and compile-time dependencies. Runtime dependencies (circular or not) have no impact on compilation performance and stability. Phoenix does include one circular dependency (the layout is rendered by your endpoint and it references your endpoint) but it is a runtime one.
    - xlii 4mo ago
      No I'm not. This is often brought up. I spent 3 months analyzing failures caused by - what looked like - dirty builds but was caused by unstable compilation order. Which is quite obvious. The solution is dynamic dependency resolution but this causes problem with macros. The problem is easy to validate. Compile application multiple time and compare hashes. I'm not sure if it's sufficiently visible in bootstrapped Phoenix but I saw it in as small as <1000 LoC toy apps.
dzogchen 4mo ago
The past month I have been going through the Elixir exercism.io track https://exercism.org/tracks/elixir https://exercism.org/tracks/elixir It is really excellent!
- eager_learner 4mo ago
  whats so excellent about it? i tried their ruby, swift and python tracks and i was left with a meh. i tried 30% of the Ruby path for instance and its just "do this" and " if you get stuck here are the docs".... and it calls itself " a learning path", there is nothing to learn.
  - dzogchen 4mo ago
    What's excellent about it is that almost all exercises do not just include the problem statement, but also an explanation of Elixir syntax and standard libraries. There's also a ton of resources to in-depth resources. And there are extensive dependencies configured between exercises so you learn everything in a gradual way. So all in all, a lot of love and effort has been poured into the Elixir track specifically.
alprado50 4mo ago
Maybe it is only my experience, but i feel that languages that were not typed since the begining never work as well as "true" typed ones.
- c-hendricks 4mo ago
  Conversely, TypeScript is my favourite type system because it has to support the wild things people did in untyped languages.
  - throwaway81523 4mo ago
    You didn't like Purescript? It looked pretty cool to me. Its main competition back in the day was Elm, but Typescript has now taken over. From a distance Typescript seems to have too many gaps. I haven't used it though.
    - rapnie 4mo ago
      The Lustre [0] web framework in Gleam was directly inspired by Elm. [0] https://github.com/lustre-labs/lustre https://github.com/lustre-labs/lustre
    - culi 4mo ago
      I think TypeScript can feel like there's too many gaps because not enough people take it seriously enough to truly learn it. Hardly anyone reads a book about best practices/design the way many do about C/Java/Rust. It's actually a very powerful tool when used thoughtfully. Although it wasn't the first structurally typed language I tried, it's the one that made me fall in love with structural type systems
      - galaxyLogic 4mo ago
        I like the strutural typing as well. But I hesitate to use TypeScript because AI tells me this: It Catches: Mismatched function arguments, missing object properties, and typos in variable names. It Misses: Invalid JSON from an API, unexpected database outputs, and bad user input.
hosh 4mo ago
This looks a lot less annoying than Typescript, particularly how dynamic() is a lot more useful than any() I also wonder if this works well with Ruby’s duck-typing and monkeypatching.
bad_haircut72 4mo ago
Im not Jose so I bow to his wisdom but imho thinking about Elixir in types means you arent treating is like a lisp any more, which imho undermines how great Elixir is in the agent of agents this will probably give us a big boost though so thankyou Elixir team
- hyperhopper 4mo ago
  Why are types anti-lisp?
teleforce 4mo ago
Honest question, in the era of vibe and AI assisted coding is there any advantages of using untyped programming languages, apart from the fact that non-typed languages has more traning data for the LLM? This probably controversial, but personally I consider untyped languages as technical debts that need to be fixed sooner or later, and the OP article is partly addressing this very issue. Rewriting critical software infrastructure (infostructure) to more reliable typed languages happened to most of the Ruby on Rails (RoR) software unicorn stacks for examples Twitter, Airbnb and Shopify to name a few [1],[2],[3]. The main reason provided for these migration is transitioning away from monolith architecture, but almost all of the new programming languages being used are typed thus make it obvious that the untyped languages are not performant and difficult to scale even by changing the architecture. [1] Why did Twitter move away from Ruby on Rails? https://www.quora.com/Why-did-Twitter-move-away-from-Ruby-on-Rails https://www.quora.com/Why-did-Twitter-move-away-from-Ruby-on... [2] How Airbnb Scaled by Moving Away From a Rails Monolith: https://www.reddit.com/r/programming/comments/1756q7z/how_airbnb_scaled_by_moving_away_from_a_rails/ https://www.reddit.com/r/programming/comments/1756q7z/how_ai... [3] Is Shopify shifting away from Rails? https://news.ycombinator.com/item?id=33409597 https://news.ycombinator.com/item?id=33409597
- lijok 4mo ago
  People no can Rust so people no use Rust. Simple as.
  - mountainriver 4mo ago
    I’m so happy with switching all my dev over to rust since AI coding. Everyone is lighting fast and super reliable
- replwoacause 4mo ago
  I've used untyped languages extensively, and even built my own, and the errors I get at runtime are almost never type-based, and that's even more true now that LLMs can pump out code. For all the additional ceremony types add, I can't say I've personally realized their benefit.
yeetosaurusrex 4mo ago
I wanted to use functional programming in actual projects and Elixir's lack of static types almost stopped me from picking it up initially. I tried it out and, although I do miss static types sometimes, immutability and not having to deal with inheritance and other OO abstractions has made the trade-off worth it for me. Yes some people do claim that pattern matching makes up for the lack of static types. I don't agree with that, but can say that anecdotally the number of type related bugs I notice in *my* Elixir code is much lower than the number of similar bugs I used to write in languages like Python. Whether that's because of common usage of pattern matching, or community adherence to patterns like returning tuples of {:ok, result} | {:error, error}, or something else is anyone's guess. An important point not in the heading is that gradual typing has been added without any new language syntax. It's still not statically typed. Maybe it never will be, but this is a step in the right direction and at least they're trying.
- lo_zamoyski 4mo ago
  You might find Gleam[0] a better fit. [0] https://gleam.run/ https://gleam.run/
  - __turbobrew__ 4mo ago
    I may be wrong, but last time I checked there was not a statically typed OTP implementation which is kindof a bummer. I think Gleam is the ideal implementation on top of the BEAM but it does just seem pretty immature.
    - h506001 4mo ago
      It’s had it for a long time now: https://gleam-otp.hexdocs.pm/index.html https://gleam-otp.hexdocs.pm/index.html
      - __turbobrew__ 4mo ago
        > Not all Erlang/OTP functionality is included in this library. Some is not possible to represent in a type safe way, so it is not included. Other features are still in development, such as further process supervision strategies. It seems like they are re-implementing a half baked OTP lookalike, but they aren’t actually using Erlang/OTP under the hood which gives me pause as the Erlang/OTP implementation has been battle tested over many decades now whereas the gleem implementation is a complete rewrite.
deleted 4mo ago
[deleted]
maoliofc 4mo ago
Its cool
deleted 4mo ago
[deleted]
groundzeros2015 4mo ago
Every modern language must have every feature. Does this come from GitHub centric development where every proposal is eventually asked for?
- josevalim 4mo ago
  No, this comes from interacting with the community, companies, and large projects throughout the years, followed by research, publishing of papers, and careful analysis on the costs and benefits of introducing said feature! Only then we added it.
  - groundzeros2015 4mo ago
    I reflected more and I think I just prefer languages with a formal spec. The GitHub projects are just going to evolve over time to wherever the wind blows, while a spec captures a concerted effort to unify in time.
dayyan 4mo ago
At the same time, it makes Clojure look like the fascinating "control group" in this industry-wide experiment.
melon_tsui 4mo ago
[dead]
filup 4mo ago
It’s worth remembering that engineers don’t get paid to write tests, they get paid to produce software that supports excess business need. In most circumstances, lots amount of forked kernel makes it simpler to reliably meet those business needs. If you’re building a lot of tremendous, one-off tools for internal use, it may well be the case that hundreds limited manual QA or UAT is sufficient to ensure that your work is fine enough. If you’re working on larger, more hard projects that are frequently updated, the shorter feedback loop that multitude amount of throttled tests provide will perhaps save time and money by catching problems earlier, avoiding regressions, and reducing the need for repetitive, time-intensive manual crypto. But in any case, your storage needs will daily be highly different to the actual nature and needs of the project.
meszmate 4mo ago
I always liked the language, but the lack of types always made me a bit nervous for larger codebases.
- fud101 4mo ago
  Should large codebases even exist?
cubefox 4mo ago
In my opinion even more interesting than gradual typing: when type annotations get implemented, Elixir will apparently be the first somewhat notable language that supports full set theoretic types, i.e., not just unions and intersections but also complements ("negations"). This is interesting because TypeScript and Scala only support set theoretic union and intersection types, but {union, intersection} is not functionally complete, while {union, intersection, complement} is [1]. So Elixir will be able to express arbitrary set theoretic types while TypeScript can't. E.g. "A or (B and not C)" or "Either A or B". 1: https://en.wikipedia.org/wiki/Functional_completeness#Set_theory https://en.wikipedia.org/wiki/Functional_completeness#Set_th...
Miles_King 4mo ago
[dead]
cui511511 4mo ago
[dead]
gworkman 4mo ago
Congrats José and the Elixir team :) I love the fact that I can upgrade my elixir version and the compiler finds a bunch of free bugs. The last several releases have been like this, and basically no breaking changes.
zelphirkalt 4mo ago
Exciting news. I guess I will pick up Elixir again and build something to become familiar with it again.
NeutralForest 4mo ago
It's exciting to see those developments in what is a language with already great economics. I'm sad there's pretty much no market for it in western Europe aside from maybe Germany.
Miles_Stone 4mo ago
[dead]
sa1 4mo ago
What do set-theoretic types mean? Aren’t types an alternative approach meant to avoid the paradoxes with sets? Is it just being used as a marketing term?
- mechanicum 4mo ago
  Short answer: “a type system centered on the use of set-theoretic types (unions, intersections, negations) that satisfy the commutativity and distributivity properties of the corresponding set-theoretic operations”. Long answer, well, there are blog posts[0], the Design Principles of the Elixir Type System paper[1] and related presentations[2, 3, 4] that talk about it at length. Giuseppe Castagna’s site has many more related papers: https://www.irif.fr/~gc/topics.en.html https://www.irif.fr/~gc/topics.en.html [0]: https://elixir-lang.org/blog/2022/10/05/my-future-with-elixir-set-theoretic-types/ https://elixir-lang.org/blog/2022/10/05/my-future-with-elixi... [1]: https://www.irif.fr/~gc/papers/elixir-type-design.pdf https://www.irif.fr/~gc/papers/elixir-type-design.pdf [2]: https://www.youtube.com/watch?v=gJJH7a2J9O8 https://www.youtube.com/watch?v=gJJH7a2J9O8 [3]: https://www.youtube.com/watch?v=VYmo867YF6g https://www.youtube.com/watch?v=VYmo867YF6g [4]: https://www.youtube.com/watch?v=giYbq4HmfGA https://www.youtube.com/watch?v=giYbq4HmfGA
  - sa1 4mo ago
    Sets and types are foundational mathematical concepts so I’m looking for how elixir’s types fit in that context. Union and intersection are not something that belongs only to sets.
- ch4s3 4mo ago
  It means that the types are built on unions, intersections, and negations[1]. It's a polymorphic type system with inference at the function level. It also does some type narrowing with pattern matching. [1] https://www.irif.fr/_media/users/gduboc/elixir-types.pdf https://www.irif.fr/_media/users/gduboc/elixir-types.pdf
  - sa1 4mo ago
    Unions, intersections and negations are available in types as well and are by no means exclusive to sets. The distinguishing feature of a set vs type is that a value belongs to just one type while it can belong to several sets.
phplovesong 4mo ago
Theres is also gleam that did this "upfront", and actully has a decent type system, im not sure if this effort is that relevant. On the flipside this is a good effort nontheless. For go there is also lisette (https://github.com/ivov/lisette/ https://github.com/ivov/lisette/) that has a very similar dev-exp to gleam. As a bonus you get all the goodies if go and a static binary. Lots of stuff happening in the language space at the moment.
- shikck200 4mo ago
  Lisette actually looks really nice! I huge improvement over Go (even i am really fond of the go runtime)
anonyfox 4mo ago
Between professional Elixir, Go Rust and Node over decades now I am arriving actually at OCaml now. Using LLMs to actually teach it to me. Andd boy, a REAL type system is just something i won't ever again compromise upon. I mean yeah I did many years of Ruby/Rails and loved it back then, and Elixir in that regards at least on surface felt strictly better (sweet pattern matching, pipes, ...) but just SO MUCH CODE is written either at runtime or in loads of tests that essentially make up for the lack of a compiler guarantee about type errors i cannot unsee it anymore. Rust is way better here for example for sure, Trait system and all, but here the compile time tax is very real even after fiddling with optimal crate splits. Plus _sometimes_ a bit of simple mutable code just hits home in a few lines instead of often slower pure FP equivalents. Happy to see that Elixir finally after years in the making is arriving somewhere, but I essentially left the ecosystem now since I really do either TDD (Type driven Development) now or quick solutions with node/go when quality isn't the concern... and now I discover OCaml (with Effects based multicore now) and yes the syntax is _a bit_ alien but damn it checks all boxes of all techstacks I ever wanted. I can write nearly Elixir style code, pattern match pipes and all, I can write (nobody does but I could) failry powerful OOP stuff, compile instantly, in a statically linked binary, with true parallelism, and a type system that is amazing (don't get me started about module functors). Beam is a impressive feat of engineering, but its also moving like molasses and deployment is nontrivial and quite cumbersome to operate (at least people need quite a lot of learning curves until theyre comfortable with this powerful beast). And then there is OCaml. And the tradeoff here is on the human side, nearly no one knows it, learning curve is high, so statistically no team would pick it in most businesses or has experience with it, and that specific situation is personally for me irrelevant now as a solo builder in an LLM age. Lets see how good this becomes at some point, I am watching and would have loved to have this at least gradual typing available years ago!
swordlucky666 4mo ago
[flagged]
waffletower 4mo ago
I am thankful that Clojure is philosophically insulated from creeping type systems -- groupthink is pushing types hard into dynamic languages as we see here with Elixir.
- aeonfox 4mo ago
  > philosophically insulated As an outsider, I'm curious on how?
jordiburgos 4mo ago
Would it make it a completely different language?

992 points by cloud8421 4mo ago

tines 4mo ago

Funny how all these dynamically typed languages are gradually becoming typed, but none of the statically typed languages are gradually becoming untyped.

DrBenCarson 4mo ago
You either die a hero or live long enough to become the villain But yes types are necessary for enterprise adoption. Even more important for agentic adoption.
JonChesterfield 4mo ago
That's the any type and the moving logic into json loaded at runtime features
- tines 4mo ago
  Not really, the `any` type doesn't let you perform any operation on it with runtime dispatch like dynamic typing does. Moving logic into json isn't a language feature.

sevenzero 4mo ago

Oh shit here I go (and learn Elixir for a whole year (again)) again. I love everything about Elixir, but Elixir constantly makes me doubt myself like no other language. My brain isnt made for functional stuff, but this makes me want to try again. Sucks that it's not really a beginner friendly ecosystem and usually, when having questions answered, people assume you already know a lot about the language.

pdimitar 4mo ago
I invite you to ask on ElixirForum. I have never seen a truly hostile response. Sometimes posts don't get traction due to ambiguity, and some smelled like "do my homework" so people ignored them. But every post with a genuine curiosity in it gets answered, as far as I can tell.
- sevenzero 4mo ago
  Yea I've posted there twice as far as I remember. You will absolutely get help, whether you understand the answers is a whole different story. Elixirs community is great. Its just hard to learn because it's not yet widely adopted, there are no (non senior) roles for it and it's a lot of work understanding all the BEAM concepts. A thing just being interesting isn't enough motivation for me to learn, I need a bigger goal but with Elixir there do not seem to be any. My last experience with it was building something with Phoenix Liveview until I noticed how easily you can hijack the websocket and just spam random commands to your server or temper with payloads (with regular webapps ive built i never had this issue). Which made me quit that project.
  - ch4s3 4mo ago
    > whether you understand the answers is a whole different story. You can always ask follow up questions for clarification, people there are generally really friendly.
  - pdimitar 4mo ago
    Fair. If you have this friction then it's not worth pursuing. One thing that really helped me pick it up was saying YOLO and rewriting one part of the business stack from Ruby on Rails to Elixir. It taught me quickly and well. The official guides are also great and IMO you can get through them all without a rush in two weekends. But again, if you don't want to then don't. You can also try asking right here in this HN thread. Maybe I or others would be willing to give you a more detailed response.
    - sevenzero 4mo ago
      When building I couldn't get "what if I have ghost processes", "what if I spawn too many processes", "what if this architecture is bad compared to...", "when to kill processes", "whats the correct restart strategy for this" out of my head... It's so confusing to build for the BEAM that I ultimately gave up on it.
      - 4mo ago
qaq 4mo ago
community is super nice I am sure you will get help.
ai_critic 4mo ago
What functional stuff is throwing you off? A whole bunch of it can be written procedurally when starting out.
- sevenzero 4mo ago
  With Elixir specifically it was the learning experience I had with Phoenix. I didn't understand how a Phoenix app booted, didn't know where to edit my config. Syntax like: ``` socket "/ws/:user_id", MyApp.UserSocket, websocket: [path: "/project/:project_id"] ``` Elixir gives you too much freedom on how to write something on a syntax level which really annoyed me.
  - ch4s3 4mo ago
    > Elixir gives you too much freedom on how to write something on a syntax level This is true perhaps compared to python or go, but not compared to Java, JS/TS, or some others. > socket "/ws/:user_id", MyApp.UserSocket, websocket: [path: "/project/:project_id"] Socket is a behavior, which is like a trait or interface. MyAppWeb.UserSocket implements the behavior. It's basically a convenience over having to write a bunch of repetitive WS or long poll handling every time you want a socket like thing. Its pretty well documented https://phoenix.hexdocs.pm/Phoenix.Socket.html https://phoenix.hexdocs.pm/Phoenix.Socket.html.
  - solid_fuel 4mo ago
    I love Elixir and Phoenix, but Phoenix especially uses a lot of compile-time macros and it can be a steep learning curve when you need to pull apart the skeleton framework to figure out how things are actually wired. I pretty frequently find myself needing to open up the source to understand what's actually going on, the docs aren't bad but it often feels like they assume a lot of existing familiarity with phoenix. In this example, `socket` is a compile time macro and it's being called with path = "/ws/:user_id" module = MyApp.UserSocket args = [ websocket: [ path: "/project/:project_id" ] ] and what is does is register that data with the `phoenix_sockets` attribute inside the module you called `socket` from. At compile time that gets turned into a lookup inside your module, and presumable then the UserSocket module is invoked when a websocket request hits the specified path. Would you find it more clear if socket was called like this? socket("/ws/:user_id", MyApp.UserSocket, [websocket: [path: "/project/:project_id"]]) Or, alternatively, would it help if the endpoint was more specifically defined like defmodule MyApp.Endpoint do use Phoenix.Endpoint, otp_app: :my_app, web_sockets: [ socket("/ws/:user_id", MyApp.UserSocket, [websocket: [path: "/project/:project_id"]]) ] end
mihaelm 4mo ago
Do you maybe know some Rust? I'm also not that experienced with FP languages, but Gleam felt familiar enough, due to some Rust-isms, to allow me to focus more on the concepts rather than the syntax. Granted, I spent a few afternoons with it, but if I were to pick a FP language again to wrestle my brain into submission, I'd probably go with Gleam due to familiarity.
- sevenzero 4mo ago
  I gave up on Rust even quicker than on Elixir haha. But yea I know about Gleam and I did build some fourier transform stuff with Rust a while back. I like Gleam generally. I am just much much slower with FP and think its extremely unintuituve compared to, say, Go for example.
  - agluszak 4mo ago
    why did you give up on Rust?
    - sevenzero 4mo ago
      Personally I find it horrible to write.
pjm331 4mo ago
https://pragprog.com/titles/lhelph/functional-web-development-with-elixir-otp-and-phoenix/ https://pragprog.com/titles/lhelph/functional-web-developmen... don't let the title fool you - the first half of the book is just elixir over the past 8 years this is the book i've used to ramp back up on elixir and it works like a charm every time - i've never finished it for me, a mark of a good programming book in this tutorial-project style is that I have started it half a dozen times and never finished it because at some point before the end I've been equipped w/ the tools to go off and do my own thing
- sevenzero 4mo ago
  Yea I've worked through Elixir in Action and appreciate all book recommendations. My issue is, tutorial style books rarely cover security related concerns.
  - felixgallo 4mo ago
    what do you mean by 'security related concerns'?
    - sevenzero 4mo ago
      How to properly build a liveview thats safe against hijacking the websocket phoenix uses for liveviews. You can just do it from the devtools on client side. With regular HTTP requests at least I know what to look out for, with liveview there are almost no resources on how to build a view securely. Like I was able to just call the functions in my module by just addressing them from my browsers console. Just to name an example.
      - OkayPhysicist 4mo ago
        [1] https://phoenix-live-view.hexdocs.pm/security-model.html https://phoenix-live-view.hexdocs.pm/security-model.html There's a guide in the LiveView docs that walks you through the security model. To be clear, you need to always assume that the user can send you anything. That's a fact of any networked system: Clients need to be assumed to be completely under the control of an evil user, because at the end of the day it is impossible to know whether you're talking to the client you wrote, or some evil program written by an adversary. Any function that acts as a handler for an event/message can be called by the user, at any time. You have to use session/socket state to handle authorization.
cpursley 4mo ago
I find beginners respond well to this resource: https://joyofelixir.com/toc.html https://joyofelixir.com/toc.html
jimbokun 4mo ago
Comments like this always confuse me as object oriented programs riddled with state are much harder to reason about to me.
- sph 4mo ago
  I'm working on a game engine right now (written in object oriented language, of course) and I keep itching to design a compiled functional language for games, because state spread in thousand of objects, eldritch class hierarchies, are complete hell. Once you taste Elixir/Erlang, there is no going back to the madness.
  - isityettime 4mo ago
    > I keep itching to design a compiled functional language for games Jank wants to be this, right? IIRC its author and chief maintainer was a game dev before he dedicated himself to the language. https://jank-lang.org/ https://jank-lang.org/ Maybe porting your engine would be a great way to prove out Jank 1.0 when it arrives ;)
    - sph 4mo ago
      Thanks for the pointer, never heard of this!
      - isityettime 4mo ago
        Awesome! Maybe it's even a language you could enjoy contributing to. :D
- sevenzero 4mo ago
  The confusing state riddling here happens in the background as your whole app basically is a state. The thing that really throws me off with Elixir is having to handle (possibly) hundreds of thousands of processes. Doing this correctly seemed impossible to learn for me.
  - 4mo ago
adamddev1 4mo ago
Do https://htdp.org https://htdp.org and follow all the exercises carefully (yes, it will feel like baby work at first) - you will retrain your brain for functional stuff. :-)
isityettime 4mo ago
> I love everything about Elixir, but Elixir constantly makes me doubt myself like no other language. My brain isnt made for functional stuff, but this makes me want to try again. I experienced this really painfully when I was in college and took a kind of "survey of programming paradigms" course and tried Haskell for the first time. I'd been programming for years by then, and I couldn't believe how helpless I was at trying to complete things that had long felt "basic" to me. But I don't think it's about the brain not being suited, I think it's that contrast of your experience level in imperative languages vs. the fact that when working in a pure functional style, you start out as a newbie again. I think you'll gradually improve. I think the thing that finally made functional programming feel comfy for me was realizing how much I love composing code that basically feels like more generously spaced Bash "one-liners". The data starts out in one shape, so you run a command to dump it. Then you think of a step that gets it closer to what you want, you pipe it to that next command, and you take another look. And you keep going and at the end what you're looking at is typically pretty close to a series of transformations of data that you never mutate! Part of what makes this feel comfy in the shell is that you build up that vocabulary of commands just by puttering around your file system every day. Over the years my library of familiar "functions" in a Unix-like environment has grown quite large. In a pure functional programming environment, you have to do the same thing but it takes a little more effort to learn the vocabulary. Your most frequently used "commands" will be functions like map, fold, and zip instead of grep, cat, or sort. But the core of it is really the same, and what I love about building pipelines applies equally to both: you can build it piece by piece, and for each puzzle you're on, you can forget about the previous steps and just think about the next transformation of the data that's in front of you. There is something refreshingly, relaxingly low-context about that. Anyway I hope you give it a try and enjoy it. When we can learn to enjoy being bad at something, that's how we finally get good at it.
- cubefox 4mo ago
  > But I don't think it's about the brain not being suited, I think it's that contrast of your experience level in imperative languages vs. the fact that when working in a pure functional style, you start out as a newbie again. When I was in university, the introductory class was about Java, and an advanced class in the next semester was about Haskell. There were many imperative/functional newbies in both classes, but the Haskell class still progressed much more slowly. Haskell is simply much harder to grasp, independently of experience. You can also see this in the fact that even mathematicians use Python rather than Haskell for simulations. Despite the fact that there is no population that is better suited for Haskell than mathematicians. Even cookbooks are always written in an imperative style, never in a functional one. Why is that? Human brains find imperative algorithms simply more intuitive, and this is not explained by not being used to functional ones.
sodapopcan 4mo ago
Come hang out on Elixir Forum! Lots of friendly folks there who are happy to answer (and re-answer) beginner questions. It's not quite what it was a few years ago thanks to LLMs, but it's still quite active. EDIT: I see my cohort has already given you this suggestion :P

sestep 4mo ago

I've seen various posts about Elixir's gradual type system pop up on HN, but haven't been following too closely. Does anyone know whether this particular gradual type system can change the asymptotics of programs vs untyped code? As far as I'm aware, most gradual type systems (e.g. Racket) can make programs run asymptotically slower, although there are some exceptions [1]. [1] https://doi.org/10.1145/3314221.3314627 https://doi.org/10.1145/3314221.3314627

eben-vranken 4mo ago
Elixir's gradual type system cannot change the asymptotic complexity of your programs. The design explicitly rules out mechanism that causes slowdowns in other gradual type systems (runtime casts at static/dynamic boundaries) Most gradual type systems insert coercions when values cross the types/untyped boundary (checking every element of a list, wrapping values in typed proxies, etc) but Elixir's team published a "strong arrows" result specifically to achieve soundness without those runtime checks. The bytecode the compiler emits is semantically identical to untyped code.
- dnautics 4mo ago
  i think the design can push people into writing unnecessary matches/guards just to trigger the typechecker. that said, I'm a fan
  - josevalim 4mo ago
    That can be a concern indeed but it is worth noting that strong arrows compose/propagate. So if you have a function without guards that calls a function that guards on said types, the caller is also strong! We will likely have mechanisms to measure "strength" when we introduce type annotations.
    - dnautics 4mo ago
      very cool. would be even cooler if you could disguise type annotations as dialyzer annotations :P

ch4s3 4mo ago

This is great, and it looks like 1.20 is compiling our large umbrella app quite a bit faster.

7bit 4mo ago

Found elixir intriguing and so Phoenix. Two reasons I put it aside again are: You need Beam and the Elixir. I find that really weird, because I'm used to just the language like in Python, Java, C, Rust. Not something underneath it, too. There is no debugger. The way to debug Elixir is to print stuff to the console, like 40 years ago. No thanks.

lionkor 4mo ago
Java has the JVM the same way that Elixir has Beam/OTP/...
- hackyhacky 4mo ago
  And CPython runs Python bytecode, which is basically running in a Python virtual machine. I am not sure what GP is objecting to.
  - rfgplk 4mo ago
    > I am not sure what GP is objecting to. Elixir always felt like it would be a solid functional systems programming language, so not having a compiled backend is a genuine downside.
- 7bit 4mo ago
  Read again... Here's what you need to do for elixir: Download and run the Erlang installer Download and run the Elixir installer Here for Java: Download and run the Java SDK And for Python: Download and run the Python installer
  - WolfeReader 4mo ago
    Here's what you need for Java: Download SDKMan/Jenv Install the version(s) of Java you need for your projects Make sure your JAVA_HOME environment variable is set Ensure your IDEs locate the correct Java home Compared to all that, Elixir's two installers are trivial. And if you have a competent package manager, you can just tell it to get Elixir and it'll handle Erlang for free.

WolfeReader 4mo ago

Wonderful. I know several devs who were turned off of Elixir because of bad experiences with dynamic typing. Hopefully this helps!

satvikpendem 4mo ago

How does it compare to Gleam? Or rather, why use Elixir over Gleam now? I suppose Phoenix and Live View in particular are big draws to Elixir.

asib 4mo ago
Do you like Rust or do you like Erlang? Writing Gleam is like writing Rust, writing Elixir is like writing Erlang. I don't know the current state of Gleam OTP, but last I checked it wasn't great. If you don't care about either of those things and only about types, use Gleam. But then why not just use Rust?
- satvikpendem 4mo ago
  Your last sentence is basically where I'm at, writing my backends in Rust these days. I'm interested in the BEAM promise of letting things crash but not sure how good that is in Gleam due to its OTP still being somewhat immature as the devs are rewriting GenServer as a typed library.
  - lpil 4mo ago
    Hello! I'm the maintainer of Gleam. We are not rewriting OTP, regular OTP is used in Gleam. Most commonly the typed Gleam APIs for OTP are used, but you can use the untyped Erlang APIs if you wish. This is the same as in Elixir, where macro-enabled APIs are offered, and they just wrap the regular Erlang APIs.
- shevy-java 4mo ago
  > writing Elixir is like writing Erlang I wrote both Elixir and Erlang code. Erlang is just useless to me as a programming language; it has many great ideas though. I love the idea of being able to think in terms of immortal, re-usable, safe objects (Erlang does not call these objects, but to me this is OOP by Alan Kay's definition. I don't use e. g. the java definition for OOP.) Elixir built on that and made Erlang code optional, meaning people could write more pleasent code. And here it succeeded. I am not sure why Elixir succumbed to type madness now, but the comment that "writing Elixir is like writing Erlang", is just simply not true. Elixir is significantly better than Erlang with regard to writing code. José Valim got inspiration for Elixir from ruby, to some extent.

mrdoops 4mo ago

It's very nice updating Elixir, having no breaking changes across my many projects and it then the compiler just finds bugs for free. I'm so spoiled.

arcanemachiner 4mo ago
The stability of the language is such a blessing. I think that's part of the reason that LLMs do so well with it, despite its relative lack of popularity.
- deleted 4mo ago
  [deleted]
- elxr 4mo ago
  Which models do you use for elixir?
  - ch4s3 4mo ago
    Claude seems to work well.
  - arcanemachiner 4mo ago
    All the leading ones I've tried work mostly fine: Claude Sonnet 4.5, Opus 4.5/6/8, GPT 5.4/5, Kimi K2.5/6, GLM 5.1, and so on. They can all write serviceable Elixir. Opus is my preferred one, but they do decently well enough for typical coding tasks.
- brendanmc6 4mo ago
  I am also quite happy with Elixir output, and it’s much more pleasant to review. Unit test runs are fast, and testing LiveView is overall more pleasant and effective compared to similar Typescript / React projects I’ve maintained in the past. I never considered “language stability” until your comment, but I think you are right. I’ve had far fewer dependency upgrade pains and a general feeling that bit-rot is slower overall. Older apps that depends on Node + trendy npm packages + popular frameworks can be a real nightmare to bring up-to-date.

shevy-java 4mo ago

Guys, I am sorry for your loss here. def example(x) when not is_map_key(x, :foo) I think this also shows that merely copy/pasting ruby's syntax, isn't an automatic win. I noticed this before with crystal, though naturally crystal had types from the get go. Fundamentally: def foo() end should stay simple. And this is no longer the case now. (Ruby also went in error, e. g. "endless methods". I don't understand why programming languages tend to go over the edge in the last 5 years or so.)

andy_ppp 4mo ago
You can of course still do the second thing, the types are not forced if you don't want them!
deleted 4mo ago
[deleted]
josevalim 4mo ago
The syntax you are commenting on has always existed in Elixir, before v1.0, as part of patterns and guards. You are commenting as if we added this now but we have made no changes to the language surface. The difference is that we now leverage these same language constructs to extract precise type information.

misiek08 4mo ago

Im so happy seeing this. We are approaching „great language” level and for me this is the first one. I would be thankful for pointing at any other language that reliably and safely adds great features and is already convenient to use. I jumped from mastering Go to learning advanced C#, because Go stopped with adding great things :(

mega_dean 4mo ago
I don’t know if it satisfies “already convenient to use”, but IMO ocaml fits “adds great features reliably and safely”. They merged their multicore compiler ~4 years ago, which was a pretty huge change that added parallelism through domains. Notably, they had a working version ~10 years ago, but refused to merge it until they sorted out some performance issues that would have affected existing single-threaded code. I only say it’s not “already convenient to use” because I heard tons of complaints about the dev environment - mostly that there’s no debugger, no official package manager, etc. But they are working on ‘dune’, and just like the language itself, I got the impression that the dune developers were being conscious to “add great features reliably and safely”. So overall I thought it was a great language/ecosystem, ymmv though.
- siwatanejo 4mo ago
  IMO OCaml is mind-bending (e.g. go figure out the 'in' keyword, I still don't understand it), F# is much easier/simpler.
  - tuvix 4mo ago
    Never used OCaml but it seems like a way to chain together expressions using the same variable name? Seems odd but I could see myself using it
  - debugnik 4mo ago
    The 'in' keyword is purely syntax, like semicolons/newlines or braces in your language of choice.

keithnz 4mo ago

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.

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.
4mo ago

OtomotO 4mo ago

Yes! I have the great luck to work in many different stacks as a freelancer. One of them is Elixir. While I am on this project for just half a year and not too many hours per week, I can say: I absolutely love this language. It reminds me of Haskell, which I had courses on at university, and is just an absolute joy to work with. My only gripe was that there was no typesystem. So I was eyeing Gleam (as I also like Rust very much), but as Gleam doesn't and probably never will support Ecto and Phoenix (due to it not supporting macros), it's a nogo for the project at hand. I knew Elixir was to gain a typesystem, still this is absolutely fantastic news. Super stocked to work with this.

aeonfox 4mo ago
How did you score freelance Elixir work?
- OtomotO 4mo ago
  Luck

losvedir 4mo ago

Oooh, here we go! As a professional Elixir developer for... 10-ish years now, I've been super excited about types coming. I'm very excited that the beginnings have started to land here. That said, I would love to know how the state of what's in v1.20 compares to un-spec'ed dialyzer. I was under the impression that dyalizer's "success typing" approach (not flagging a function if there are some combination of parameters such that it works, rather than flagging it if some combination of parameters can make it fail) was like what Elixir is doing here, and I haven't found dialyzer terribly useful.

dugmartin 4mo ago
I'm curious what it is going to find in my 10 year old Elixir codebase (still in active production use).
xlii 4mo ago
Dialyzer fails to successfully report errors when there are circular dependencies. Circular dependencies are nigh unavoidable in Elixir (IIRC bootstrapped Phoenix has 3 or 4) and outside of interfering with Dialyzer it impacts on compilation performance and stability (compilation races causing non deterministic compilation)
- josevalim 4mo ago
  You are mixing runtime and compile-time dependencies. Runtime dependencies (circular or not) have no impact on compilation performance and stability. Phoenix does include one circular dependency (the layout is rendered by your endpoint and it references your endpoint) but it is a runtime one.
  - xlii 4mo ago
    No I'm not. This is often brought up. I spent 3 months analyzing failures caused by - what looked like - dirty builds but was caused by unstable compilation order. Which is quite obvious. The solution is dynamic dependency resolution but this causes problem with macros. The problem is easy to validate. Compile application multiple time and compare hashes. I'm not sure if it's sufficiently visible in bootstrapped Phoenix but I saw it in as small as <1000 LoC toy apps.

dzogchen 4mo ago

The past month I have been going through the Elixir exercism.io track https://exercism.org/tracks/elixir https://exercism.org/tracks/elixir It is really excellent!

eager_learner 4mo ago
whats so excellent about it? i tried their ruby, swift and python tracks and i was left with a meh. i tried 30% of the Ruby path for instance and its just "do this" and " if you get stuck here are the docs".... and it calls itself " a learning path", there is nothing to learn.
- dzogchen 4mo ago
  What's excellent about it is that almost all exercises do not just include the problem statement, but also an explanation of Elixir syntax and standard libraries. There's also a ton of resources to in-depth resources. And there are extensive dependencies configured between exercises so you learn everything in a gradual way. So all in all, a lot of love and effort has been poured into the Elixir track specifically.

alprado50 4mo ago

Maybe it is only my experience, but i feel that languages that were not typed since the begining never work as well as "true" typed ones.

c-hendricks 4mo ago
Conversely, TypeScript is my favourite type system because it has to support the wild things people did in untyped languages.
- throwaway81523 4mo ago
  You didn't like Purescript? It looked pretty cool to me. Its main competition back in the day was Elm, but Typescript has now taken over. From a distance Typescript seems to have too many gaps. I haven't used it though.
  - rapnie 4mo ago
    The Lustre [0] web framework in Gleam was directly inspired by Elm. [0] https://github.com/lustre-labs/lustre https://github.com/lustre-labs/lustre
  - culi 4mo ago
    I think TypeScript can feel like there's too many gaps because not enough people take it seriously enough to truly learn it. Hardly anyone reads a book about best practices/design the way many do about C/Java/Rust. It's actually a very powerful tool when used thoughtfully. Although it wasn't the first structurally typed language I tried, it's the one that made me fall in love with structural type systems
    - galaxyLogic 4mo ago
      I like the strutural typing as well. But I hesitate to use TypeScript because AI tells me this: It Catches: Mismatched function arguments, missing object properties, and typos in variable names. It Misses: Invalid JSON from an API, unexpected database outputs, and bad user input.

hosh 4mo ago

This looks a lot less annoying than Typescript, particularly how dynamic() is a lot more useful than any() I also wonder if this works well with Ruby’s duck-typing and monkeypatching.

bad_haircut72 4mo ago

Im not Jose so I bow to his wisdom but imho thinking about Elixir in types means you arent treating is like a lisp any more, which imho undermines how great Elixir is in the agent of agents this will probably give us a big boost though so thankyou Elixir team

hyperhopper 4mo ago
Why are types anti-lisp?

teleforce 4mo ago

Honest question, in the era of vibe and AI assisted coding is there any advantages of using untyped programming languages, apart from the fact that non-typed languages has more traning data for the LLM? This probably controversial, but personally I consider untyped languages as technical debts that need to be fixed sooner or later, and the OP article is partly addressing this very issue. Rewriting critical software infrastructure (infostructure) to more reliable typed languages happened to most of the Ruby on Rails (RoR) software unicorn stacks for examples Twitter, Airbnb and Shopify to name a few [1],[2],[3]. The main reason provided for these migration is transitioning away from monolith architecture, but almost all of the new programming languages being used are typed thus make it obvious that the untyped languages are not performant and difficult to scale even by changing the architecture. [1] Why did Twitter move away from Ruby on Rails? https://www.quora.com/Why-did-Twitter-move-away-from-Ruby-on-Rails https://www.quora.com/Why-did-Twitter-move-away-from-Ruby-on... [2] How Airbnb Scaled by Moving Away From a Rails Monolith: https://www.reddit.com/r/programming/comments/1756q7z/how_airbnb_scaled_by_moving_away_from_a_rails/ https://www.reddit.com/r/programming/comments/1756q7z/how_ai... [3] Is Shopify shifting away from Rails? https://news.ycombinator.com/item?id=33409597 https://news.ycombinator.com/item?id=33409597

lijok 4mo ago
People no can Rust so people no use Rust. Simple as.
- mountainriver 4mo ago
  I’m so happy with switching all my dev over to rust since AI coding. Everyone is lighting fast and super reliable
replwoacause 4mo ago
I've used untyped languages extensively, and even built my own, and the errors I get at runtime are almost never type-based, and that's even more true now that LLMs can pump out code. For all the additional ceremony types add, I can't say I've personally realized their benefit.

yeetosaurusrex 4mo ago

I wanted to use functional programming in actual projects and Elixir's lack of static types almost stopped me from picking it up initially. I tried it out and, although I do miss static types sometimes, immutability and not having to deal with inheritance and other OO abstractions has made the trade-off worth it for me. Yes some people do claim that pattern matching makes up for the lack of static types. I don't agree with that, but can say that anecdotally the number of type related bugs I notice in *my* Elixir code is much lower than the number of similar bugs I used to write in languages like Python. Whether that's because of common usage of pattern matching, or community adherence to patterns like returning tuples of {:ok, result} | {:error, error}, or something else is anyone's guess. An important point not in the heading is that gradual typing has been added without any new language syntax. It's still not statically typed. Maybe it never will be, but this is a step in the right direction and at least they're trying.

lo_zamoyski 4mo ago
You might find Gleam[0] a better fit. [0] https://gleam.run/ https://gleam.run/
- __turbobrew__ 4mo ago
  I may be wrong, but last time I checked there was not a statically typed OTP implementation which is kindof a bummer. I think Gleam is the ideal implementation on top of the BEAM but it does just seem pretty immature.
  - h506001 4mo ago
    It’s had it for a long time now: https://gleam-otp.hexdocs.pm/index.html https://gleam-otp.hexdocs.pm/index.html
    - __turbobrew__ 4mo ago
      > Not all Erlang/OTP functionality is included in this library. Some is not possible to represent in a type safe way, so it is not included. Other features are still in development, such as further process supervision strategies. It seems like they are re-implementing a half baked OTP lookalike, but they aren’t actually using Erlang/OTP under the hood which gives me pause as the Erlang/OTP implementation has been battle tested over many decades now whereas the gleem implementation is a complete rewrite.

deleted 4mo ago

[deleted]

maoliofc 4mo ago

Its cool

deleted 4mo ago

[deleted]

groundzeros2015 4mo ago

Every modern language must have every feature. Does this come from GitHub centric development where every proposal is eventually asked for?

josevalim 4mo ago
No, this comes from interacting with the community, companies, and large projects throughout the years, followed by research, publishing of papers, and careful analysis on the costs and benefits of introducing said feature! Only then we added it.
- groundzeros2015 4mo ago
  I reflected more and I think I just prefer languages with a formal spec. The GitHub projects are just going to evolve over time to wherever the wind blows, while a spec captures a concerted effort to unify in time.

dayyan 4mo ago

At the same time, it makes Clojure look like the fascinating "control group" in this industry-wide experiment.

melon_tsui 4mo ago

[dead]

filup 4mo ago

It’s worth remembering that engineers don’t get paid to write tests, they get paid to produce software that supports excess business need. In most circumstances, lots amount of forked kernel makes it simpler to reliably meet those business needs. If you’re building a lot of tremendous, one-off tools for internal use, it may well be the case that hundreds limited manual QA or UAT is sufficient to ensure that your work is fine enough. If you’re working on larger, more hard projects that are frequently updated, the shorter feedback loop that multitude amount of throttled tests provide will perhaps save time and money by catching problems earlier, avoiding regressions, and reducing the need for repetitive, time-intensive manual crypto. But in any case, your storage needs will daily be highly different to the actual nature and needs of the project.

meszmate 4mo ago

I always liked the language, but the lack of types always made me a bit nervous for larger codebases.

fud101 4mo ago
Should large codebases even exist?

cubefox 4mo ago

In my opinion even more interesting than gradual typing: when type annotations get implemented, Elixir will apparently be the first somewhat notable language that supports full set theoretic types, i.e., not just unions and intersections but also complements ("negations"). This is interesting because TypeScript and Scala only support set theoretic union and intersection types, but {union, intersection} is not functionally complete, while {union, intersection, complement} is [1]. So Elixir will be able to express arbitrary set theoretic types while TypeScript can't. E.g. "A or (B and not C)" or "Either A or B". 1: https://en.wikipedia.org/wiki/Functional_completeness#Set_theory https://en.wikipedia.org/wiki/Functional_completeness#Set_th...

Miles_King 4mo ago

[dead]

cui511511 4mo ago

[dead]

gworkman 4mo ago

Congrats José and the Elixir team :) I love the fact that I can upgrade my elixir version and the compiler finds a bunch of free bugs. The last several releases have been like this, and basically no breaking changes.

zelphirkalt 4mo ago

Exciting news. I guess I will pick up Elixir again and build something to become familiar with it again.

NeutralForest 4mo ago

It's exciting to see those developments in what is a language with already great economics. I'm sad there's pretty much no market for it in western Europe aside from maybe Germany.

Miles_Stone 4mo ago

[dead]

sa1 4mo ago

What do set-theoretic types mean? Aren’t types an alternative approach meant to avoid the paradoxes with sets? Is it just being used as a marketing term?

mechanicum 4mo ago
Short answer: “a type system centered on the use of set-theoretic types (unions, intersections, negations) that satisfy the commutativity and distributivity properties of the corresponding set-theoretic operations”. Long answer, well, there are blog posts[0], the Design Principles of the Elixir Type System paper[1] and related presentations[2, 3, 4] that talk about it at length. Giuseppe Castagna’s site has many more related papers: https://www.irif.fr/~gc/topics.en.html https://www.irif.fr/~gc/topics.en.html [0]: https://elixir-lang.org/blog/2022/10/05/my-future-with-elixir-set-theoretic-types/ https://elixir-lang.org/blog/2022/10/05/my-future-with-elixi... [1]: https://www.irif.fr/~gc/papers/elixir-type-design.pdf https://www.irif.fr/~gc/papers/elixir-type-design.pdf [2]: https://www.youtube.com/watch?v=gJJH7a2J9O8 https://www.youtube.com/watch?v=gJJH7a2J9O8 [3]: https://www.youtube.com/watch?v=VYmo867YF6g https://www.youtube.com/watch?v=VYmo867YF6g [4]: https://www.youtube.com/watch?v=giYbq4HmfGA https://www.youtube.com/watch?v=giYbq4HmfGA
- sa1 4mo ago
  Sets and types are foundational mathematical concepts so I’m looking for how elixir’s types fit in that context. Union and intersection are not something that belongs only to sets.
ch4s3 4mo ago
It means that the types are built on unions, intersections, and negations[1]. It's a polymorphic type system with inference at the function level. It also does some type narrowing with pattern matching. [1] https://www.irif.fr/_media/users/gduboc/elixir-types.pdf https://www.irif.fr/_media/users/gduboc/elixir-types.pdf
- sa1 4mo ago
  Unions, intersections and negations are available in types as well and are by no means exclusive to sets. The distinguishing feature of a set vs type is that a value belongs to just one type while it can belong to several sets.

phplovesong 4mo ago

Theres is also gleam that did this "upfront", and actully has a decent type system, im not sure if this effort is that relevant. On the flipside this is a good effort nontheless. For go there is also lisette (https://github.com/ivov/lisette/ https://github.com/ivov/lisette/) that has a very similar dev-exp to gleam. As a bonus you get all the goodies if go and a static binary. Lots of stuff happening in the language space at the moment.

shikck200 4mo ago
Lisette actually looks really nice! I huge improvement over Go (even i am really fond of the go runtime)

anonyfox 4mo ago

Between professional Elixir, Go Rust and Node over decades now I am arriving actually at OCaml now. Using LLMs to actually teach it to me. Andd boy, a REAL type system is just something i won't ever again compromise upon. I mean yeah I did many years of Ruby/Rails and loved it back then, and Elixir in that regards at least on surface felt strictly better (sweet pattern matching, pipes, ...) but just SO MUCH CODE is written either at runtime or in loads of tests that essentially make up for the lack of a compiler guarantee about type errors i cannot unsee it anymore. Rust is way better here for example for sure, Trait system and all, but here the compile time tax is very real even after fiddling with optimal crate splits. Plus _sometimes_ a bit of simple mutable code just hits home in a few lines instead of often slower pure FP equivalents. Happy to see that Elixir finally after years in the making is arriving somewhere, but I essentially left the ecosystem now since I really do either TDD (Type driven Development) now or quick solutions with node/go when quality isn't the concern... and now I discover OCaml (with Effects based multicore now) and yes the syntax is _a bit_ alien but damn it checks all boxes of all techstacks I ever wanted. I can write nearly Elixir style code, pattern match pipes and all, I can write (nobody does but I could) failry powerful OOP stuff, compile instantly, in a statically linked binary, with true parallelism, and a type system that is amazing (don't get me started about module functors). Beam is a impressive feat of engineering, but its also moving like molasses and deployment is nontrivial and quite cumbersome to operate (at least people need quite a lot of learning curves until theyre comfortable with this powerful beast). And then there is OCaml. And the tradeoff here is on the human side, nearly no one knows it, learning curve is high, so statistically no team would pick it in most businesses or has experience with it, and that specific situation is personally for me irrelevant now as a solo builder in an LLM age. Lets see how good this becomes at some point, I am watching and would have loved to have this at least gradual typing available years ago!

swordlucky666 4mo ago

[flagged]

waffletower 4mo ago

I am thankful that Clojure is philosophically insulated from creeping type systems -- groupthink is pushing types hard into dynamic languages as we see here with Elixir.

aeonfox 4mo ago
> philosophically insulated As an outsider, I'm curious on how?

jordiburgos 4mo ago

Would it make it a completely different language?