@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.
https://github.com/mykewould/crutches
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?
If my memory serves me well, there’s no such thing as O(2n) 
It’s still linear complexity. Moreover, vaguely speaking, the amount of operations is the same in both cases. In filter_map, you need to filter each element, and map all elements which are not rejected. You perform the same amount of operations if you filter all elements first, and then map the result.
However, the difference is that with Enum.filter |> Enum.map an extra intermediate list is generated (compared to filter_map). If that intermediate list is big, you might experience a significant performance penalty and increased memory usage. A simple fix would be to use Stream.filter |> Enum.map instead, or to use the comprehension, as you mentioned.
No idea why filter_map is removed, but FWIW I never used it myself. I prefer piping to filter and then to map, or comprehensions.