Which Elixir version(s) are you (still) using on your non-pet projects?

Chat / Discussions
,
1

For reference, I’m still on 1.15.7

1 Like
2

I am trying to follow new versions of Elixir and Phoenix, refactoring code as needed. So I am at 1.18.2.

2 Likes
3

1.18.4-otp-27

3 Likes
4

Just upgraded to 1.18. I try to stay 1 behind current.

4 Likes
5

Pet project:

Elixir 1.19.1-otp-28

Erlang 28.1.1

Both seem like great releases

5 Likes
6

We are trying to keep up, though had to skip 1.17 for a bug that never has been fixed in any release if the branch, but actually got backported onto the release support branch.

Now we are working on updating to 1.19 from 1.18, though the deprecation of strict update makes this update non trivial.

2 Likes
7

We are running a couple small but customer facing applications that are still on Elixir 1.12 since it’s inception. The majority are on 1.15 and our flagship is currently on 1.17 which will soon replace most of the smaller systems, and be upgraded to 1.19 early next year.

Edit: also an internal system still used daily that is running Elixir 1.8 which I haven’t touched since upgrading from 1.7. Can’t believe I forgot it since it’s one of the most critical. If it ain’t broke, don’t fix it as they say.

2 Likes
8

Current work project:

elixir 1.18.3-otp-27
erlang 27.3.4.2

2 Likes
9

Most of the time staying on current but sometimes had to stay 1 major version behind.

I think I missed this one, can you give an example or point me to docs?

2 Likes
10

You missed the deprecation of struct update, without matching on the struct first for the type checker?

In the first RC it was a full deprecation of %S{s | a: :new } but now we have to convince the type checker first that s is indeed an S since the second RC IIRC.

11

Oh, that. I saw it on the forum but I could not switch to 1.19 at the time. Thanks for the reminder.

What was the proposed workaround? :thinking:

12

This was the thread I think? which announced there will be a second poll at some point to get community feedback, which seems really split Changes to the struct update syntax

If that is where we’re headed, not so much a workaround as you will get type warnings unless you pattern match before updating the struct with that syntax. So if you don’t really use that syntax (which seems to be most of the people ok with deprecating it and don’t feel strongly really), then it will be just prodding you toward best practices with pattern matching (which hopefully you were already doing). If you were using that syntax heavily as a type guarantee, you will have to do something more than (not necessarily instead of) what you were doing.

It’s honestly not quite clear to me if pattern matching is “better than” struct update in terms of guarantees it provides. It seemed like that’s what José was saying but I didn’t dig in enough to follow.

2 Likes
13

Aha, that’s why I never stumbled upon this problem in my hobby projects recently: I always do both. Thank you.

14

We often have it in situations where we indeed expect crashes:

%S{super(data) | date: decode_date(data["date"]) }

In our deserialisation abstraction now has to be written as:

data = %S{} = super(data)

%S{ data | date: decode_date(data.date) }

This is about 75% of the occurrences I did change so far.

We also played with using Map.put/3 and the Map.updates, though to me it felt wrong using it on structs. Also I lost that when doing some git acrobatics to split a single huge (and erroneous commit) I to several commits I can ship in multiple MRs for easier reviewability.

I am done with yesterday’s runtime code now, but I still have tests to adjust. And at least till we actually update, I’ll have to check the prod code regularly with both versions of elixir.

Removing --warnings-as-errors from our pipeline is not an option.

1 Like