[ashton314]

Fantastic. Congratulations to the Elixir team!

Something striking from the release announcement:

> As mentioned earlier, releases was the last planned feature for Elixir. We don’t have any major user-facing feature in the works nor planned.

Part of me is a little alarmed—no one wants a language to stagnate. José makes it clear that this doesn't mean it's the last version:

> Of course, it does not mean that v1.9 is the last Elixir version. We will continue releasing shipping new releases every 6 months with enhancements, bug fixes and improvements.

Elixir is remarkably extensible. When I was first getting acquainted with the language finding macros with all the expressive ability of a LISP blew my mind. Making powerful macros a core part of the language meant that the language could grow. That in my mind is the most important part of any language's long-term viability.

Fantastic work all who contributed. Thank you for making a fast, functional, and fun language to work with!

[jerf]

"no one wants a language to stagnate"

In the sense of the language itself, I do. The language community should keep growing, libraries, frameworks, etc., but I'd like to see more languages qua languages declare themselves "done" sooner and more often, or failing a sudden cutoff, start seriously raising the bar on the next "new feature". There's a lot of good languages out there that were great in years 5-15 and then choked on all the features they kept adding to the core language.

[ksec]

"no one wants a language ecosystem to stagnate"

I used to be so happy when there was a new Java version every year, something new is good, something better is good, some hype is good. Now I am getting old I just want to use the same tools for the next 15 years. I mean it is not like most of the problem we are trying to solves were limited by the languages itself. ( Mostly the ecosystem around it )

[derefr]

A difference with Java is that new Java releases tend to come with changes to the JVM. The language's semantics and the abstract machine are intertwined in a way where the JVM might be changed to enable a new language feature, or vice-versa. And the JVM itself improving is pretty much always an unalloyed good, so people tend to look forward to releases of Java to see what JVM improvements it has in store.

Elixir doesn't hold the same position for its abstract machine. BEAM, the abstract machine, has its development intertwined with that of Erlang's language development, but not-so-much with Elixir's. Elixir can stabilize while BEAM+Erlang continue to evolve "underneath" it. Given that Erlang syntax is pretty much† always valid Elixir syntax, Elixir doesn't even need to change to expose new Erlang stuff!

† There were big changes when maps were introduced, but another change of that scale seems unlikely at this point. (Unless Erlang gets a mutable byte-array type or something.)

[pjmlp]

Unless you are using Android J++, then you get some Java features at the expense of de-sugaring.

[elcritch]

Also earlier versions of Java were a pain. The flexibility of a well thought out functional and dynamic language means new syntax to reduce boiler plate or extend generics don't need to be added. Compare Clojure to Scala for extreme examples in the JVM land. Similarly I think modern OO languages seem to be adding new syntax to handle OO complexities, e.g. much of the newest syntax additions to Python3 aren't useful (walrus operator? Well everything is already an expression... Etc).

In the end, I agree that the idea of a language which could be stable for a decade or more sounds fantastic! Given macros could add almost any other required feature should a good idea arise. Plus the BEAM and elixir compiler can continue improving performance and tooling.

[ashton314]

Thank you. That's what I should have said. :)

[pjmlp]

Programming languages are software products, when they are done, it is time to move on.

[dudul]

Honestly I'm happy to see that they're gonna slow down a little bit. You need a certain stability for the language to become more attractive. Think that the book "Elixir 1.6" was only released a few months ago, and today we're already getting Elixir 1.9.

Yes, of course 99% of the book is probably still relevant and all, but I believe it is important to brand a language as having reached maturity and stability.

[josevalim]

By the metric above, which is release numbers, we won't slow down because we will continue with two releases per year (this is our frequency since v1.2/v1.3). :)

However, in terms of new features, we have already been slowing down over the last releases.

[brightball]

FWIW, the new books they are releasing for Elixir and Phoenix are both titled "Programming Phoenix >= 1.4" and "Programming Elixir >= 1.6"

That they are willing to put that in a primary book title is pretty bold.

[faitswulff]

I guess Elixir is "done" then? What could be the downsides to this?

[comboy]

Lack of language improvement. Sure, you can do anything with macros, but then when you open some random open source library it may be using different macros (or macros that are named the same way but act differently) than those that you use. Putting something in the language forces everybody to use the same standard. It can be good and it can be bad.

[derefr]

There's a middle-ground stance that's pretty common in the Elixir ecosystem: five or six libraries get written to solve a problem over the course of a year or two, people play around with them, and then a common set of primitives gets factored out of those libraries and made into an interchange library that all those libs support.

That interchange library can then be integrated into the Elixir stdlib—that's what happened with DateTimes in Elixir—but there's no reason it needs to be. It works just as well to just keep the interchange-type library as its own tiny little dependency that all these libraries pull in.

[yellowapple]

This is one of the awesome things about Plug, in the sense that if your library or what have you targets Plug it'll work reasonably well (if not entirely seamlessly) in a Phoenix app, a Sugar app, a pure-Plug app, a $SomeOtherFramework app, or what have you.

Plug happens to be somewhere in between the two outcomes you've presented, of course; its development happens very closely to that of Elixir (and it's arguably a sub-project thereof), but it ain't a core part of the language itself (last I checked; maybe this has changed in recent years).