This is a release candidate for the upcoming Elixir v1.5. It includes bug fixes, enhancements and it integrates many new features that are part of OTP 20+.
Since it is a release candidate, please report any breaking changes you may find. To run this version, you can either compile from source or use the precompiled packages in the link above. If you need help to compile from source or use the precompiled packages, check our Install page.
Can not wait to use the Calendar improvements. Thanks!!
@josevalim in the ElixirConfEU you talked in your keynote about two interesting features: a Language Server implementation and a kind of Quickcheck support in tests. Are those features to be expected in future versions of the language? Or should we expect them to be developed as separated packages?
We will see how things evolve. Property testing (which remember, is for data only for now, not for state machines stuff like Quviq’s QuickCheck) might land in ExUnit in future versions of Elixir. The language Server Protocol implementation is likely to remain a separate package. We’ll see how it goes
I just checked the changelog and I’m a bit surprised by this one:
[Enum] Deprecate Enum.filter_map/3 in favor of Enum.filter/2 + Enum.map/2 or for-comprehensions
I assume that we would now have to filter |> map instead ? If this produces the same result it does not have the same algorithmic complexity. Why is it now deprecated?
and I have a problem:
I tried example call from changelog: Access.fetch(:foo, :bar), but result surprised me. I don’t see part about available function clauses.
Erlang/OTP 20 [erts-9.0] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:10] [hipe] [kernel-poll:false]
Interactive Elixir (1.5.0-rc.0) - press Ctrl+C to exit (type h() ENTER for help)
iex> Access.fetch(:foo, :bar)
** (FunctionClauseError) no function clause matching in Access.fetch/2
The following arguments were given to Access.fetch/2:
# 1
:foo
# 2
:bar
(elixir) lib/access.ex:261: Access.fetch/2
On of my packages, ex_cldr, I’m seeing compilation and test times improve significantly - about twice the speed. This monster generates and runs over 12,000 tests so it makes a big difference!
Looking forward to the new Date functions, as well as the async_stream timeout option Although it’s sad to see the filter_map function go…
Only thing that worries me, though:
[Calendar] Limit Calendar.ISO up to year 10000
I’d put a TODO note for future developers to revise that in a few thousand years — we don’t want to cause a bug that could bring down the life support systems in planets across the galaxy…
This is a tricky one. Exception.blame/3 works only on modules compiled on OTP 20. Most package managers use the precompiled Elixir which is compiled on the lowest supported release - currently OTP 18. This means when you use precompiled Elixir, you won’t get nice diffing from stdlib modules (but you would in your own modules or packages since you compile them every time).
This is understandably inconvenient. Hopefully, there will be a solution before the final release.
Dude, everyone knows those systems will run nodejs… Node.js Is Bad Ass Rock Star Tech (Note: Despite what’s said in the video, Christopher Colombus did not discover that the world was round, everyone already knew that since like forever).
This limit was introduced to guard against a common error of a wrong unit - for example passing the number of nanoseconds, where milliseconds were expected.
@michalmuskala is this documented somewhere? I did not see it in my quick glance of the new version of yhe Calendar.ISO documentation but I might have missed it.
Marvellous changes, and I am of course super excited that the calendar conversions are becoming part of the Elixir release now .
The reason is actually that Erlang’s calendar library works only until the year 9999. So it always raised, we are just making it clearer in the error message and user experience.
Yes. Elixir has to be conservative here. I believe the solution should be for package managers to promote the OTP 20 + Elixir v1.5 combo. This way those who need to run on earlier versions still can but those who can jump to the latest will get a better experience.
@josevalim: From what I can see elixir plug-in for asdf is using Precompiled.zip file as source path from elixir-lang/elixir official github repository, so correct me if I’m wrong, but in this case you need to update Precompiled.zip release file.
I get the feeling that my question sunk, can anyone explain or point me anywhere?
If anything, I would actually add more functions to Enum. So I’m a bit surprised. Last one I was missing is a Enum.count_by/2. Btw Is this the kind of contribution that would be well received or is the core team reluctant to inflate the size of the API of a module like Enum?
I understand your sentiment here. Doing filter |> map is O(2n) while filter_map would be O(n). However, I think it’s fairly trivial to write something like for x <- list, filter.(x), do: map.(x) where filter/1 is your filter function and map/1 is your mapper function. That’s how filter_map was implemented (at least for lists) in the first place.
Firstly, I don’t speak for the core team in any way.
I haven’t been active on the core mailing list much since I switched jobs over a year ago, but getting anything in Enum is going to require a very solid use case. (i.e. it should replace 10+ lines of complicated, hard to figure out code). It needs to be efficient for Lists and cover the edge cases for Enumerables; anything that just uses existing Enum functions will likely have a difficult time.
There are helper libraries for creating additional Enum functions.
Search the core email list, it is more than likely that any function added to Enum that you can come up with has already been proposed ( and rejected). The Core team is very conservative in Enum, since everything in there must work solidly and they (still a very small team) have take on the burden of ongoing support.
Also, if you add it to Enum, you should also add it to Stream if at all possible.
Everyone is very polite and if you do your homework, you’ll at least learn something.
Here’s a question: I saw in the changelog the following line:
[Kernel] Use the new debug_info chunk in OTP 20. This provides a mechanism for tools to retrieve the Elixir AST from beam files
Does this mean (in theory) that tools such as Concuerror which operate on the compiled beam files would be able to use this debug info to construct stack traces as if they came from the Elixir source files themselves instead of from the beam files?
Although it’s sad to see the 
.
