I'm not trolling, but I'm very serious about language design after going through a long gauntlet. I don't think making mutation easy, and also having the ability to hide code execution, is necessarily a good practice in a system principally designed for safe, robust and efficient concurrency. Don't use a flathead on a phillips screw.

▲ asa400 a day ago | parent [-]

Rebinding is not mutation. This seems pedantic but is an important distinction. None of the semantics of the runtime are changed. The data remains immutable. You probably know this. However, for the benefit of readers who may be less familiar: Erlang does not allow variables to be rebound, so it's somewhat typical for Erlang code like this:

  X1 = 8.
  X2 = X1 + 1.
  X3 = X2 * 302.

You cannot, say, do this:

  X1 = 8.
  X1 = X1 + 1.

This is because in Erlang (and in Elixir) the `=` is not just assignment, it is also the operator for pattern matching. This has implications that are too broad for this post, but the key point here is that it's attempting to see if the the left side and the right side "can match".

Whereas writing the same thing in Elixir would look like:

  x = 8
  x = x + 1
  x = x * 302

This is because Elixir allows `x` to be rebound, in effect changing what data `x` points to, but not mutating the underlying data itself. Under the hood Elixir rewrites each expression into something resembling the Erlang version.

The practical effect of this is that if you for example insert a process spawn somewhere in between any of the lines that references `x`, that process gets its own totally immutable version of the data that `x` points to at that point in time. This applies in both Erlang and Elixir, as data in both is completely immutable.

▲ johnnyjeans a day ago | parent [-]

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 21 hours ago \| parent [-]
		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`