[johnnyjeans]

It should also be noted that handling state like that is not really idiomatic Erlang. State is updated at a process level, thus traditionally you spawn another process which is trivial to do. On the BEAM that is fast enough for 95% of cases. If you really need mutation on local variables for performance reasons, you should already be writing NIFs anyways.

State variables are what I think corpos call a "code smell". The BEAM/OTP isn't a number cruncher, there are better tools out there if you're doing a lot of that. Erlang is, at it's core, about constraint logic programming. It should be best thought as a tool for granular, scalable, distributable userspace scheduling. If you need something outside of that, NIFs or Ports. Both are quite nice.

[asa400]

This has nothing to do with math or number crunching on the BEAM. This has nothing to do with mutation. This has nothing to do with performance.

This kind of process and function-local static single-assignment code is all over the place in Erlang codebases. It's incredibly common. The other popular method is tail recursion.

I searched for literally 30 seconds and found these:

  - https://github.com/ninenines/cowboy/blob/master/src/cowboy_router.erl#L139-L144
  - https://github.com/ninenines/cowboy/blob/master/src/cowboy.erl#L201-L205
  - https://github.com/ninenines/cowboy/blob/master/src/cowboy_http2.erl#L487-L506

[klibertp]

> It should also be noted that handling state like that is not really idiomatic Erlang.

It's not about the state but about intermediate results. When you have a value that you pass to one function, and then you need to pass the result to another function, you're not dealing with a "state" as OTP defines it, unless the calls are asynchronous. Often, they're not, and that's where variable rebinding comes in.

Worth noting: `|>` macro operator in Elixir serves a similar purpose, as long as you don't need pattern matching between calls. In that case, you don't have to name intermediate results at all, resulting in cleaner code.

> State variables are what I think corpos call a "code smell".

Having to call multiple functions in a sequence is the most natural thing to do, and Erlang code is littered with "X1 = ..., X2 = ...(X1), X3 = ...(X2)" kind of code everywhere.

[schonfinkel]

There are some libraries (based on parse transforms) that introduce a sort of "do" notation to deal with this issue (erlando and its variations come to mind).

Also, the latest versions of OTP have introduced the `maybe` expression: https://www.erlang.org/eeps/eep-0049

[klibertp]

I love it. I didn't know. It's going to take a while to make this a pervasive feature of most Erlang codebases, but it seems like a good feature to introduce.

I know there are monad libraries using parse transforms and/or list comprehensions, but I often found their use is frowned upon in the Erlang community. I kind of assumed the GP in this thread would reject them, given their negative opinion on macros.

[schonfinkel]

I was in a similar situation, ended up relying on libs that used parse transforms a lot and then found out most of my usage could have been replaced by the new `maybe` expression.