Elixir v0.14.0
elixir-lang.org
Elixir v0.14.0
1–8 of 8 posts
Re: Elixir v0.14.0
#2The changelog for this particular release: https://github.com/elixir-lang/elixir/releases/tag/v0.14.0
Enhancements
[ExUnit] Add on_exit/1 callbacks that are guaranteed to run once the test process exits and always in another process
[Kernel] Store documentation in the abstract code to avoid loading them when the module is loaded
[Kernel] Add get_in/2, put_in/3, update_in/3 and get_and_update_in/3 to handle nested data structure operations
[Kernel] Add get_in/1, put_in/2, update_in/2 and get_and_update_in/2 to handle nested data structure operations via paths
[Mix] Add Mix.Config to ease definition of configuration files
[Mix] Add mix loadconfig task that can be called multiple times to load external configs
[Mix] Support --config option on mix run
[Mix] Support HTTP_PROXY and HTTPS_PROXY on Mix url commands
[Mix] Support --names options in mix help which emit only names (useful for autocompletion)
[Protocol] Add Protocol.consolidate/2, Protocol.consolidated?/1 and a mix compile.protocols task for protocol consolidation
[Protocol] Add Protocol.derive/3 for runtime deriving of a struct
[String] Add String.chunk/2
[Struct] Add support for @derive before defstruct/2 definitions
Bug fixes
[File] File.rm now consistently deletes read-only across operating systems
[Kernel] Ensure Mix _build structure works on Windows when copying projects
[Kernel] Ensure 1.0E10 (with uppercase E) is also valid syntax
[Mix] Fix mix do task for Windows' powershell users
[Path] Fix Path.absname("/") and Path.expand("/") to return the absolute path "/".
Soft deprecations (no warnings emitted)
[Kernel] size/1 is deprecated, please use byte_size/1 or tuple_size/1 instead
[ExUnit] teardown/2 and teardown_all/2 are deprecated in favor of on_exit/1 callbacks
Deprecations
[Access] Access.access/2 is deprecated in favor of Access.get/2
[Dict] Dict.Behaviour is deprecated in favor of Dict
[Kernel] Application.Behaviour, GenEvent.Behaviour, GenServer.Behaviour and Supervisor.Behaviour are deprecated in favor of Application, GenEvent, GenServer and Supervisor
[Kernel] defexception/3 is deprecated in favor of defexception/1
[Kernel] raise/3 is deprecated in favor of reraise/2
[Kernel] set_elem/3 is deprecated in favor of put_elem/3
[Kernel] Passing an atom var!/1 is deprecated, variables can be built dynamically with Macro.var/2
[Mix] Exceptions that define a :mix_error field to be compatible with Mix are no longer supported. Instead please provide a :mix field and use Mix.raise/1 and Mix.raise/2
Backwards incompatible changes
[Access] Kernel.access/2 no longer exists and the Access protocol now requires get/2 (instead of access/2) and get_and_update/3 to be implemented
[Kernel] Retrieving docs as module.__info__(:docs) is no longer supported, please use Code.get_docs/2 instead
[Kernel] Code.compiler_options/1 no longer accepts custom options, only the ones specified by Elixir (use mix config instead)
[Mix] mix new no longer generates a supevision tree by default, please pass --sup instead
[Task] Tasks are automatically linked to callers and a failure in the task will crash the caller directly
Re: Elixir v0.14.0
#3We've started using Elixir in our Erlang application and it's been a pleasure to work with. Everyone in my office agrees they would've loved to have this when they started with Erlang.
Re: Elixir v0.14.0
#4I've been keeping an eye on Elixir for a while, waiting for some spare time. What are reasons not to use it in favour of Erlang?
Re: Elixir v0.14.0
#5I've been keeping an eye on Elixir for a while, waiting for some spare time. What are reasons not to use it in favour of Erlang?
Elixir is still a moving target (as the number of deprecations and changes in the announcement show) so if you are building something that needs a stable base then I would not recommend Elixir just yet. You are still using a lot of Erlang libraries for things outside of the core, so you still need to learn or at least understand Erlang and its APIs. OTOH, I love it and I think that the costs that I mentioned previously are more than made up for by the lower cognitive load Elixir imposes on people coming from outside the functional world and the macros and protocols are very cool. Elixir is a language to play around with now and get used to and in three to six months I think it will be a serious contender for any new product that slings packets or has to handle massively concurrent loads.
Re: Elixir v0.14.0
#6I've been keeping an eye on Elixir for a while, waiting for some spare time. What are reasons not to use it in favour of Erlang?
Elixir is still a moving target (as the number of deprecations and changes in the announcement show) so if you are building something that needs a stable base then I would not recommend Elixir just yet. You are still using a lot of Erlang libraries for things outside of the core, so you still need to learn or at least understand Erlang and its APIs. OTOH, I love it and I think that the costs that I mentioned previous…
Fair comment. Some of us are using Elixir in production, and there's a cost to migrating the code base from one release to the next.
But overall, even for a new fast moving language, the stability of erlang benefits it pretty well.
Re: Elixir v0.14.0
#7We've started using Elixir in our Erlang application and it's been a pleasure to work with. Everyone in my office agrees they would've loved to have this when they started with Erlang.
What sort of thing are you working on that is well-suited for the Erlang/Elixir languages?
Re: Elixir v0.14.0
#8Has anyone used Elixir in production yet?