Elixir – HUGE Release Coming Soon | Hacker News Reader

Elixir – HUGE Release Coming Soon

genserver.social

135 pointsgregors77 comments

Hi everyone! I want to align everyone expectations and say this is not related to the Elixir language itself but rather the Elixir ecosystem.

The language has been stable for years and non-minor features always discussed upfront through several proposals. With that said, if you are interested on the work happening on types, I wrote recently about it here: https://elixir-lang.org/blog/2022/10/05/my-future-with-elixi...

This announcement is about a new project, which we are very excited about and working on for months. We hope to officially release it tomorrow (Thu UTC). We are dotting the "i"s and crossing the "t"s right now.

I was definitely not expecting this to make to the front page, I should perhaps be more careful the next time. :)

Can you at least give us a little tease as to what domain the new project is targeting?

Disappointed that it's not about the language itself, but congrats nonetheless. Looking forward to seeing what you all have done.

the Elixir metaverse? ;P

The potion of youth?

Elixir but it's a blockchain?

Is it related to NFTs? Crypto? Blockchain?

The announcement sure sounds one of those "we're joining the NFT hype train and it will be AWESOME!" type of announcements...

He has been teasing this for a couple of months now. This cryptic twitter post[1] would suggets something related to nx[2] as numbat is their logo and that is the alt text on that tweet.

The most out of the box thing I can think of is that one of the image generative models has been ported to elixir. That would be insane! That numbat twitter image is suspiciously 512x512.

[1] https://twitter.com/josevalim/status/1583551565381914624 [2] https://github.com/elixir-nx/nx

Doesn't sound out of the box to me- sounds like a pretty good guess.

ah, seems pretty clear you probably figured it out. very cool!

I'm sure it will be interesting but for HN discussion purposes let's wait until it actually exists.

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...

(Off-topic) As much as I love decentralization these Twitter alternatives have some really awful UIs. Feels like stepping back in time, although that's not always a bad thing.

They should get some of the cryptobros to help, they always had amazing designs for their useless services.

“must be the introduction of mutability and OOP!”

Hilarious

Or Global Interpreter Lock.

Maybe something more basic. Like GOTO's

I hope its a big update with static types

IIRC José recently said he was was gonna spend some time thinking about Elixir's approach to typing, so that's probably it.

My hope is a smaller runtime that works well for CLI tools. I'd love to use Elixir for small scripts I'd ordinarily use Go/Python for.

I had an idea years ago when I still had the young man’s dream about writing a programming language. It came after I took over a J2ME project that was trying to do a great deal of functionality in an 85K jarfile.

That idea was that there should be a little language inside of each big language that is used to implement the self hosting aspects of the language, and then a small set of additional libraries would provide a usable embedded variant of the ecosystem, good for small places and things that have to start quickly.

I like this idea. I believe Rust does something somewhat similar (though not quite) for processing compile-time procedural macros. We see somewhat similar, but external approaches in the Clojure ecosystem with Babashka and Joker (and probably a few others).

In general, I like this, but not every language actually needs it. Like, what would that even be in Python for example?

Something for PyPy perhaps? JITs written in the host language are the original use case I was thinking of, but that’s not the sole domain where it applies.

static types is the main thing that keeps me from putting more time into learning / using elixir.

Me too.

Every time I read statements like this from Jose

"This brings another discussion point: a type system naturally restricts the amount of code we can write because, in order to prove certain properties about our code, certain styles have to be rejected."

I can't but think few things:

- by compilers (in this case static type checkers) laws we all know that there are valid programs that won't satisfy the type checker and viceversa there's only a handful (none being production or development ready) of compilers powerful enough to infer all code bugs

- limiting the expressiveness of a language isn't necessarily a bad thing

I've noticed that people with a huge background in dynamic languages tend to have a natural refusal for static types. Lispers are a community with such an attitude, even the typed lisps like typed/racket seem to be born more to please people wanting typecheckers and academics than the userbase itself.

But I, and my mind, work the other way around: I want to think about the types first, I need them to express my domain and my DSLs, so I need an expressive type system able to translate my thoughts and validate all of my program with nothing but types. It's possible in plenty of languages (most famous one is TypeScript with its declare keyword) to do type-driven development and I can't really function without it.

Once a program has been well modeled, once I've seen the APIs, then and only then I get into implementation and it is by far the part I spend less time on.

Every time I read a lisp dialect without static types (most of them) my mind just doesn't work properly, I can't follow much. And I really believe that the lack of commercial success for many of these languages derives from how poorly non statically-typed languages scale when klocs and number of maintainers of a project start increasing.

The main question of the quote is: if we introduce a system that rejects a "large" amount of Elixir code, will developers adopt it? If some language features are only available for "untyped" code, will developers often forego types only to get those features? And if that happens, could we end-up "forking" the Elixir community, where part of the community uses some idioms and the other part uses others (which is a common complaint about large languages)?

The goal is not to reject types but rather to find a theory that mirrors the language as close as possible. I believe balancing these trade-offs will be essential to the adoption and success of a type system in Elixir.

I use Elixir whenever I can, and I would love a better type system (though I admittedly suck at using what Dialyzer already provides, which is extensive). I'm very excited to see where the current effort goes!

But absolutely, if new types break existing Elixir code and idioms it would result in a schism that would be devastating and disastrous to the Elixir community. I for one am really glad you are asking these questions, and FWIW I think you're doing exactly the right thing.

> I've noticed that people with a huge background in dynamic languages tend to have a natural refusal for static types. Lispers are a community with such an attitude, even the typed lisps like typed/racket seem to be born more to please people wanting typecheckers and academics than the userbase itself.

I feel like it's the opposite. It seems like we have this huge wave of a push for static types. The only way I can explain it to myself is that a bunch of people using dynamically typed languages finally came over to the static typing side. And I say this as someone that worked using statically typed languages for pretty much all of their career.

I get it for TypeScript and the frontend. The frontend is a huge, complex mess of interactions, in the same codebase. Static types are awesome there.

But the way we write most backend systems these days, IMHO, static types are practically a nothingburger. Sure, they were awesome when I was working on those millions of LOC projects back in the 2000s. But nowadays those millions of locs are spread across N projects which are separated by a typeless network boundary so I'm not looking at anything more than 50-100k LOC anyways.

So I just don't get it. Systems are written in a way that devalues static typing, but it feels like the demand for it is higher than ever.

As someone maintaining a moderately complex codebase in Python: static typing doesn't feel valuable until you need it. But then you really, really need it. Thank god for Mypy and type-hints.

I'd prefer something that can infer types in the simple case and have explicit types when dealing with huge complexity. Really, it comes down to having tight control around the shapes of your data, and that is incredibly valuable when you cannot keep the entire codebase/API/contract in your head. Quick navigation is a huge bonus too.

I also don't fully understand it. Maybe it's driven more by the ease of autosuggesting/completing in static typed languages than actually catching bugs. It will swing back like everything else and reorient on slightly different direction. This pendulum is quite slow though.

It's not satisfying to everyone, but if lack of types is hampering your desire to learn Elixir, check out Dialyzer[1]. It's certainly not perfect, but between pattern matching struct arguments and Dialyzer, I've yet to personally encounter a situation where it wasn't sufficient.

[1]: http://coolerranch.com/using-dialyzer-in-elixir/

Programs never have to be rejected; programs can be diagnosed (so we are informed) and run anyway.

Programs have to be rejected if there is no safe way to handle them at run-time, when for the sake of efficiency we removed the type bits from the data. (And not even always then; the programmer may have assured safety otherwise.)

Would that make it more difficult to implement the BEAM?

Same. I would love to see it get static types.

Yes, but there’s a PhD student working with Jose on this and I think the timeline was 18 months. My guess is it’s a joke around how stable everything in the Elixir world remains compared to other constantly evolving ecosystems.

I thought so too, but Jose Valim says "never before seen on Elixir or the BEAM", while Gleam exists and Jose undoubtedly knows about that project:

https://gleam.run/

Also meta has a static typing system for Erlang. Also, dialyzer exists. So if it's "never" he means set theoreic types, but there are incomplete set theoretic type libraries for elixir

By meta do you Facebook? If so just say that, it's confusing otherwise.

I had actually started typing Facebook, then remembered that it was Whatsapp, which post name change is technically not Facebook but actually meta, so I submitted as meta for correctness

Meta is also WhatsApp, which is what I know was part of the erlang community.

That would be neat! I would really like it if added optional typing like Python or PHP.

I thought Erlang lacked a type system.

How would this work since Elixir compiles into BEAM byte code (via Erlang Abstract Format)?

Do you need to have static typing in your byte code for static typing at the language level to be useful?

I ask because the JVM lacks static typing[1] at byte code level but Java and Scala have it at the language level where it seems to be useful for correctness and performance.

1. https://wuciawe.github.io/jvm/2017/03/04/notes-on-jvm-byteco...

the compiler can type check source code for any obvious insanities, and thereby catch and prevent, at compile time, a subset of what would be runtime errors.

that's the idea anyway. (i worked on v8 for example, and other compilers, and typescript does something similar targeting javascript)

Sure but so does javascript, it doesn’t mean it can’t be added at compile time and add a lot of value.

I've seen his comment somewhere (on reddit?), it's not.

I thought Elixir was "feature complete".

https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-releas...

Granted, that doesn't mean it won't be worked on. But it does implies nothing "huge" will be happening.

It doesn't mean that the thing will be in the Elixir language. Nx was teased in a similar way and ended up being an external library.

That's what I'm thinking too, unless José has a secret Elixir branch. Might be a brand new tool.

What it likely means is that it won’t be a change to the language, but the addition of something stdlib or tooling related.

So is this a joke or is something actually on the roadmap?

I don't think Jose has had any announcements in the past that were jokes.

If it's related to cryptocurrency HN is going to explode.

It's not, but it would be hilarious.

I hope it is, because I've been putting off learning Elixir for too long and I want to feel like my procrastination has been justified.

Maybe a proper debugger?

Thanks, Jose. Really looking forward to it.

Any good guesses?

Finally, externally visible module constants (i.e attributes)!

Ok, probably not, but one can dream.

Zero-arity functions are your externally visible module constants. :)

Sure, but I find it less readable and more verbose than your usual constants.

Also you can't pattern match on a function return value IIRC. Or maybe I didn't find the right syntax, I get "invalid pattern in match" or "cannot invoke remote function inside a match" when pattern matching on function parameters.

There's also solutions with macros, but why complicate something so simple :)

Those are all good points.

When we talk about macros and function parameters, however, we want to avoid spreading multiple constants across multiple modules, because they lead to compile-time dependencies (and potentially long compilation cycles), so my go-to approach has been to define a single module with all of my constants (they could be macros or not, it changes per project).

I wonder if this could be a matter of promoting certain styles rather than adding language features?

> Also you can't pattern match on a function return value IIRC.

You definitely can. A function return value is just any other value and you can pattern match on it directly, or with the `case` or `with` constructs.

I think the poster means "you can't pattern match with a function value

I don't see how this would be useful.

What would be the correct way to pattern match here?

  def foo(<I want to pattern match the value returned by GreatModule.constant_substitute()>), do: "bar"
 
  def foo(value), do: value

Use a `case` in the body of the function. Why do you absolutely need to pattern match in the function header?

Module constants are externally visible by using Module.register_attribute

Native system target compile for beam/elixir.

I suspect there's (understandably) a 0% chance of this ever happening, but it sure would be huge.

The JIT could probably be abused to make that happen, on amd64 and arm64 anyway

Something LiveView related, is my guess.

Perhaps it's getting a new feature, like PWA support? Or maybe the API is hitting 1.0?

Automatic function/task distribution across beam nodes.

A new "relup" process for kubernetes deployments.

terminal output for phoenix liveview.

Well crap, I've been writing that all week

Please sir, I'd like to subscribe to your newsletter.

Look for ExTerm around dec 25

What a great christmas present !

Is this based on extermbox ?

replacement for dialyzer?

IIRC there already was a replacement from whatsapp. Ive heard good things but not used it myself.

I'm mistaken, the FAQ ( https://github.com/WhatsApp/eqwalizer/blob/main/FAQ.md ) mentions that its not a replacement.

Reply on news.ycombinator.com