7 ms·

Elixir v1.4.0 released

229 points by njade 10y ago

themgt 10y ago
Coming from Ruby, Elixir feels like a powerful, beautiful language with a surprisingly radical but ultimately simple approach to concurrency thanks to Erlang/BEAM, and Phoenix is like Rails 2006, as far as the framework to sell Elixir's advantages to the masses. It's very powerful and scaling "just works". All Elixir needs now is a viable ElixirScript that can compile down to JS/WASM, and along with Nerves it's ready for world domination. ;)
- pmontra 10y ago
  If all you need in js/wasm is the functional layer of the language, that could be easy. If you want to add processes, that could be very hard. If you also want the supervisors, that's difficult but probably not has much as adding Erlang style processes.
  - pmarreck 10y ago
    What's stopping a compile of Erlang to JS via LLVM and Emscripten and just taking the expected performance hit?
    - Xixi 10y ago
      Erlang doesn't compile to machine code, but to bytecode that runs into the Erlang VM. So you would probably have to run the Erlang VM on top of javascript... I'm not sure whether it's possible, but it sure sounds heavy.
      - int_19h 10y ago
        With WebAssembly, you should be able to compile the Erlang VM itself to it.
    - bryanjos 10y ago
      There is the LLVM backend in Erlang as of version 17. I haven't seen much info on it. I haven't seen anyone try to go the whole process from Erlang code to LLVM to Emscripten to JavaScript. I am interested to know what hurdles there might be, performance, etc.
  - lawik 10y ago
    AFAIK the VM creates a thread per core (by default) and schedules Processes across those threads and stuff. I'd say this might be possible to do with Web Workers. Sounds like it could be fun, probably a challenge to make it fast.
- chao- 10y ago
  >All Elixir needs now is a viable ElixirScript that can compile down to JS/WASM On the off-chance you pulled that name out of a hat, or for the benefit of anyone else who might not realize you are referencing a real project: https://github.com/bryanjos/elixirscript https://github.com/bryanjos/elixirscript
- rubyn00bie 10y ago
  I'm not sure why you want to compile Elixir or Erlang to JS... Most of the magic of the language is provided by BEAM and OTP which for a multitude of reasons cannot be properly implemented in any JS engine/backend I'm aware of. If anything I'd think the abstractions of Elixir/Erlang would be cumbersome and very awkward when writing performant code which had to be transpiled to JS. The biggest reason being is BEAM can do preemptive scheduling, interrupting a running process to ensure all have equal execution time. This is a stark contrast to everything I know about how most any other VM or runtime work (which cannot preempt). While yes the language is nice, I think using something like Opal would provide most of the syntactic pleasantries while being easier to understand when it comes to tuning and debugging. If what I'm saying is nonsense, I'm missing the point, or short sighted please learn me! :)
  - jaredklewis 10y ago
    Even if Elixir had no concurrency goodness I would still prefer it to a language like JS any day of the week. JS is a mess of paradigms and features. Elixir has a small set of great features: modules, functions, pattern matching, immutable data structures, macros. Regarding your performance point, I'm skeptical. Is it really so easy to reason about the performance of even plain JS code? Maybe you're more familiar with the deep dark crevices of v8 and spidermonkey than I am, but I find v8 to largely be a black box in terms of fine tuning performance. Of course, the big picture optimization is simple enough, but that wouldn't change whether you are using plain JS, Opal, PureScript, or any other language. Yes, a BEAM elixir program can run parallel threads and ElixirScript won't be able to do that because in JS, there are no threads. That doesn't make plain JS faster, just means Elixir will be brought down to the same level as plain JS. I've used what I view to be equally foreign compile to JS languages (ClojureScript, Elm). They of course came with challenges, but fine tuning performance doesn't even make the top 10.
  - btown 10y ago
    With the right abstractions and (adhered-to) guidelines, a library in a non-preemptive language can allow your code to effectively yield to the scheduler so often that you get many of the benefits of preemptiveness. React is moving in this direction with their ongoing Fiber project [0] - since components are encouraged to be granular, and must be loosely coupled, the new React scheduler can take well-structured React code and plan the rendering of various subtrees with high levels of control. In fact, there's a TON of similarities between React's component model and the BEAM actor model: a component's "mailbox" consists of inbound props, outbound async callbacks to the component that requested its instantiation, and outbound assertions that the component desires to communicate props to new instances of other components. One could imagine a compiler that inserts a yield around the calculation done in each Elixir AST node, and/or one which allows first-class representation of React components as Elixir processes, complete with JSX-like syntax. Very interesting to think about. [0] https://github.com/acdlite/react-fiber-architecture https://github.com/acdlite/react-fiber-architecture EDIT: Should also add that the shared-nothing messaging model translates very well to the requirements for Web Worker interop, so you actually could get multithreading.
- retrogradeorbit 10y ago
  Just use elixir on the server, and clojurescript on the client.
  - kim0 10y ago
    Or clojurescript on both sides
josevalim 10y ago
Link to the official announcement: http://elixir-lang.org/blog/2017/01/05/elixir-v1-4-0-released/ http://elixir-lang.org/blog/2017/01/05/elixir-v1-4-0-release...
- qaq 10y ago
  Thanx for all the great work José we all really appreciate it.
- ptlu 10y ago
  thanks!!
_asummers 10y ago
Congratulations to José and the Elixir team! It will be nice to finally settle the bare words debate and fix all the new warnings and deprecations. We compile with warnings as errors, so that should be a fun morning when we upgrade.
sotojuan 10y ago
My favorite part about Elixir is that it doesn't try to reinvent the wheel. It's not an untested, trendy new paradigm or tool. It's based on decades of Erlang/BEAM/OTP experience and Ruby/Rails/last 10~ years of programming ergonomics. The only things that are added are those that actually add to the experience. An example: A large part of the Erlang standard library is not translated in Elixir. Instead, you call Erlang methods with a seamless interop. José & co. understand that there's no need to reinvent the wheel and no benefit in another abstraction. I like that. My least favorite part about Elixir is that it has become a "trendy" language among the web crowd. While the community is overall great, there's always a loud minority of "beginner experts" both claiming it's the best thing ever and deriding those for using other tools. I've seen a lot of random, unwarranted Rails bashing and Elixir shilling (never from a team member or community leader though!).
- jbhatab 10y ago
  What's wrong with getting excited about a new language and framework that's better? Being vocal about how awesome something is gets people involved which grows the community. A larger community translates to more educational material and tooling. I think zealotism has a fine line, but I don't think it's all bad. It's almost like protestors that believe in something strongly. Sometimes they cross the line, but them protesting gains visibility which results in change.
  - MrBra 10y ago
    Better than what?
    - erik14th 10y ago
      Erlang was developed to solve problems that are quite common in Web Development like concurrency, high availability and so on. I see Elixir basically as a user-friendlier version of Erlang with some added goodies. So I think it makes perfect sense for it to be popular among the Web crowd. It definitely has it's own problems(ease of deployment, package maturity, imo). But if your problem involves networks I think Elixir is at the very least worth having a look at.
transfire 10y ago
> [Kernel] Deprecate support for making private functions overridable. Overridable functions must always be public as they must be contracts Just lost interest. I thought Elixir was supposed to learn from Ruby.
- josevalim 10y ago
  Can you please expand on this a bit? Your comment is very vague. The comparison with Ruby here doesn't make much sense because private means different things in both languages and Elixir does not have inheritance.
- jkmcf 10y ago
  You'd think they'd learn from Java! Edit: Not a shallow dig, but I had lots of fun using a 3rd party library that had locked down a lot of methods which prevented some sales driven features...
- brightball 10y ago
  Personally, I've never seen the value in private functions in the real world. If you are in the same runtime and can see the code, what exactly does a private function offer you other than ensuring somebody has to duplicate the method to manipulate it. Professionally I've never seen a private function/method that had a purpose or benefit from being private.
  - _asummers 10y ago
    In Elixir especially, with everything being immutable, I don't really have to worry about state hanging around for my private methods to care about. I wind up just throwing private functions into little helper modules that can be tested independently. As far as benefit of something being private, an API does not have to be maintained if it is private. Once it's out there, you're locked into doing that for the duration of your deprecation window.
  - swsieber 10y ago
    They seem quite useful. Mostly signaling that things should not be used. What's the largest number of people you've workwe with on a codebase? I would assume the benefits aren't really all that much for small codebases / teams.
securingsincity 10y ago
> [Kernel] Recognize merge conflict markers in source and provide a readable error message Great idea, having to track down a merge conflict that may have been committed can be a drag.
- zegerjan 10y ago
  This confuses me, as I can think of any language where `<<<<<<HEAD` would be valid? This is why its formatted this way. I'd say the compiler or interpreter should tell you within no time where it encountered invalid tokens?
  - lostcolony 10y ago
    The point of this change is to make the error message, when the compiler encounters such a line, something like "Unresolved merge conflict detected in source code at (file:line)", rather than whatever it previously was (some sort of nebulous syntax error, that may or may not have been well located, depending on exactly what the parser managed to infer, but certainly was not well defined).
tiffanyh 10y ago
Will Erlang/Elixir ever be able to attain the raw performance speed of Go? I'm not talking about concurrency, etc. Just raw computational speed.
- qaq 10y ago
  No, same as Go will never be able to match the unique characteristics of Erlang/OTP.
- brightball 10y ago
  The trade off is that a runaway process can't compromise everything else. The inherent performance difference comes from prescheduling vs cooperative scheduling. Prescheduling is slightly slower in exchange for consistency in the face of bad behavior. Add in the supervision tree structure and you end up trading "super fast" for "very fast, consistent and runs forever"
  - tiffanyh 10y ago
    Is there any updates on the JIT work from 2014 to help speed up raw performance of Erlang? [1] http://www.erlang-factory.com/static/upload/media/1402914329562325jiteuc2014.pdf http://www.erlang-factory.com/static/upload/media/1402914329... [2] http://www.erlang-factory.com/euc2014/frej-drejhammar http://www.erlang-factory.com/euc2014/frej-drejhammar
    - di4na 10y ago
      Yes. The news is basically "still in the roadmap, we got a bit more of time budget from it" from the OTP team. It is not something you will see tomorrow, but it is a long standing thing in the roadmap for the team. Of course, if you want to sponsorise the work...
- napsterbr 10y ago
  If you need raw computational speed you shouldn't be dealing with erlang / elixir anyway. Rust and go would be a proper comparison here

229 points by njade 10y ago

Coming from Ruby, Elixir feels like a powerful, beautiful language with a surprisingly radical but ultimately simple approach to concurrency thanks to Erlang/BEAM, and Phoenix is like Rails 2006, as far as the framework to sell Elixir's advantages to the masses. It's very powerful and scaling "just works". All Elixir needs now is a viable ElixirScript that can compile down to JS/WASM, and along with Nerves it's ready for world domination. ;)

pmontra 10y ago
If all you need in js/wasm is the functional layer of the language, that could be easy. If you want to add processes, that could be very hard. If you also want the supervisors, that's difficult but probably not has much as adding Erlang style processes.
- pmarreck 10y ago
  What's stopping a compile of Erlang to JS via LLVM and Emscripten and just taking the expected performance hit?
  - Xixi 10y ago
    Erlang doesn't compile to machine code, but to bytecode that runs into the Erlang VM. So you would probably have to run the Erlang VM on top of javascript... I'm not sure whether it's possible, but it sure sounds heavy.
    - int_19h 10y ago
      With WebAssembly, you should be able to compile the Erlang VM itself to it.
  - bryanjos 10y ago
    There is the LLVM backend in Erlang as of version 17. I haven't seen much info on it. I haven't seen anyone try to go the whole process from Erlang code to LLVM to Emscripten to JavaScript. I am interested to know what hurdles there might be, performance, etc.
- lawik 10y ago
  AFAIK the VM creates a thread per core (by default) and schedules Processes across those threads and stuff. I'd say this might be possible to do with Web Workers. Sounds like it could be fun, probably a challenge to make it fast.
chao- 10y ago
>All Elixir needs now is a viable ElixirScript that can compile down to JS/WASM On the off-chance you pulled that name out of a hat, or for the benefit of anyone else who might not realize you are referencing a real project: https://github.com/bryanjos/elixirscript https://github.com/bryanjos/elixirscript
rubyn00bie 10y ago
I'm not sure why you want to compile Elixir or Erlang to JS... Most of the magic of the language is provided by BEAM and OTP which for a multitude of reasons cannot be properly implemented in any JS engine/backend I'm aware of. If anything I'd think the abstractions of Elixir/Erlang would be cumbersome and very awkward when writing performant code which had to be transpiled to JS. The biggest reason being is BEAM can do preemptive scheduling, interrupting a running process to ensure all have equal execution time. This is a stark contrast to everything I know about how most any other VM or runtime work (which cannot preempt). While yes the language is nice, I think using something like Opal would provide most of the syntactic pleasantries while being easier to understand when it comes to tuning and debugging. If what I'm saying is nonsense, I'm missing the point, or short sighted please learn me! :)
- jaredklewis 10y ago
  Even if Elixir had no concurrency goodness I would still prefer it to a language like JS any day of the week. JS is a mess of paradigms and features. Elixir has a small set of great features: modules, functions, pattern matching, immutable data structures, macros. Regarding your performance point, I'm skeptical. Is it really so easy to reason about the performance of even plain JS code? Maybe you're more familiar with the deep dark crevices of v8 and spidermonkey than I am, but I find v8 to largely be a black box in terms of fine tuning performance. Of course, the big picture optimization is simple enough, but that wouldn't change whether you are using plain JS, Opal, PureScript, or any other language. Yes, a BEAM elixir program can run parallel threads and ElixirScript won't be able to do that because in JS, there are no threads. That doesn't make plain JS faster, just means Elixir will be brought down to the same level as plain JS. I've used what I view to be equally foreign compile to JS languages (ClojureScript, Elm). They of course came with challenges, but fine tuning performance doesn't even make the top 10.
- btown 10y ago
  With the right abstractions and (adhered-to) guidelines, a library in a non-preemptive language can allow your code to effectively yield to the scheduler so often that you get many of the benefits of preemptiveness. React is moving in this direction with their ongoing Fiber project [0] - since components are encouraged to be granular, and must be loosely coupled, the new React scheduler can take well-structured React code and plan the rendering of various subtrees with high levels of control. In fact, there's a TON of similarities between React's component model and the BEAM actor model: a component's "mailbox" consists of inbound props, outbound async callbacks to the component that requested its instantiation, and outbound assertions that the component desires to communicate props to new instances of other components. One could imagine a compiler that inserts a yield around the calculation done in each Elixir AST node, and/or one which allows first-class representation of React components as Elixir processes, complete with JSX-like syntax. Very interesting to think about. [0] https://github.com/acdlite/react-fiber-architecture https://github.com/acdlite/react-fiber-architecture EDIT: Should also add that the shared-nothing messaging model translates very well to the requirements for Web Worker interop, so you actually could get multithreading.
retrogradeorbit 10y ago
Just use elixir on the server, and clojurescript on the client.
- kim0 10y ago
  Or clojurescript on both sides

josevalim 10y ago

Link to the official announcement: http://elixir-lang.org/blog/2017/01/05/elixir-v1-4-0-released/ http://elixir-lang.org/blog/2017/01/05/elixir-v1-4-0-release...

qaq 10y ago
Thanx for all the great work José we all really appreciate it.
ptlu 10y ago
thanks!!

_asummers 10y ago

Congratulations to José and the Elixir team! It will be nice to finally settle the bare words debate and fix all the new warnings and deprecations. We compile with warnings as errors, so that should be a fun morning when we upgrade.

sotojuan 10y ago

My favorite part about Elixir is that it doesn't try to reinvent the wheel. It's not an untested, trendy new paradigm or tool. It's based on decades of Erlang/BEAM/OTP experience and Ruby/Rails/last 10~ years of programming ergonomics. The only things that are added are those that actually add to the experience. An example: A large part of the Erlang standard library is not translated in Elixir. Instead, you call Erlang methods with a seamless interop. José & co. understand that there's no need to reinvent the wheel and no benefit in another abstraction. I like that. My least favorite part about Elixir is that it has become a "trendy" language among the web crowd. While the community is overall great, there's always a loud minority of "beginner experts" both claiming it's the best thing ever and deriding those for using other tools. I've seen a lot of random, unwarranted Rails bashing and Elixir shilling (never from a team member or community leader though!).

jbhatab 10y ago
What's wrong with getting excited about a new language and framework that's better? Being vocal about how awesome something is gets people involved which grows the community. A larger community translates to more educational material and tooling. I think zealotism has a fine line, but I don't think it's all bad. It's almost like protestors that believe in something strongly. Sometimes they cross the line, but them protesting gains visibility which results in change.
- MrBra 10y ago
  Better than what?
  - erik14th 10y ago
    Erlang was developed to solve problems that are quite common in Web Development like concurrency, high availability and so on. I see Elixir basically as a user-friendlier version of Erlang with some added goodies. So I think it makes perfect sense for it to be popular among the Web crowd. It definitely has it's own problems(ease of deployment, package maturity, imo). But if your problem involves networks I think Elixir is at the very least worth having a look at.

transfire 10y ago

> [Kernel] Deprecate support for making private functions overridable. Overridable functions must always be public as they must be contracts Just lost interest. I thought Elixir was supposed to learn from Ruby.

josevalim 10y ago
Can you please expand on this a bit? Your comment is very vague. The comparison with Ruby here doesn't make much sense because private means different things in both languages and Elixir does not have inheritance.
jkmcf 10y ago
You'd think they'd learn from Java! Edit: Not a shallow dig, but I had lots of fun using a 3rd party library that had locked down a lot of methods which prevented some sales driven features...
brightball 10y ago
Personally, I've never seen the value in private functions in the real world. If you are in the same runtime and can see the code, what exactly does a private function offer you other than ensuring somebody has to duplicate the method to manipulate it. Professionally I've never seen a private function/method that had a purpose or benefit from being private.
- _asummers 10y ago
  In Elixir especially, with everything being immutable, I don't really have to worry about state hanging around for my private methods to care about. I wind up just throwing private functions into little helper modules that can be tested independently. As far as benefit of something being private, an API does not have to be maintained if it is private. Once it's out there, you're locked into doing that for the duration of your deprecation window.
- swsieber 10y ago
  They seem quite useful. Mostly signaling that things should not be used. What's the largest number of people you've workwe with on a codebase? I would assume the benefits aren't really all that much for small codebases / teams.

securingsincity 10y ago

> [Kernel] Recognize merge conflict markers in source and provide a readable error message Great idea, having to track down a merge conflict that may have been committed can be a drag.

zegerjan 10y ago
This confuses me, as I can think of any language where `<<<<<<HEAD` would be valid? This is why its formatted this way. I'd say the compiler or interpreter should tell you within no time where it encountered invalid tokens?
- lostcolony 10y ago
  The point of this change is to make the error message, when the compiler encounters such a line, something like "Unresolved merge conflict detected in source code at (file:line)", rather than whatever it previously was (some sort of nebulous syntax error, that may or may not have been well located, depending on exactly what the parser managed to infer, but certainly was not well defined).

tiffanyh 10y ago

Will Erlang/Elixir ever be able to attain the raw performance speed of Go? I'm not talking about concurrency, etc. Just raw computational speed.

qaq 10y ago
No, same as Go will never be able to match the unique characteristics of Erlang/OTP.
brightball 10y ago
The trade off is that a runaway process can't compromise everything else. The inherent performance difference comes from prescheduling vs cooperative scheduling. Prescheduling is slightly slower in exchange for consistency in the face of bad behavior. Add in the supervision tree structure and you end up trading "super fast" for "very fast, consistent and runs forever"
- tiffanyh 10y ago
  Is there any updates on the JIT work from 2014 to help speed up raw performance of Erlang? [1] http://www.erlang-factory.com/static/upload/media/1402914329562325jiteuc2014.pdf http://www.erlang-factory.com/static/upload/media/1402914329... [2] http://www.erlang-factory.com/euc2014/frej-drejhammar http://www.erlang-factory.com/euc2014/frej-drejhammar
  - di4na 10y ago
    Yes. The news is basically "still in the roadmap, we got a bit more of time budget from it" from the OTP team. It is not something you will see tomorrow, but it is a long standing thing in the roadmap for the team. Of course, if you want to sponsorise the work...
napsterbr 10y ago
If you need raw computational speed you shouldn't be dealing with erlang / elixir anyway. Rust and go would be a proper comparison here