> Opinionated when it makes life easier.
> Tab character in source code is a compile error.
I don't think I will ever understand this. I get that different people have different preferences and reasons for those preferences, but why deliberately alienate such a large set of potential users? Especially after a statement asserting it's to make life easier? Who's life? The developers who will be using the language? I'm not convinced forcing all users to either type more white space or figure out how to configure their editor to auto convert (some of which may not be able to) is really making life easier. Or is it for the language developers themselves? In which case I'd argue that's probably the wrong thing to be optimizing for, and that it isn't that difficult to support both anyway.
And to be clear, I'm not interested in litigating the tabs vs spaces debate here, or even white space as part of code/syntax. It's this attitude that I'm seeing a lot more in recent years of 'I know better than you how you should do/use _X_ so I'm not going to give you the option'. Obviously not every project out there can be tailorable to every user's every preference, but I wish that when deciding what to accommodate and what not to, it would be done not on one's own myopic perception of the problem space, but on actual limitations and priorities and user needs. And when making a choice that may not be widely popular, be up front about why and how that decision was made. I'm much happier accepting 'not enough dev resources to support the added complexity in the parser' than I am 'tabs are stupid and you're dumb for wanting to use them'.
That is an opinionated decision to make tabs a compile error. It sounds like it offended you somehow, since nowhere does it even imply "tabs are stupid".
There could be a reasonable explanation, for example, that having two different characters for white space is redundant and unnecessary. We may not agree, but making it an error to use tabs is an effective way to avoid any bike shedding about this contentious topic.
It's similar to the Go formatter enforcing tabs for indentation and white space for alignment. It doesn't matter what I may think is the correct answer to the tabs/spaces question because I would never bother doing that manually. Either let some tool do it automatically, or don't allow tabs at all - which I'm guessing is how Zig's formatter works, by replacing tabs with white space.
I also think these features are no good. I agree with you, I don't like this attitude of "I know better than you how you should do/use _X_ so I'm not going to give you the option" and the related stuff (and it is found in other computer programs too).
(In addition to the opinions about tabs, and about trailing spaces (which you did not mention, but it is related; when writing programs in C, I often have trailing spaces in incomplete programs), it also uses UTF-8.)
However, it might make sense to disallow tabs inside of string literals if you want "secure character set" (in which case disallowing trailing spaces inside of multi-line string literals also makes sense), but then you should not allow non-ASCII characters either (if you need non-ASCII text, it can either be escaped, or loaded from a separate file; the ability to run arbitrary code at compile-time would make this easy enough to do).
(Even then, it would probably make sense for "secure character set" to be an option (whether enabled or disabled by default) rather than mandatory, anyways.)
I don't think I will ever understand this. I get that different people have different preferences and reasons for those preferences, but why deliberately alienate such a large set of potential users? Especially after a statement asserting it's to make life easier? Who's life? The developers who will be using the language? I'm not convinced forcing all users to either type more white space or figure out how to configure their editor to auto convert (some of which may not be able to) is really making life easier. Or is it for the language developers themselves? In which case I'd argue that's probably the wrong thing to be optimizing for, and that it isn't that difficult to support both anyway.
And to be clear, I'm not interested in litigating the tabs vs spaces debate here, or even white space as part of code/syntax. It's this attitude that I'm seeing a lot more in recent years of 'I know better than you how you should do/use _X_ so I'm not going to give you the option'. Obviously not every project out there can be tailorable to every user's every preference, but I wish that when deciding what to accommodate and what not to, it would be done not on one's own myopic perception of the problem space, but on actual limitations and priorities and user needs. And when making a choice that may not be widely popular, be up front about why and how that decision was made. I'm much happier accepting 'not enough dev resources to support the added complexity in the parser' than I am 'tabs are stupid and you're dumb for wanting to use them'.