Seems pretty good.

I’d think the most ‘pure’ way of thinking of bindings are as unevaluated closures, so even doing just a = 4 means define a 0-arity function a in the current scope with the running environment that just returns a 4 and does nothing else, or that b = a * 64 is a 0-arity function like the above and uses the a in the current scope, calls it, takes its value and returns it multiplied by 64. In old functional design see:

let tester =
  let a = 4
  let b c = a * c
  let d e f = e * b f
  d 4 4

Is essentially just like a 0-arity function a that returns an integer, a 1-arity function b that returns an integer, a 1-arity function d that returns a 1-arity function <anonymous> that returns an integer, and the top 0-arity tester function that returns an integer. In Functional programming everything is a Function in concept.

As I understand it (read it with scepticism), in case of Elixir:

1. binding would be an expression, assignment is statement.
2. In Elixir = is basically a pattern matching with binding(?)
3. Since BEAM has only immutable values, binding making much more sense. Maybe I’m simplifying a lot - assignment assigns some literal (textual representation) to a place in memory, so changing variable X changes data in memory it was pointing to. In case of binding changing X changes only it’s pointer (so it points to another place in memory and does not affect original data it was pointing to)

Hope I did not write some non sense

Great question

I’ve also wondered the same thing.

So would it be safe to say the following?

Binding has to do with giving names to things (or values) in a given well delimited context. Assignment is about storing things (or values) in some location (a variable)

From: terminology - What is the difference between assignment, valuation and name binding? - Computer Science Stack Exchange

The code you showed works. However, we usually try to reduce the number of single use variables. So, the “Elixir way” of writing that code is

var1 = 
  123
  |> get_new_value(:something)
  |> get_new_value(:something2)

Furthermore, if it was the last statement in a function, then we would drop the var1 like this:

def my_fun do
  # ...
  123
   |> get_new_value(:something)
   |> get_new_value(:something2)
end

Since everything is immutable and also there is nothing shared between 2 BEAM processes[1], there is no issue with that code in terms of concurrent processing.

[1] Well, in fact, large binaries are shared across processes, but as they are still immutable we do not get any problems because of this as well.