4 ms·
Certainly, and I can also type my JavaScript. But it doesn't happen more than maybe 1% of the time because optional good practices usually fall by the wayside.
by blixt 10y ago
Certainly, and I can also type my JavaScript. But it doesn't happen more than maybe 1% of the time because optional good practices usually fall by the wayside.
This is why Go's simple but strict rules are so key to keeping it clean. Again, I'm not opposed to the alias solution, I just don't think it should be added as a tool with optional good practices accompanying the design spec (e.g., "use it to transition an API and then remove the old aliases").
In his article, Russ argues mainly for the breaking API case, but ends with that general aliases (what was proposed for 1.8) are a promising solution. I think otherwise – a specific use case shouldn't necessarily be seen as an opportunity to apply a generic solution.
- crdoconnor 10y ago>Certainly, and I can also type my JavaScript. Running a linter that catches just unused imports is a one line command (30 seconds), whereas statically typing your javascript essentially requires a full rewrite (weeks or months of work). >This is why Go's simple but strict rules are so key to keeping it clean. There's value in being able to "dial up" the cleanliness as and when its needed. It's often a waste of time to focus on cleanliness of code that you're not sure is going to last. I wouldn't want unused imports to cause a compiler failure even though I run the linter and use that rule regularly.
- blixt 10y agoThat's just evading my point. Go doesn't dial up its cleanliness, it's just clean. And it already does cause a compiler failure if you have unused imports or variables.