It isn’t. 
There is very little reason for an Elixir v2.0 with breaking changes. The language was designed to be extensible and if we need to do major changes to the language to improve the language itself, then we failed at the foundation.
Every time we deprecate something in v1.x in favor of something new, it is literally a step towards 2.0. Elixir 2.0 should indeed be mostly removing deprecated features.
It has been discussed previously on why removing it is very dangerous and confusing to Elixir variable and function namespaces. Hopefully someone can find a link to some of those discussions.
There are case insensitive file systems, which means that, if we remove the Elixir. prefix, then a User module will conflict with the user module in Erlang. The same for IO and io, etc.
Great idea! No need to wait for 2.0 though, should be done now. I think there is even an open issue.
Unfortunately very hard to do efficiently without currying and without static type checking to eliminate intermediate lambdas.
With tuples and atoms, you do have sum types and product types, which are the foundation of algebraic data types. We don’t have type checked algebraic data types though.
Thanks for taking the time to reply here @josevalim, I’m sure Elixir’s design has been discussed at length on the mailing list over the years.
There’s one other idea I’d like to experiment with: an FFI to webassembly. Assuming Rust/C++ can be compiled to wasm and published to a package repo, then Elixir could load the precompiled wasm, optionally JIT compile it, and run it on a dirty scheduler.
Statically compiled binaries for distribution would be a great feature for deployment, a la go or rust. I’ve seen talk about this before, and how there are a lot of underlying BEAM mechanisms that would have to exist before this would be possible.
would love to see a ‘pipe to value’ syntax
a
|> f1
|> M.f2
~> b
And maybe this is a big ask, but requiring a sigil on mutable variable names (or a declaration keyword like “mut x”), so all variables are defalut-immutable would be great.
Except there are no variables, so there is no mutation, there is only immutable bindings and rebinding?
What would such a value be, an anonymous function?
I still think that ‘buffing’ piping with a proper monad pipeline would be so amazingly useful.
What is a “proper module pipeline”? The only pipeine you need for a monad is the bind function, right?
Technically (and well a return), but you also need the infrastructure to support dispatching based on the types better, which a Protocol can mostly do, but would need to build that up, etc… etc… etc…
But that’a only if you want typeclass-like monads. If you’re haooy with using qualified binds, the whole issue goes away, right?
Per-expression qualified binds basically puts you back at the current pipeline style, per pipeline qualified binds limits you to OCaml style single-type pipelines (no changing types throughout the pipeline), etc… etc…
sorry I should have said that the
a
|> f1
~> b
is equivalent to
b = a
|> f1
Except there are no variables, so there is no mutation, there is only immutable bindings and rebinding?
You’re rebinding the variable name to a different value. In elixir, there are no mutable values. I don’t know what elixir calls this, but julia we would say this is a “variable with an immutable value” (there are also variables with mutable values in julia)
Hope this is not viewed as necroing a thread.
Related to a recent discussion here – Module naming conventions – I would actually like to see Elixir 2.x enforce a file name and a module name to be the same (with CamelCase <-> snake_case compatibilty, say MyApp module can belong to both MyApp.ex and my_app.ex).
Furthermore I would also suggest enforcing only one module per file but that might be tricky; imagine a 5-line protocol and then 5 implementations 10 lines each, all in 6 different files – might be an overkill. But maybe the protocol implementations can be exempt from the rule.
EDIT: As pointed out by @axelson, Credo could allow this in the future: https://github.com/rrrene/credo/pull/587
It’s a very good founding principle. Now let’s take the article that Andrea Leopardi wrote about retiring shorter_maps. This is a case where someone used the extensibility of the language to provide some nicer and shorter syntax.
Ultimately he decided to retire the library for various reasons, one of them being:
Fair point.
This reminds me of the existence of great packages like Exceptional, Quark or Witchcraft by expede on Github. These packages provide new operators and new constructs which are not standard Elixir, therefore according to Andrea’s argument, we should reconsider using them. Lots of people agree with Andrea, and I do too to some degree.
@josevalim What’s your take on the opposing forces which are Extensibility and (not sure of the best name) Familiarity?
I don’t think there is a canonical answer. It is a discussion that different teams will have, on different topics, with different outcomes. In @whatyouhide’s case, he thought short_maps was adding too little, probably because it was mostly a syntax concern and not really extending Elixir to any new domain.
But there are many examples where the language is extended to new domains (ecto, nerves, scenic, phoenix, etc) and developers are happy with the outcome, even if it means learning new constructs. It may also be that some new domains overreach and try to change even known language idioms and I would expect the community to push back under those circumstances.
Hardly possible due to module generating macros, as eg. defimpl.
I do not want to create lib/string/chars/my/module/name/and/struct.ex…
True, it would be annoying. Maybe having namespace.subnamespace.module.ex filename format would be better?
Oh well. I suspected something similar. Seems the community already gravitated towards making the best of the current situation. 
FWIW, I want to make clear that I don’t think that extending the syntax of the language is not worth it. Ecto did it successfully and I’m sure many other packages will. However, I always try to balance out how “disruptive” the syntax addition is versus how big the package is and how frequently it’s used by the community. Ecto is a pretty standard Elixir package so most folks that will come to Elixir will have to learn it, so I don’t mind that it uses that syntax it uses. A package such as short_maps is not a de-facto standard so I think it does damage with its syntax more than it adds benefits.
I can’t talk for things like Witchcraft, but at the end of the day, the important thing is that the language allows you to do all the weird stuff you want and to experiment and use your own syntax. That has nothing to do with whether you should, which is the reason I retired short_maps.
While I don’t think that an ETS-specific module like @mbuhot mentions is needed–as matchspecs star in a few erlang APIs beyond it–or even a dedicated module, I think there’s a pretty compelling argument to be had for adding a macro or two in kernel to build them.
ex2ms does a decent job in translating Elixir AST to matchspec data structures, but that’s only one aspect of a robust solution for them, and there are certain features you could only get by having them be integrated into core–and certain challenges supporting them in tracing you can’t accomplish without some hackiness, or additions to OTP itself.
This is something I could wax on about in depth, and I plan to make the case for them somewhere someday soon, but I just wanted to voice my overwhelming support for their inclusion in a future version or Elixir on this thread. Matchspec macros lie in a sweet spot of Elixir’s strengths: powerful metaprogramming, helpful compile-time errors, and easing interaction with existing amazing OTP tooling. They’re one of the few obvious adds to the language left in my mind.