{. singleEqualsTests .}
if x = 1:I have used Modula and Oberon with "=" for equality check and ":=" for assignment for a few years...
Assignment occurs more often than equality check, typing ":=" is not much fun, and reading that is also not really nice. Comparison with math (as Wirth did 50 Years ago) is not really helpful. Math is a different area, where equality check occurs often, but assignment very rare. "==" for equality check is very common today, and the two letter sign matches well with !=, >= and <=. Learning to use == for equality check is really easy. Of course it can occur that due to a typing error we write an assignment instead of a comparison. But there is much more what we may do wrong.
"I assume == was introduced by C for what was at the time a good reason with early 70s computer limitations."
Er, no. What kind of limitations would those be?
Algol used = for equality and := for assignment. FORTRAN used .EQ. and = for assignment. The designers of C and its predecessors chose differently, and it was a pretty good choice IMO. In any case, it is now widespread and Nim adopted it. Allowing either has far more cons than pros.
"Of course it can occur that due to a typing error we write an assignment instead of a comparison."
Not in Nim ... that's a syntax error. (Although the error message is obscure and confusing.)
Stefan Salewski: Assignment occurs more often than equality check, typing ":=" is not much fun, and reading that is also not really nice. Comparison with math (as Wirth did 50 Years ago) is not really helpful. Math is a different area, where equality check occurs often, but assignment very rare.
The general problem with using = for assignment and == for equality is that it's known to confuse people who learn programming. Understanding the role of assignment in imperative languages tends to be the single biggest obstacle for novice programmers (part of the reason why functional languages can sometimes be better at easing people into programming), and conflating the notation for assignment with the mathematical notation for equality that people are used to from school or college complicates this further.
That said, (1) Nim isn't a teaching language and (2) the ship really, really has sailed. The syntax can't be changed retroactively, and introducing optional alternate forms would only introduce a number of Nim dialects that in the end destroy readability because everybody writes in a different style and make tooling harder (the Perl disease). There are plenty of things for which I would have preferred a different style myself (incidentally, that includes having := for assignment and = for equality), but these subjective preferences can really go either way. In the end, it's a pointless distraction. My ultimate interest in Nim (as someone who is actually using the language for real work) is to get stuff done, not to debate forever how to dress up that stuff in a myriad different ways.
Syntax arguments in general are bad because they rely so heavily on personal opinion and preference and have little backing in scientific fact. That means that everybody has an opinion, that there are plenty of different opinions, and nobody really has a way of conclusively ending the debate. This then results in a discussion that can go on and on and on and at some point the language designer has to make a decision and stick to it. That has happened and unless somebody has an argument backed by actual studies that the alternative is a significant improvement, that should be the end of the story.
"Understanding the role of assignment in imperative languages tends to be the single biggest obstacle for novice programmers"
I've encountered a lot of novice programmers in my decades in the field and that's not what I've observed. Even when people steeped in mathematics -- which most novice programmers aren't -- encounter assignment, they quickly learn that variables are like pigeonholes that you can stick stuff into and take stuff out of.
The primary problem I see with novices is that they are inattentive to detail. They can stare at their code for hours and not notice that they have = in an if expression where they intended ==. But this is largely an obsolete problem with compilers that warn about assignments in boolean context, and in Nim it's an outright error -- although the error message could be a lot better:
var x = 0 if x = 0: discard x.nim(2, 6) Error: ':' expected
"to get stuff done, not to debate forever how to dress up that stuff in a myriad different ways"
The '==' makes no effort to type it. You simply repeat the key.
We live with C since the 80ies. Why to reinvent the wheel?