Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elixir v1.20: Now a gradually typed language

elixir-lang.org

Post reply on HN
Print view View original

301–310 of 426 posts

Re: Elixir v1.20: Now a gradually typed language

#301

Post by nesarkvechnep »

neya wrote: post #241
yeetosaurusrex wrote: post #177

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

If you use Phoenix, using types at the data model level using changesets and then trickling them down all the way to the UI is a very good compromise. As changesets provide type validations out of the box too.

Yeah, one of the worst practices. I've been working with Elixir professionally for 6 years now and I still see this sh*t everywhere. Bad APIs, bad UIs because someone coupled themselves to the database structure and can't escape. List of memberships? Keep them as a list with the same fields as the junction table. Top-level APIs taking maps with string keys as "params" so they can very easily be cast for a changeset.

Re: Elixir v1.20: Now a gradually typed language

#302

Post by arcanemachiner »

elxr wrote: post #170
arcanemachiner wrote: post #142

Earlier quoted context omitted.

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.

Which models do you use for elixir?

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.

Re: Elixir v1.20: Now a gradually typed language

#303

Post by _danielle_ »

rapnie wrote: post #114
lawn wrote: post #63

Earlier quoted context omitted.

Gleam doesn't have macros, which many Elixir libraries (such as Phoenix and Ecto) uses to great effect. Gleam for example has issues with verbosity of decoding/encoding json whereas in Rust you derive serde and in Elixir it's just a function call away. Elixir has a more mature ecosystem. While you can for example use Phoenix with Gleam (or some other Gleam framework) the experience just isn't the same. The big draw w…

> and being able to compile to JavaScript Apparently it is not that difficult to add different compiler backends. There was a presentation [0] recently about adding wasm support as a compiler target. The implementation was quite far along, including support for the wasm component model. [0] https://www.youtube.com/watch?v=UQ0--ODjiDk

Just to add a slight correction here, support for the wasm component model wasn't added in the target I wrote

Re: Elixir v1.20: Now a gradually typed language

#304

Post by flexagoon »

misiek08 wrote: post #73

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 :(

If I understand correctly that you think Elixir is not yet "convenient to use", I suggest you still give it a shot if you haven't. I'm generally a huge hater of dynamically typed languages, and I still love using Elixir.

Re: Elixir v1.20: Now a gradually typed language

#305

Post by flexagoon »

satvikpendem wrote: post #41

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.

They're different languages with different syntax and different features. Them using tge same VM doesn't really make them competing products, just like Java, Scala, and Clojure all use JVM and yet are all different languages

Re: Elixir v1.20: Now a gradually typed language

#306

Post by __jonas »

sph wrote: post #288
losvedir wrote: post #88

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

I know this is blasphemy to the average HN reader, but as a professional Elixir developer for 10 years, never have I felt the need for stronger compile-time type guarantees. None of my production services have had downtime or crashes because of type errors. Sure, at times, for very data-intensive sections of the application I would have loved something a bit more complex than dialyzer, but the guarantees offered by O…

I wouldn't say it's blasphemy, but I don't really understand the argument about how this relates to 'the application crashing and causing downtime'.

I don't have your level of experience with the language, but I have a personal project written in Elixir, and I do not feel very confident about parts of it that don't have complete test coverage, due to the lack of static typing.

I'm talking about things like: Is this pattern match exhaustive or is there a possible permutation I forgot / specified wrongly, which may then cause a match error at runtime, breaking a particular feature? (of course not bringing down the whole app due to OTP!); or if I change some keys in a map / struct in refactoring, did I forget to change them somewhere else in the application, introducing another error that is only caught at runtime?

Both of these have happened to me, I can even give you examples from code that is not my own – for my project I use a snapshot testing library by an experienced Elixir developer, and while using it I encountered two runtime crashes due to data being in the wrong shape and failing a (function clause) pattern match:

https://github.com/zachallaun/mneme/issues/85

https://github.com/zachallaun/mneme/issues/105

Proper static typing would make it very hard to write bugs like this. In Gleam for example, the compiler checks the exhaustiveness of your pattern matches against the type of the data you're matching against, and forces you to handle all possible values.

Re: Elixir v1.20: Now a gradually typed language

#307

Post by neya »

nesarkvechnep wrote: post #301
neya wrote: post #241

Earlier quoted context omitted.

If you use Phoenix, using types at the data model level using changesets and then trickling them down all the way to the UI is a very good compromise. As changesets provide type validations out of the box too.

Yeah, one of the worst practices. I've been working with Elixir professionally for 6 years now and I still see this sh*t everywhere. Bad APIs, bad UIs because someone coupled themselves to the database structure and can't escape. List of memberships? Keep them as a list with the same fields as the junction table. Top-level APIs taking maps with string keys as "params" so they can very easily be cast for a changeset.

This was the only out of box solution when Elixir didn't support types. So, if you really did Elixir professionally for 6 years, you'd know that by now.

> Bad APIs, bad UIs because someone coupled themselves to the database structure and can't escape.

If you don't commit yourself to the database structures you defined at the time of application creation, then it just reflects poor planning and architecture overall as that is one of the very first things you do.

What you describe is an approach a lot of NoSQL fans use - use whatever works then, worry about datatypes later on. That's how you shoot yourself in the foot.

> List of memberships? Keep them as a list with the same fields

Again, using embeds_many or has_many works well too, using changesets - which is my point exactly. Not sure where the disagreement is here.

Your account is full of just ragebait comments at a quick glance, so I'm just going to leave it here.

Re: Elixir v1.20: Now a gradually typed language

#308

Post by rapnie »

_danielle_ wrote: post #303
rapnie wrote: post #114

Earlier quoted context omitted.

> and being able to compile to JavaScript Apparently it is not that difficult to add different compiler backends. There was a presentation [0] recently about adding wasm support as a compiler target. The implementation was quite far along, including support for the wasm component model. [0] https://www.youtube.com/watch?v=UQ0--ODjiDk

Just to add a slight correction here, support for the wasm component model wasn't added in the target I wrote

That was a misunderstanding then, thank you for correcting.

Re: Elixir v1.20: Now a gradually typed language

#309

Post by epolanski »

elitehacker1337 wrote: post #202
teleforce wrote: post #163

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

I’ve been using Ruby and Elixir for over a decade. Pre-AI I used them for aesthetic reasons. The code was beautiful, and I disliked dealing with types. People without experience in dynamic languages tend to overestimate the number of bugs their type system is saving them from. It’s pretty rare that I run into a bug in production that a type system would have caught. They also overstate how much types help their AI ag…

C is among the most token efficient languages out there and is statically typed.

Typescript is very verbose thus it cannot compete with much denser languages on token efficiency.

By the way, the biggest reason many love statically typed languages, especially those that are quite expressive like TypeScript is for the domain and data modelling. Makes it easier to reason about the program and to refactor.

Re: Elixir v1.20: Now a gradually typed language

#310

Post by flexagoon »

7bit wrote: post #26
lionkor wrote: post #22

Earlier quoted context omitted.

Java has the JVM the same way that Elixir has Beam/OTP/...

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

> Download and run the Erlang installer Download and run the Elixir installer

No, you just install the elixir package from a package manager. Windows not including a proper one by default is not a fault of the language.

Post reply on HN