Elixir influences on JavaScript ES2025

Phil just posted this on EFS:

…interesting that some of the key updates to JavaScript appear heavily influenced by (or blatantly copied from) Elixir

Here are some blog posts about it:

https://medium.com/@alexdev82/whats-new-in-javascript-es2025-f9e99d04f45c

6 Likes

Unfortunately it seems like this article is fake AI slop (see the HN discussion).

It appears some of the proposals are real, e.g. pattern matching, but are nowhere near being accepted. The record proposal was withdrawn, which is a shame because native immutable data structures sound kinda nice. The pipe proposal is stage 2 at least.

It is interesting how many of these proposals are reminiscent of Elixir, though. And pattern matching has already made it into Rust and Python AFAIK, so that one probably has a good chance.

2 Likes

I have to this day never seen anything remotly resembling pattern matching to what we have on the BEAM, it’s a misnomer to call it pattern matching in Rust with the perspective of the BEAM.

4 Likes

I agree. But what about Prolog? :slight_smile:

2 Likes

Thank you, Erlang was heavily inspired by prolog!

But I doubt that most people who write JS and Rust is even remotely familiar with prolog. I myself have never written one line of it. I’m just not old enough and we did turbo pascal growing up. Although my dad might have shown me prolog.

2 Likes

Oh I certainly haven’t written any Prolog either lol. I do still need to take a good look at Datalog though, especially since I am interested in alternatives to SQL as you know.

I think at the end of the day pattern matching “feels good” in BEAM langs because the libraries and ecosystems are built for it. Plus it pairs nicely with immutability.

Similarly, the pipe operator feels good in Elixir because our standard library is built for it. But if you start working with e.g. :gb_trees you will find that it’s not so great, because the tree is the last argument!

So for interop with JS libraries maybe these features wouldn’t be all that useful, but the thing about JS is that it’s so widely deployed that you can write it in entirely different styles with entirely different subsets of the ecosystem pulled in. Functional/immutable JS is a whole thing. And I refuse to touch JS dependencies with an 11-foot pole anyway, so I can write whatever I want :slight_smile:

1 Like

Yeah, traditional datalog might be a no go for you as there is no concept of strings or integers.

Also, SQL was influenced but datalog, so it can’t be that bad :grinning_face:

2 Likes

Oh yeah, I meant more in the sense of studying the history. There are a lot of papers I need to read from those times. Datalog probably wouldn’t be for me, but it seems some are still trying to make fetch happen. Although those guys seem to have forgotten how to write about anything other than “AI agents”, so I’m not sure it’s going well.

The thing about SQL is that it has been influenced by a great many things because it is so inexpressive and inextensible that the only way to add new functionality is to further bloat the (incredibly bloated) standard with one-off features.

For example, apparently recursive queries (1999) were inspired by Datalog. Can you imagine if somebody “added recursion” to Python or JavaScript? What would that even mean?

2 Likes

That’s a nice blog and it’s clear that matchspec is heavily inspired by datalog, although I do believe that SQL weakness is a strength, as it is completely implementation specific so it is extensible.

I’m a sucker for pattern matching, but I can hear the average developer yelling that it’s not readable. And that is properly why SQL is so heavily used.

2 Likes

I love Prolog !

I only wrote an “hello world” with it, toyed a bit, and then when looking up documentation on the web, I found something strange and unknown to me called “Erlang”. That was some long time ago :slight_smile: And now I’m here, so <3 Prolog

(More seriously it was kinda fun to play with!)

I’m a sucker for pattern matching, but I can hear the average developer yelling that it’s not readable. And that is properly why SQL is so heavily used.

Yeah some coworkers do not seem to want to take advantage of it … though on this forum “I cannot live without it now” seems to be shared by most people.

2 Likes

I think it’s not a matter of taking advantage of it, and more an inability. Although we strive to tell ourself that as programmers then we love logic and analytics, but it is clear to me that most do not think in the way of prolog and datalog. If they did we would see it more used.

2 Likes

Very strange article cause I can’t find these proposals in tc39 repo

1 Like

I linked a few of the proposals above, they are real. But the article is fake.

1 Like

A lot of this is just a matter of what you’re used to, which is why it’s good that pattern matching and pipes and so on are propagating to other languages. It eases adoption for Elixir because people are already familiar with the style. This is actually how I started writing Elixir: I had become comfortable with a functional/immutable style of programming in languages like JS and Python first, so when I heard there was a whole language like that I was open to the idea.

Libraries like immutable.js probably drive a good chunk of Elixir adoption.

lol I’m not sure if I would describe SQL as “readable” either. It comes from the era of “what if we made programming languages look like English” and that really didn’t work out. What is interesting is that SQL has maintained such relevance when others (e.g. COBOL) have not.

1 Like

Lol, I was not arguing for anything to be more readable than the other. Quite the opposite. It was a jab at the whole notion around readability in general.

3 Likes

Well I do think a lot of it is just experience/comfort (like I said), but I also definitely think “readability” does exist. C is definitely more readable than x86 assembly. I don’t think that’s just because I’m more comfortable with C syntax. Some constructs are legitimately hard to understand; you know, “GOTO considered harmful” and all that.

Actually if anything I think I would be comfortable asserting that pattern matching is a bit more readable than if/elseif block spam in a language with C syntax. I rarely use if in Elixir.

3 Likes

I think you said it best yourself: it depends, and it depends especially on the problem you’re trying to solve, at times assembly is by far the better choice then C in readability when you work at that level of performance.

That’s exactly why I dread when anyone brings up readability as it is mostly used as a knee jerk reaction from developers that lacks maturity to admit their own inabilities.

3 Likes

Oh yeah, I guess it’s just a matter of interpretation. I would think of that as “sacrificing” readability for performance by dropping to assembly, but I do see the other perspective there. Sometimes the choice is between using “ugly” tricks in a high-level language or doing it the right way in a low-level language.

2 Likes

I have to strongly disagree here. Of course readability increases with familiarity but that doesn’t mean there isn’t significant variation in baselines. The difference is quite clear between languages that value clean, communicative apis and those that don’t, just as there is between frameworks, and code bases.

And I have had the opposite experience, of developers shutting their ears to criticism around readability/clarity because in their view only “objective” metrics like performance, or LOC, etc, matter when assessing code quality.

edit Also should say I think the point that languages having their own domains makes direct comparisons problematic, is absolutely valid, but even, or rather especially those cases illustrate the power of readability. Like many newcomers to Elixir I started with little to no knowledge of parallel computing, and although of course this made the OTP stuff more opaque than, say, the Enum module, the care put into expressing the problem the clear consistent way made it a lot easier to gain that familiarity.

4 Likes

I don’t think we’re disagreeing at all, my point with c vs assembly was to illustrate readability in a sense where you can read exactly how the code would be executed on a specific machine, C abstract that to a degree where you can write code more generally regardless of the architecture. And for some cases that comes with a performance penalty. But again all of this is beside the point and my opinion about knee jerk reactions as readability, since it all depends which to me then makes it a weak argument in general.

Case in point my own post about SQL above, which was made with tongue in cheek and as a jab to it all.

2 Likes