4 ms·

Fantastic. Congratulations to the Elixir team! Something striking from the release announcement: > As mentioned earlier, releases was the last planned feature

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!

faitswulff 7y ago
I guess Elixir is "done" then? What could be the downsides to this?
- comboy 7y ago
  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.
  - deleted 7y ago
    [deleted]
  - derefr 7y ago
    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 7y ago
      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).
      - deleted 7y ago
        [deleted]
dudul 7y ago
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.
- brightball 7y ago
  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.
- josevalim 7y ago
  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.
jerf 7y ago
"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 7y ago
  "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 )
  - ashton314 7y ago
    Thank you. That's what I should have said. :)
  - derefr 7y ago
    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.)

faitswulff 7y ago

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

comboy 7y ago
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.
- deleted 7y ago
  [deleted]
- derefr 7y ago
  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 7y ago
    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).
    - deleted 7y ago
      [deleted]

dudul 7y ago

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.

brightball 7y ago
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.
josevalim 7y ago
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.

jerf 7y ago

"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 7y ago
"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 )
- ashton314 7y ago
  Thank you. That's what I should have said. :)
- derefr 7y ago
  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.)