josevalim

1. The cross module optimizations I mentioned above 2. Have a WASM target for the runtime itself 3. Make it easier to ship single file executables with the whole VM

But they are really “nice-to-have”s. I have been a happy user for 15+ years!

Comment · 3 months ago

Can you clarify which ones? We will be glad to improve them (or feel free to send a PR).

Comment · 3 months ago

There are multiple people working on the JIT within the last 5-6 years. The WhatsApp folks also contribute meaningfully.

I suspect once the Erlang/OTP team squeezes all performance in the JIT, they will look into optimizing across modules, which will probably open up many new possibilities, but it requires rethinking some runtime primitives.

Comment · 3 months ago

The Software Mansion folks designed it and we actually iterated on the designs on Figma, having discussions as humans, and exploring alternatives. They were lovely to work with.

I also worked on all of the copy myself, collecting feedback from core maintainers as I went. The new tagline was a suggestion from Theo which we iterated on. I did use LLMs as an assistant, but I did not ask it to generate the content.

Might as well use LLMs for the whole thing next time, since we will be accused of doing so anyway! :D

Comment · 4 months ago

I don't think these articles fully cover (pun intended) the claims being made.

First of all, we need to separate "types" from "static type checking". Elixir always had types and types by themselves won't eliminate tests. You can combine types with type checkers, as well as tests themselves (as described in the first article), to aid software verification. Plus many of the techniques discussed in the article (property-based testing, static analysis, etc) are available to dynamically typed languages too.

Some notes on the first article:

> For example, there is no test we could write that would show that our function never throws an exception or never goes in to an infinite loop, or contains no invalid references. Only static analysis can do this.

Static analysis is doing a lot of heavy lifting here. When applied to type checking, where it can prove absence of exceptions depends entirely on how expressive the type system and checker are.

For example, this Haskell function can fail at runtime even though it type checks:

    maxPosInteger :: (Ord a, Num a) => [a] -> a
    maxPosInteger xs = maximum (filter (> 0) xs)

If `xs` contains no positive elements, maximum fails. The type system does not rule this out.

As the article itself later discusses, proving stronger properties requires more expressive type systems, such as dependent types. Those systems can prove the absence of additional classes of failures, but they come with their own costs in complexity, ergonomics, inference, compile times, and so on. My recent ElixirConf talk touched on these trade-offs: https://www.youtube.com/watch?v=Ay-gnCqDw9o

But overall the article does not discuss coverage. Under some of the scenarios it presents, such as finite domains, exhaustive testing guided by coverage can prove the absence of bugs too. Additionally, some of the concerns the article has about Python, such as runtime redefinition and excessive polymorphism, do not really apply to dynamic languages like Elixir and Clojure.

> Correctness oracles abound. We have test suites, fuzzers and property-based testers, runtime sanitizers, static analyzers, linters, strong type systems, and formal verifiers. Any time such a tool can be made available to the LLM, we’ll reap the benefits in terms of not dealing with bugs the hard way, later on.

I completely agree with that framing. Static type systems are valuable tools, but they're one tool among many. My overall point is that I wouldn't draw the line at static typing as the "must have" mechanism for software quality, especially in the context of AI-assisted development where multiple correctness oracles can be composed together.

Thanks for sharing, those were great reads!

Comment · 5 months ago

Lovely!!!

Comment · 5 months ago

That’s very exciting! Is there anywhere I could follow you for updates? If you don’t want to share it publicly, and is ok with sharing it privately, my email is my username on gmail. Thank you!!

Comment · 5 months ago

Agreed on the guardrails bit. My point is that we still don't have much evidence that static types are an effective way to constrain the search space for coding agents, or how much value they add on top of other mechanisms. Redundancy can certainly be beneficial, but how much and at what cost?

On expressiveness, people often frame it as a dynamic-language goal, but a large portion of type system research is precisely about making type systems more expressive so they can describe a wider range of programs and invariants. This is clearly something both camps value. I suppose another interesting benchmark could be: how do coding agents perform across languages with different degrees of type-system expressiveness?

We may directionally agree, but it is hard to draw conclusions without measurements. Overall, I'd say this is much more of an open question than people give it credit for.

Comment · 5 months ago

Please file a bug report if you can indeed isolate/reproduce it (and please ping me on GitHub once you do)!