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

271–280 of 426 posts

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

#271

Post by josevalim »

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…

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

Author here.

Type systems restrict which programs can be expressed and increasing expressiveness often requires increasing type-system complexity (which, speaking from experience, both humans and agents will struggle with). Plus they are not the only mechanism to assert correctness (they only validate a subset of your program correctness and do not replace tests) and you are still on your own when it comes to actually recovering from unexpected errors (something Erlang/Elixir were designed for).

I'd say there are two flip sides to your question:

1. Given types do not replace tests, if you can use AI to automate full test coverage, are there actual benefits in static typing for coding agents? The downside of tests for humans is that we suck at writing them (but guided agents can do better) and they can take time to run (which agents do not care)

2. Do we actually have any data or evaluations that show which typing discipline is better for agents? The only benchmark I am aware of [AutoCodeBenchmark] has Elixir come first (dynamic) and C# as second (static), so it doesn't answer the question. There are other benchmarks that show dynamic languages require fewer tokens to solve problems (but that's not a metric I particularly care about)

My gut feeling is that local structure, documentation, quality and quantity in the training data, etc are likely to play a more important role than typing for coding agents. I'd also love to measure how agents perform on specific domains. If you are writing concurrent software, how does Elixir/Java/Rust/Go compare? But without data, it's hard to say.

[AutoCodeBenchmark]: https://github.com/Tencent-Hunyuan/AutoCodeBenchmark

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

#272

Post by tancop »

galaxyLogic wrote: post #188
meghprkh wrote: post #172

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?

its more than annotations, your code fails to compile when you get a type error at least with strict settings. if it type checks and fails at runtime that means youre missing input validation or using bad declarations for third party/legacy untyped code. or using some escape hatch like `myValue as unknown as MyType` in the wrong way.

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

#274

Post by [deleted] »

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…

[deleted]

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

#275

Post by OtomotO »

aeonfox wrote: post #164
OtomotO wrote: post #85

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

How did you score freelance Elixir work?

Luck

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

#276

Post by josevalim »

groundzeros2015 wrote: post #228

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

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.

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

#277

Post by bonesss »

aeonfox wrote: post #154
pdpi wrote: post #82

Earlier quoted context omitted.

> you don't get bugs related to typing because elixir is somehow magic, I've never followed Elixir particularly closely, but what I saw in some Erlang discussions was different. Discourse there was that you need to gracefully handle failure anyhow, so type errors can (should?) just get handled by the failure recovery machinery you're supposed to have anyhow. I disagree with that point of view, but it's much more defe…

OP might be referring to Jose Valim's 2023 ElixirConf talk where he's explaining why Elixir should go down the path of types. He gives a lot more nuanced take than 'types are useless', which is more like 'types are less useful than people think in the context of Elixir development'. (Which makes sense because he's in the middle of implementing a type system for Elixir.) https://youtu.be/giYbq4HmfGA?t=571

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

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

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

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

#278

Post by xlii »

josevalim wrote: post #266
xlii wrote: post #249

Earlier quoted context omitted.

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)

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.

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.

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

#279

Post by xlii »

simoncion wrote: post #267
xlii wrote: post #249

Earlier quoted context omitted.

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)

> ... circular dependencies ... compilation races ... Does Dialyzer understand Elixir? Last I knew, it could only process Erlang source code and BEAM files. Looking around, it seems like folks running Dialyzer against Elixir code are using some "dialyxer" thing. You talk about circular dependencies causing minor compilation troubles, so it doesn't sound like you're talking about types defined in terms of each other.…

There's dialyxir which is wrapper to Dialyzer and I found it work fine on pure (non Phoenix) code.

As for how the problem manifests: even obvious contract violations stops being shown (making it feel like "Dialyzer is useless") but the second tell is very long check times (tens of seconds up to minutes).

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

#280

Post by osener »

josevalim wrote: post #271
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…

> 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? Author here. Type systems restrict which programs can be expressed and increasing expressiveness often requires increasing type-system complexity (which, speaking from experience, both humans and agents will struggl…

In my experience restricting programs that can be expressed is a good thing, even more so with agentic engineering. The more guardrails there are, strong typing/TDD/computer use/..., the solution space shrinks and chance of a robust solution increases. Sure maybe this burns more tokens going in circles but it feels less like a slot machine more like a robot searching for a solution for a well-defined problem.

Devs have very strong opinions about dynamically typed programming languages. But reasons such as "exploratory programming", "expressiveness", "taste" that makes them feel good to program in for humans does not matter for agents. Agents don't care that the language "limits them" and prevents them from expressing the code in a succint way because it would not type check.

Post reply on HN