The primary justification for "you can have any color as long as it's black" approach to coding style & formatting is precisely that the language is a tool, not an art project. Having a single standard well-defined style does wonders to prevent bikeshedding when teams adopt the tool, which is why this approach is increasingly popular (e.g. Black in Python).
And I don't think you can meaningfully compare this to constraints imposed by Rust, which aren't about where to place a curly brace etc, but about not being able to (easily) model some data structures and algorithms. You could argue that both represent a form of tax on your freedom as a developer, but even if so, it's an orders of magnitude difference.
> The primary justification for "you can have any color as long as it's black" approach to coding style & formatting is precisely that the language is a tool, not an art project. Having a single standard well-defined style does wonders to prevent bikeshedding when teams adopt the tool, which is why this approach is increasingly popular (e.g. Black in Python).
I have no problem with standards. There are times where standards are useful. The thing about standards is that they can also be ignored where appropriate. It's notable no one is seriously pushing for Black to be made mandatory for Python, for extremely obvious and sensible reasons. Also, 'increasingly popular' is doing some heavily lifting in that argument. The vast, vast, vast (vast!) majority of Python code will never ever use Black, and that is fine.
A language, as we agree, is a tool, and it is a poor tool indeed that refuses to lend itself for use in creative ways.
> And I don't think you can meaningfully compare this to constraints imposed by Rust, which aren't about where to place a curly brace etc, but about not being able to (easily) model some data structures and algorithms. You could argue that both represent a form of tax on your freedom as a developer, but even if so, it's an orders of magnitude difference.
Very different - Rust's constraints actually serve a purpose beyond merely enforcing stylistic conformity. If I am to take on the added cognitive load of coding a certain way, I might as well actually get something out of it.
It's not like the Zig compiler will refuse to compile unformatted code, either.
And the vast majority of Python code was written before Black was a thing. However, once it appeared, it spread through the ecosystem very quickly. At this point I wouldn't be surprised if most people using Black don't even know that they do so simply because they write their Python in VSCode, which suggests Black (and will install it for you) if you try to do Format Document or enable format-on-save.
> It's not like the Zig compiler will refuse to compile unformatted code, either.
I mean... the use of tabs or LF+CR / CR line endings was a compiler error, last I checked. So, yes, it is exactly like that. And this was a deliberate choice to introduce friction for people who don't hew to the author's stylistic preferences.
> However, once it appeared, it spread through the ecosystem very quickly.
Uh huh, sure, a trendy hipster linter that appeared in 2019 is now so standard that Python code is nigh unthinkable without it. We marvel in the museums at what Python used to look like! There will definitely not be another trendy hipster linter in a couple of years with totally different opinions! :P
And I don't think you can meaningfully compare this to constraints imposed by Rust, which aren't about where to place a curly brace etc, but about not being able to (easily) model some data structures and algorithms. You could argue that both represent a form of tax on your freedom as a developer, but even if so, it's an orders of magnitude difference.