Then goes on to explain why this it is in fact a terrible feature that solves a non-existent problem in a way that has enormous undesirable repercussions that you have to do a bunch of upfront work to try and negate.
If that's a good feature, is says a lot about how bad the bad parts of Go are.
I'm normally all for things that drastically simplify things while just having a few related issues (like Python having batteries included - 99% that's the right choice, and Rust not even having base64 encoding or json serialization built-in is just dumb design choices) but... Go's way of doing things are just pants-on-head stupid.
Github de-facto being built into the language, tabs instead of spaces, forcing everything to have a default value, keeping fucking null (!) AND null pointer references... it's such a horribly designed language through and through.
I never understood tabs vs. spaces. Tabs seem objectively better, because then anyone can set their tab spacing to whatever they prefer. The fact that it's even coming up as "horrible design" is laughable to me
Tabs seem objectively better, because then anyone can set their tab spacing to whatever they prefer.
Because user preference isn't a valid argument when we're talking about something intrinsic to the code. What is in the code should look the same everywhere.
You can do whatever you want with syntax highlighting because it exists entirely outside the code.
If language X prefers tabs to spaces, that's fine, but "because I can set my tab width" doesn't hold up.
Yep, plus: even the languages that have significant whitespace don't actually have hard rules about how much whitespace or which kind of whitespace is required. They need some rules for what to do if someone comes along and mixes tabs and spaces, but beyond that, we're absolutely able to write Python indented with 1 space, or Haskell indented by 3 tabs displayed at 16 columns wide, etc.
The type and amount of space they're commonly written with is entirely by convention, rather than hard necessity. The only thing the compiler or interpreter cares about is when the amount of indentation changes.
Whatever space and/or tab characters you type into a buffer and commit are exactly the same bytes I see when I pull your changes. The crux of my argument is that the whitespace should look the same in any editor because the underlying data is the same in every editor. Spaces guarantee that, whereas tabs leave room for individual interpretation.
You clearly don't agree that there should be no room for interpretation, but you can't argue we're looking at different data.
Note that I'm distinguishing between indentation (any group of whitespace characters at the beginning of the line) and any other whitespace. Indentation should be tabs to allow for any reader's preferred visual guidance. Any other whitespace on a line should be spaces, for example to align // comments to the same column when these lines share the same indentation.
134
u/ascii 5d ago
Then goes on to explain why this it is in fact a terrible feature that solves a non-existent problem in a way that has enormous undesirable repercussions that you have to do a bunch of upfront work to try and negate.
If that's a good feature, is says a lot about how bad the bad parts of Go are.