Live data from Hacker News

Elixir v1.20: Now a gradually typed language

elixir-lang.org

371–380 of 426 posts

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

#371
post #174

Earlier quoted context omitted.

This reminds me of the analogy of the smoking grandpa. I had a grandpa that was chainsmoking his whole life and managed to reach 90 and died of other causes. This does not mean smoking is "relatively safe".

This analogy is absolutely absurd and inappropriate on multiple levels. It reflects a parochial mindset that can't fathom contexts where dynamic type systems can be advantageous, such as a breadth of data processing applications. My favorite irony is how dynamic languages excel at concise translation between opposing type systems -- a very common data processing scenario.

You expand my comment to uses I had not envisioned. It was simply an analogy to correct the analogy of the OP comment.

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

#372
post #288

Earlier quoted context omitted.

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…

> people used to write server software in compiled languages feel the need for them because any runtime bug means downtime I keep hearing that but I don't think it's been true in many years? Whether it's Go, Java, C#, Rust... a runtime bug will only fail the request, not the whole server. FWIW, the main reason I like types isn't for the compile-time guarantees (although they're certainly nice). It's for documenting w…

That’s my top issue with Clojure: I see what the function does, but is it expecting a list, a string, either, or a map? The function may apply correctly, but what was it supposed to do? Java may be boring, but it’s surprise-free. In Elixir this is less of an issue because of pattern matching and very clear errors showing the actual arguments passes, that are unbeatable for debugging - you look at the log and can “see” the issue.

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

#373
post #326

Earlier quoted context omitted.

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.

Types do not inherently have any such restrictions. A value can belong to several types. In fact, if you posit types to have union, that necessarily follows.

I think they do, and as you mentioned you can explicitly remove such a restriction. Sets and types are once again two different kinds of objects in mathematical theory, and a set-theoretic type doesn’t seem to be based either on set theory or type theory.

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

#374

Earlier quoted context omitted.

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

>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). I used to hold similar opinion but D language, and this article by Patrick Li (HN JITX co-founder) who's the original author of little known but very powerful language Stanza changed my mind [1],[2]. He argue…

> Groovy also deserved a special mention, and the pudding is Grails.

Not sure it is much of a success. Groovy gets unreadable very fast, and the editor won’t help you. Gradle moved to Kotlin, and it’s 10x better in readability and maintainability.

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

#375

Earlier quoted context omitted.

I am well aware of that, its much much easier to account for this with regular HTTP handlers in other stacks though. The issue here is that you can call random functions if you guess the signature correctly. Even authorized/authenticated users can and will missbehave if given the chance.

To clarify, when you say "random functions", do you mean arbitrary event handlers like "handle_event("my_event")", despite the intended UI not presenting a way to call that event at the moment? Or do you mean any function in the LiveView module? The latter doesn't seem to be the case, and if it is would be alarming. The former is absolutely the intended behavior. The client can send events to the server, that's how t…

>"handle_event("my_event")", despite the intended UI not presenting a way to call that event at the moment?

Exactly this, didnt know how to phrase it as it was a while ago where i had this issue.

And thats absolutely not true for any HTTP handler as there's no way for people to easily break out of the intended behavior.

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

#376

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…

Statically typing the underlying message passing model used in Erlang is pretty hard, because the mailbox of a process can accept any type of message. And so, it cannot be statically typed in general, since anyone who holds a process id can shove a message into that mailbox.

In contrast, Go's message passing model works on typed channels. A channel has a type, and only accepts messages of the given type. The `receive` operator then acts as the merging data flow which solves the problem of receiving messages of different types. This is a design which amends itself far better to static typing.

Pattern matching isn't a substitute for static typing at all. The two features are entirely orthogonal indeed, and you definitely want static typing and pattern matching at the same time.

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

#377
post #253

Earlier quoted context omitted.

> to more performant runtimes and architectures in response to operational concerns at scale, which have a tenuous link to language The runtime performance and the language are deeply linked. None of the dynamically typed runtimes you mention are actually performance competitive with JVM languages.

Luajit and SBCL are very much performance competitive with the JVM? Why do you say that they're not? Random example benchmark: https://madnight.github.io/benchmarksgame/lisp.html

That's someone's 8 year old mirror of the benchmarks game website.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

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

#378

Earlier quoted context omitted.

To clarify, when you say "random functions", do you mean arbitrary event handlers like "handle_event("my_event")", despite the intended UI not presenting a way to call that event at the moment? Or do you mean any function in the LiveView module? The latter doesn't seem to be the case, and if it is would be alarming. The former is absolutely the intended behavior. The client can send events to the server, that's how t…

>"handle_event("my_event")", despite the intended UI not presenting a way to call that event at the moment? Exactly this, didnt know how to phrase it as it was a while ago where i had this issue. And thats absolutely not true for any HTTP handler as there's no way for people to easily break out of the intended behavior.

In most other HTTP handlers I've ever used, event handling would be handled by API endpoints, which are trivial for the user to target directly just by going to the Network tab in their browser's developer console.

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

#379

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…

> if you can use AI to achieve full test coverage, are there actual benefits in static typing for coding agents?

Full test coverage doesn’t tell you if the tests behave correctly. So you could prompt an AI agent to write 100% test coverage where those tests could be exercising all code paths yet contribute 0% to the story of what the code does. You need human understanding of what the desired contract is that the tests check.

Imagine a contract lawyer who blindly signs any contract that they are given: they aren’t doing their job. They ought to have an idea in mind of what their client’s goals and limits are so they can determine if a given contract fulfils those needs.

Types are a declarative contract, so they can be a lighter yet more limited way to enforce a contract. The compiler can verify if all the declared types across the program agree with each other. This is especially helpful with refactoring, such as ensuring the adding a field has been rolled out everywhere.

Types aren’t to be just checked by the compiler, but checked by the human authors too. That’s why explicit type signatures are valuable, especially if they are kept intelligible. They encode the different variations in state and possible branching on that state. So you can whittle your types down as a way of whittling the solution down to be more focused. The problem in your head is reflected in the types, and any simplifications in the types then simplify the problem in your head, and any tests derived from that understanding.

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

#380

Earlier quoted context omitted.

Honestly, I think you're framing this incorrectly. Twitter, Airbnd and Shopify all managed to get massive using Ruby on Rails. Maybe that was part of the reason why? I.e. they were able to move fast and developers were happy. I don't use Rails, so don't have any skin in the game. But who cares if you have to do a re-write once you get to that size?

Having been at a several places that have gone from framework-makes-us-fast to too-massive-for-the-framework, engineering velocity works as a function of how much mental context is needed and how many people/teams have to collaborate. As orgs grow, the only way to maintain velocity is to reduce mental context. Humans have to reason about their systems. In the half a dozen engineering orgs I have worked, each and ever…

There is almost nobody in startup world that will put the failure of a product/startup to choosing a dynamic language. Probably there are some exceptions where it matters but very few to count and in those cases yes use the most performant strongly typed, with string tools for static analysis and performance optimisations.

The real truth is that language preference (typed or dynamic) are more of a fashion choice in most companies where I was present than a pure technical consideration.

if you build your product by accumulating technical debt without any focus and effort toward simplicity and trying to make it do anything then the solution after many years is rewriting. But if you have the same culture and keep the same customers you will be in the sample place where you have started but now having different category of problems (eg network latency vs N+1s).

Maybe this is the "way of the startup" but lets not pretend that types can fix culture, engineering practices or product vision and good customer management.

Post reply on HN