What would you like to see in Elixir 2?

Chat / Discussions
,
1

This is just a random question about what the community would expect in a bigger Elixir release

4 Likes
2

I’d expect to not see an 2.0 release at all.

Because it would be accompanied by probably a lot of breaking changes.

A breaking release in a language can massively affect its ecosystem and probably make abondoned but broadly used packages from hex a hurdle to update other packages.

25 Likes
3

Did someone say python? :stuck_out_tongue:

12 Likes
4

Well, python did it right v1 to v2.

2 Likes
5

My personal whishlist, though maybe some of these could happen in a 1.x release

  • no more dot-call syntax for lambdas - it’s unfamiliar to newcomers.

  • removal of charlist literals - newcomers get tripped up on integer lists appearing as strings in terminals, or accidentally using charlist when they intended binaries.

  • removal of the Elixir. prefix on module names - this makes calling into Elixir from other beam languages feel second class.

  • Type parameters for Enumerable.t so that the collection element type is better documented.

  • inclusion of the Gradualizer type checker or something like it.

  • An ETS module in the elixir std lib - ETS match specs are intimidating at first

  • A pipe operator that plays nicely with lambdas (like F#, Elm, etc)

16 Likes
6

Algebraic data type support. This is very important to me.

6 Likes
7

I’d expect everything that’s deprecated now to be removed. That’s it.

5 Likes
8

I’d like to see the single quote be allowed in variable name, like haskell.

state’ = fun(state)

Currently you see all sorts of personal habits, n_state, new_state, state2 etc.

1 Like
9

Wouldn’t this make code a little more difficult to read? I try to name transformed variables by assigning a descriptive prefix, for instance

def assign_rank(students) do
  sorted_students = Enum.sort_by(students, fn x -> x.rank end)
  ranked_students = Enum.with_index(sorted_students, ....)
  #...
5 Likes
10

@minhajuddin, many times, your suggestion is the perfect solution. However, alot of times when you are just mutating state, the result is more or less just “the updated state”, and the appropriate prefix is adhoc, (updated_, new_, changed_ …).

11

Why not none at all? Re-binding is allowed for a very good (IMO) reason. And a lot of the time, re-binding repeatedly is a hint that you should use a pipeline.

5 Likes
12

@sribe, rebinding seems to be a mood type thing, somedays, in some code I rebind all day long:)

If it’s my own personal private sideproject, it’s a much easier move. But programming in the large, I think rebinding is a small increase in the the maintenance debt.

13

I disagree. mydata_sorted & mydata_filtered might be OK, but with something like mydata' or mydata'' it is way too easy to pass the wrong version of the data, especially when refactoring. In fact, I’d argue not just that this feature is not really needed in Elixir, but that we should keep it out because it would be detrimental.

9 Likes
14

To try to achieve text processing capabilities on the level of the best text processing languages, e.g. Perl, change this blasted function:

update(map, key, initial, fun)

Updates the key in map with the given function.

If key is present in map with value value , fun is invoked with argument value and its result is used as the new value of key . If key is not present in map , initial is inserted as the value of key . The initial value will not be passed through the update function.

so that it operates like this:

If key is present in map with value value , fun is invoked with argument value and its result is used as the new value of key . If key is not present in map , fun is invoked with argument initial.

15
  1. It’s an arbitrary decision, meaning: in some cases it would be more convenient in the way you describe, and in some cases it will be more convenient as it is. 2) In the cases where it would be more convenient, it is at best a tiny, tiny convenience.
16

I think this is a bad reason.

The best Elixir in Jose’s head is probably a lot different from how it looks in 1.x.

That’s just natural, we all learn and evolve.

Breaking things shouldn’t put a stop to evolution.

Perhaps having a stable 1.x and a experimental branch which breaks things for a few years, and eventually gets to a nicer equilibrium is the way to go.

I doubt we’ll ever benefit from all the learning over the past years if stuff cannot be broken : /

8 Likes
17

Objects

Jkjk, don’t kill me.

3 Likes
18

Elixir has lots of kinds of objects!

There are tuple objects: {}
List objects: []
Map objects: %{}
And a lot of others like closure objects, unique reference objects, process identifier objects, etc…

^.^

7 Likes
19

One thing: static type checking.

15 Likes
20

I saw a project on GitHub the other day that did this at the Erlang level, via dialyzer types.
EDIT: found it

3 Likes