Live data from Hacker News

Elixir v1.20: Now a gradually typed language

elixir-lang.org

191–200 of 426 posts

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

#191

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…

IMO all of these higher level languages that were designed for humans have a very short lifespan at this point. The only thing propping them up seems to be loyalty for the most part.

theres nothing in common between humans and llms or llm training sets!

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

#192

Earlier quoted context omitted.

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.

I thought a big part of the reason for type systems was a sort of self documentation/contract? Especially if you need to work on an unfamiliar system with bad documentation. Also what about system boundaries? I prefer typed languages personally.

The benefit is not only about "documenting the contracts" but documenting the contracts in a way that we can trust those contracts can not be violated when the program is running.

That is a very good thing to help us reason about the program, we have invariants we know must hold true if the program does not stop in a type-error.

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

#193

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 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.

when i was programming elixir by hand i was making typing errors about 1 every half year or so. none took production down, most were caught and corrected quickly from logs. now im doing mostly llm elixir, almost all typing errors are caught in integration tests and only one has made it to prod.

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

#194
post #168

Earlier quoted context omitted.

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.

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

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.

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

#195

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.

Conversely, TypeScript is my favourite type system because it has to support the wild things people did in untyped languages.

Haha, it is actually my least favorite statically typed lang for this very reason.

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

#196
post #33

Earlier quoted context omitted.

Comments like this always confuse me as object oriented programs riddled with state are much harder to reason about to me.

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.

> 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/

Maybe porting your engine would be a great way to prove out Jank 1.0 when it arrives ;)

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

#197

Earlier quoted context omitted.

Not necessarily. Since the word "typed" language is not well-defined. For example, typescript is a fantastic language for marshalling data and UI state since it uses substructural typing instead of nominal typing. Libraries like kysely / other ORM libraries are great examples too and easy to use, whereas in fully typed languages like Rust you would end up having to use a macro library like sqlx or having to define st…

As I understand it TypeScript does not enforce types at runtime. Am I correct? If so that would signify to me it is not a "typed language", like say Java for instance. Types in TypeScript are more like "annotations" for docujmenting the program. Am I correct?

I have never worked in Java. But you can certainly ship TypeScript code that does not pass typecheck and it'll run fine in the browser because the browser runs Javascript, not typescript. Obviously a decent build process will prevent code that fails typecheck from shipping, but that's not a language feature.

For runtime types I've leaned on Zod or Effect schema,which can also generate static types for you.

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

#198

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

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…

IMO OCaml is mind-bending (e.g. go figure out the 'in' keyword, I still don't understand it), F# is much easier/simpler.

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

#199

Earlier quoted context omitted.

I've experienced this, but it's mostly because languages like Python and TypeScript give you way too many escape hatches. I get the intent: allow devs to convert their code base slowly. But in practice it just lets developers opt out of the benefits of typing to "save time" in the short run.

Well now Claude will add the types for me, so I don't need to use escape hatches

I haven't tried that but so are you saying I could basically code in JavaScript and then ask Claude to turn it into TypeScript?

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

#200

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 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.

I've been working with typescript for the past ten or so years.

A couple of years ago I did some contract work for a client who used Javascript.

I did some basic smoke testing to understand the state of the app and I was able to get lots of fun type errors on the server and client at runtime just by QAing the damn thing.

Post reply on HN