I have and they are not addressed, that's why I commented as such. How would I know that one of the reasons you think <> are hard to read is because they are used as comparison and bitshift or that you intend () as indexing syntactic sugar if I hadn't read them? As for the second, I didn't think how different languages managed to parse them matters as long as it doesn't impact compilation times significantly, hence my comment.

If you read more than just the headings, you'd find out that your objections have been addressed in the article. ;-)

Also dropping here the list of contrarian views op listed in the next article:

Language Design: Popular, but Wrong

1. static members
2. properties
3. <> for generics
4. [] for arrays
5. Type ident instead of ident: Type
6. having if-then-else and switch/case and a ternary operator
7. having both modifiers and annotations
8. async/await
9. separate namespaces for methods and fields
10. method overloading
11. namespace declarations doubling as imports
12. special syntax for casting
13. using cast syntax for things that are not casts
14. requiring () for methods without parameters

1. <> is hard to read for humans

Not really. <> is unusually pointy among the brackets and comparisons / bitshifts are used in different places than generics are so I've never confused them.

2. <> is hard to parse for compilers

I guess? Does this meaningfully increase compilation times?

3. It makes the uses of brackets confusing and inconsistent

No. A language that uses () for parameter lists, literals and indexing is much more mentally taxing to parse

It's a bit of a change but certainly the right thing to do.

My only disagreement with the article is the get/set stuff. I still want to keep something like the old container[index] syntax, maybe container.[index] to indicate that it's a form of access. As long as generics go after names, this would not cause ambiguity.

Stop using types for variables

I think if someone's curious about that they might be in the market for something more like just, as in, here's an example for running recipes with uv or use [script($INTERPRETER)].