I'm talking about quantity not the popularity of a given language. There are certainly a number of popular languages that follow that convention

The basic problem is that identifiers can be either types or variables, and without a keyword letting you know what kind of statement you're dealing with, there's no way of knowing without a complete identifier table. For example, what does this mean:

foo * bar;

If foo is a type, that is a pointer declaration. But if it's a variable, that's a multiplication expression. Here's another simple one:

foo(bar);

Depending on how foo is defined, that could be a function call or a declaration of a variable bar of type foo, with some meaningless parentheses thrown in.

When you mix things together it gets even more crazy. Check this example from this article:

foo(*bar)();

Is bar a pointer to a function returning foo, or is foo a function that takes a bar and returns a function pointer?

let and fn keywords solve a lot of these ambiguity problems because they let the parser know what kind of statement it's looking at, so it can know whether identifiers in certain positions refer to types or variables. That makes parsing easier to write and helps give nicer error messages.

any new keyword could break backwards compatibility

Wouldn't that happen anyway with variable and function names? Any type other than primitive/built in ones are usually camel case so lower case keywords are more likely to clash with single word variable and function names, unless you restrict the cases of those too or allow keyword overriding or something.

Ah I was misunderstanding the problem. And learned something new about C#, seems in order to avoid breaking existing code they introduce "contextual keywords" var being added later, it is a contextual. You can create a class 'var' and the compiler will prefer it.

At least in C#, you can define variables with keyword names like this:

var @struct = "abc"

I think in Kotlin you can do the same, and even include spaces with backticks like val abstract class = "abc"

I'm not sure if other languages allow that, regardless it should be rarely used.

Yeah, I missed the custom allocator at first. I thought I deleted my comment fast enough, but I guess you were faster. :)

As long as you call .collect() on it at the end, don't need to write the entire type as it is a method with a generic parameter, and returns that generic.

The intermediate iterators though, those are hell. Especially if you pass it to a lambda and for some reason rust can't infer the type.

I once came across a parsing library that did the parsing with basically just the type system. It was absolute hell to debug and build. Types of parsers would be hundreds of characters long. It would take tens of minutes to build a simple parser.

I don't know much much time it would take to build a complex parser, since it was unable to. it reached the max type generic depth of the rust compiler, and would just refuse to compile.

I believe it was called Chomsky or Chumsky or something like that. Discovering nom was a blessing.

Frankly, I have way more often ended up scratching my head for some cryptic piece of syntax than the opposite. Sure I could sit down and spend the rest of my life learning each language designer's favourite syntax optimisations, but I kinda don't want to. I'm a human, not a parser.

And frankly, a good IDE editor should be able to fold/unfold verbose syntax. Better for it then to be there and folded, than for it to not be there and for someone to have to work backwards the intendrd meaning of every single line of code.

I am not married to any particular language's syntax choices but sure if we want to play "make it feel like C++":

std::cpp26::string a : std::cpp26::make_unique( std::cpp26::string{} );

I could try and pass it through a number of iostreams or a to_array conversion to see if I can push a to_string() in somewhere...

Older variants used DIM for arrays and LET for other variables. DIM was originally called that because it was setting the dimensions of the array.

In modern BASIC variants, DIM has become a backronym: "declare in memory".