I would remove discussions from the community’s main forum about what to remove from the language

if, cond and unless. Yes they may have use case, but they are also in general a bit too much abused.

I like tuple keyword pairs, I do however hate the [foo: 1] syntax, I prefer [{foo, 1}], not only because that is the erlang way, but because propertylists are more powerful than elixir kwlists. For example in erlang-style property-lists both of these are the same thing (using elixir syntax of course) [{:blah, true}, :blah] which means that you can have very succinct option lists for arguments, but in elixir you have to do [{:blah, true}] (or the traditionally elixir syntax, which saves you 3 chars [blah: true]) instead of just being able to do [:blah]. Consequently I use the erlang’s property list functions in Elixir a lot more than I use Elixir’s Keyword module just because the Keyword module is a sub-set of the property list module as an Elixir keyword list is a property list, but a property list is not necessarily a keyword list, property lists are more succinct and more powerful. In addition the ‘key’ of a property list can be anything, not just atoms.

I’m still iffy on the colon-atom syntax in Elixir, but I think I’m warming up to it. And atoms are interned strings, they are not strings, just like you cannot compare a flyweight string in C++ to a normal string, same thing here. Think of Atoms as a globally named enumeration (because that really is what they are), do not think of them as strings. I absolutely would *NOT*EVER* want atoms removed, enumerations are valuable.

That is in any language though (that does not do magical and bug-hiding auto-casting), the bit representation of 1.0 and 1 are different (well, it might for 1.0 and 1 depending). Absolutely would not want this removed either. Emulating floating point with integer math is sloooooooow.

I mostly prefer fixed-point though, but floating point is sometimes necessary.

Hehe, what I said above, you want property lists too.

if is a nice wrapper around cond (wish it were a literal wrapper around cond), but it and unless are nice macro’s, they should just not be part of the language proper, but should be macro’s inside Kernel is all, if so then all good.

Keyword lists are not inheritence from Erlang, they are entirely an Elixir construct, just a reduced property list (which ‘is’ from Erlang). I’d prefer property lists over keyword lists any day.

Tagged tuples are indeed not only idiomatic but *very*fast*, they are awesome in general.

Function head matching just compiles into a case statement in a single function in CoreErlang anyway, so they are just a case.

case is a core branching conditional, it should be front-and-foremost.
cond is a core sequential conditional, it should be front-and-foremost.

case and cond cannot do what the other does as efficiently as the other does it.

Everything else after that is sugar.

There are libraries for that. The compiler absolutely should not do that, absolutely! They have two very different use-cases and they are not equivalent.

So you want it how it is in Erlang then.
In Erlang you have no if, just cond, and if you have no ‘else’ condition (via true ->) then you get a match error. I prefer that.

Elixir has one very very very what I consider monumentally stupid decision that is hitting me to this day (in mostly macro work), but I’ll get to that at the bottom…

Very very much. For every one time I use if/cond I use case at least a dozen times. if/cond is not a common construct on the BEAM for well written code.

Honestly I’d think elixir should toss out if/unless, if someone wants those let them use and/or/||/&& as those are obviously expressions and have defined results. Try to push people to case/cond instead.

I’d honestly prefer if the a: 42 syntax was removed entirely to be honest, it is inconsistent, it should just be :a => 42 as it would be a lot less confusing to newbies. This is not a big thing to me though, but I do like unified constructs, and having two ways to do the same expression for something so simple does bug me.

We already have the Decimal and Ratio libraries for that.

Except those cannot be emulated efficiently by a library, floating point has to be a fairly native language construct unless you can write assembly in the language (which we obviously cannot).

And it has great uses by far! Just a lot of people try to do stupid things like represent money as floating points.

If you can come up with an efficient representation of floating point that is at least as fast as floating point (since its purpose is for efficiency, not accuracy) then I’d say sure, but if you came up with such a style you would also likely become a millionaire near overnight.

Standard markdown syntax:
Like a link, just with ! at the start.

Not necessarily. If you only need, oh, 4 decimal places of accuracy and your work will not cause the error value to exceed that then floating point can let you get it done in, oh, 10 seconds, where fixed-point might take 2 hours. SSE is a heck-of-a-drug. ^.^

Ditto, there is *no*reason*whatsoever* to have with be a special language construct. It can easily be done as a macro instead, and can indeed be done ‘better’ as a macro. Elixir has a few ‘special constructs’ that just break the syntax rules or are just wtf’s, and with is one.

I think something like with-as-a-macro should be included in Kernel, but it should absolutely not be a special construct.

What should be removed

And for my vote of what should be removed:

BLOODY-FREAKING-VARS-LEAKING-OUT-OF-SCOPE!

iex> case :blah do
...>   :blah ->
...>     a = 42 # From function or so
...>     a * 2
...>   _ -> :bloop
...> end
84
iex> a
42
iex> # WTF?!?!?
nil

Grrrr, and sometimes this is really REALLY freaking hard to fix in macro’s without resorting to holding some state in ETS tables or the procdict or so, grrrrrrrr…

WHY was this EVER a thing?!? This is the one thing that bugs me most of all and just makes the language feel like it is bug-ridden-waiting-to-explode kind of thing (even though I know better)…

Bonus second thing

Why the frick is the atom nil used as the nil value when [] is better for it in every way. It is ‘slightly’ faster for comparisons, it is also falsey to the BEAM, it is even called the nil type in the Erlang documentation, and there are a half-dozen other reasons it should have been used.

Also nil is used way too much! The undefined atom is often better in most places it is used as it is a great indicator of this is an ignorable return, or the ok atom is often better in most places it is used as it is a better indicator of success-but-no-useful-return, or the error atom is often better in most places it is used as it is a better indicator of uhhh-wtf, or any other number of things. I cannot thing of a single place anywhere in any function in any place that I would prefer nil over one of []/undefined/ok/error or something else more specifically descriptive. I have no clue where this nil wart even came from, probably some ruby-horror…

Bonus-bonus what I want added

An option and result types, though they would really be {:ok, value}/:error and {:ok, value}/{:error, reason} but with helpers in a module. This could easily be a library sure, but this should be baked into the language stdlib/kernel or so thus the usage is ubiquitous and unified. I’d love to do something like this (assume each returns an option/result tuple):

import OptionResult, only: [|>: 2, ~>: 2] # I'd prefer these in kernel though...
do_something(blah)
|> operate_on_value(bleep)
~> operate_on_error_to_return_new_result(bloop)
|> more_stuff()
|> yet_more_stuff()

And at the end you have an ok or error tuple that is the result of the pipeline, success values are passed in at |> and skipped on error, and error values are passed in on ~> and skipped on successes. You could even have a final call of something like ~> throw if you want to throw on error so you only have a success too.

Yes I know there are libraries for these, exceptional is the library I use for this (although it does ‘more’), but it really should be part of the base standard library so its use is ubiquitous.