What would you remove from Elixir?

Tuple keyword pairs, e.g [foo: 1] and replace them with real maps. Not gonna happen though

:atoms because

%{"foo" => value} = input
%{foo: value}

floating point numbers, because

1.0 != 1

I would remove the restriction that keyword lists can only contain atoms as keys .

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

The allure of atoms is their speed and memory efficiency. From a small Benchee-powered run:

Name ips average deviation median
match atoms in maps 7.59 M 0.132 μs ±110.46% 0.130 μs
match strings in maps 4.34 M 0.23 μs ±35.97% 0.23 μs

Comparison:
match atoms in maps 7.59 M
match strings in maps 4.34 M - 1.75x slower

Name ips average deviation median
lookup atoms in maps 4.48 M 0.22 μs ±2057.09% 0.20 μs
lookup keys in keyword list 3.04 M 0.33 μs ±1179.91% 0.30 μs
lookup strings in maps 1.39 M 0.72 μs ±330.99% 0.70 μs

Comparison:
lookup atoms in maps 4.48 M
lookup keys in keyword list 3.04 M - 1.47x slower
lookup strings in maps 1.39 M - 3.22x slower

Those numbers appear to be very consistent over multiple runs / changes, and they do indeed add up in real world applications.

Keyword lists and “tagged tuples” are an inheritance from Erlang where they are idiomatic and widely used, and I agree they are not as useful in Elixir on its own but .. yeah.. legacy is as legacy does, they aren’t going anywhere.

What would you replace them with? Or is your suggestion that all numbers should be able to represent a fractional value, or put another way to get rid of integers as a distinct thing?

Do you prefer function head pattern matching, or other control flow strategies, or?

I don’t think we should loose that. It just seams to me that deciding between strings and atoms is an implementation detail. A smart enough compiler should be able to turned user declared strings into atoms at the places it matters.

Keep integers, they represent a real world concept. In most cases rational numbers (fractions) are all that’s needed.

I’d prefer to keep at least if and cond. if is so much nicer and easier to read than a case which does only match on true and false. As well as a cond is so much nicer to read than a deeply nested cond or an if...then..else if....

But! I’d be very happy if we could remove the implicit else: nil and either replace it with raising something or making it mandatory as in Haskell.

If this had been from the beginning, we hadn’t had any problems with what is called an “imperative assignment” nowadays.

Given how atoms work, that’d be rather dangerous, esp since I’m not sure how one would measure “places it matters”. IMHO, it’s one of those things best left to the smartest, if slowest, compilers: people

I totally understand how the difference between these “tags-as-values” and strings can feel clumsy and even be confusing (as you noted in your example: the difference between user input and structures in the program itself) … it doesn’t feel super elegant. But, and perhaps this is just because I’m an old and jaded fart who is used to far more annoying baggage in my programming languages, I can forgive this because of the benefits it brings.

On the bright side, it’s nice that there aren’t too many more pressing things in the language

So you’d introduce a data type that represents rational numbers? A fixed precision decimal type? Because obviously straight up integers don’t suffice everywhere, and it’s somewhere between cumbersome and horrible to try and represent rational numbers with integers.

Is there a use case where this actually matters to you? Or is it just the fact that there are two numeric types annoying in an aesthetic sort of way?

Personally I don’t mind them either and sometimes they are absolutely the best tool to express a specific idea in the code.

What I do notice is that these conditionals get used a lot in some Elixir code when there are other more .. idiomatic? .. ways of doing it. Some code looks very much like it’s -port-to-Elixir. I know here at work developers new to Elixir avoid things like function-head pattern matching in favor of the seemingly-familiar if even if that more familiar conditional form ends up being less clear to read.

I think we are all just so used to “create a truth value, then test against that; if it fails, create a different truth value and test that” from other languages that the (at times) more elegant pattern matching features are not used as much. I find myself falling into that trap from time to time, as well.

This is why I asked @DianaOlympos about what they meant, to see if they have a general grump about those constructs or if it is more about wishing people would use them more sparingly in lieu of the other mechanisms offered in Elixir that can be more expressive and readable in some/many cases.

I do find that with the embarrassing riches in conditional constructs that are available, it can be difficult at times to decide which to use when. I wonder if over time there will be a stronger tendency towards a given set of idioms in Elixir, or if over time it will evolve into a more Perlesque acceptance of the multitude of equal paths.