This is touching on a pet peeve of mine: Mathematics and programming are similar in many aspects, but this is not one of them. In mathematics = is not a comparison, but a statement.
More generally, mathematics is about tautologies, that is statements that are always true. In programming, a comparison is evaluated to either true or false.
That doesn’t mean that there’s no room for conditionals in mathematics (one example is piecewise function definitions). But it’s not the same. Heck, even the definition of “function” is different between mathematics and programming.
As a new language design feature procedures could be assigned to references for reuse in the same way as calling a function by name/variable.
"let x = 1" has the same meaning in mathematics as well as JavaScript and Rust.
Historically, distinguishing an equality operator from an assignment one has existed for many decades. Whether using colon for the latter is "absolutely correct" is the subject of valid debate.
An equally compelling case could be made for any of the following assignment operators as well:
foo <- 42
foo -> 42
foo <= 42
foo => 42
foo <-> 42 if expressing substitutability is important
foo := 42 Pascal lives!
(foo 42) so does LISP!
foo is 42 for those who prefer English operators
f(foo) = 42 for mathematically inclined languages
Personally, I think this argument only holds water for languages that are rooted in mathematics (e.g. Haskell, Lean, Rocq, F*, ...). If your computational model comes from a place of physical hardware, instructions, registers, memory etc. you're going to end up with something very different than an abstract machine based on lambda calculus. Both valid ways to design a PL.
(I find it baffling in the extreme that in many mainstream languages the convention is to write type annotations as “x: T”, both prima facie and because in those languages the notation then collides with field assignment!)
f(x) = x * 2
-> for definition is just annoying. On every keyboard layout, it takes two strikes to type, possibly with shift involved.
Then again I quite like rewriting languages like Mathematica and lean
For example, in most languages you have a notation like f(g(h(x))) which calls the functions in the exact opposite order of reading which is unnecessarily confusing.
c = a + b;
Nope, make it explicit. You're moving the value of an expression to a placeholder. The only sensible way to write that would be
ADD a TO b GIVING c
Instead of := you should use => for assignment.