* Backwards compatibility is a priority so you can be pretty sure code you wrote yesterday will work tomorrow
More Cons:
* Unused variables and imports are a compilation error which is INCREDIBLY annoying during development (number one frustration with the language)
* If you work with a team or a legacy project, you will almost certainly encounter panics from a nil dereference at some point (or in my experience basically all production bugs were the result of one)
* If you work with a legacy project, early lack of generics encouraged copy/paste spaghetti piles
* Due to early lack of real generics, many popular libraries (such as ent) used codegen to make generic behavior possible. Generated code balloons PRs (unless you take care to quarantine them to their own commit and share commit ranges for diffs), and gets in the way of understanding code you care about.
>Unused variables and imports are a compilation error which is INCREDIBLY annoying during development
It's easily solved with:
_ = unused_variable
_ "unused_import"
Sure, it's annoying, but not in an incredible way :) Before I knew about this trick, I used to temporarily delete or comment out all related code, which is indeed incredibly annoying.
I know about it. Still incredibly annoying. I shouldn't need to do anything, it should just be completely ignored unless I run a linter or compiler in pedantic mode.
Unused variables are an indication that the author hasn't completed their thought, so to speak, in the best case. In the worst case, it's a mistake and indicates the code is likely implemented in a way that it does something other than what it intended. I think making it a compiler error is the right way to do it. Other languages should adopt it.
The thing about software in development is that it isn't complete, practically by definition. I don't litter my code with unused imports and variables, I just have some stuff hanging out below while fixing it above. This is what linters are for, and unused variables and imports weren't the thing making software unmaintainable. Could even have a compiler flag that errors on unused for prod builds. There are a bunch of ways to skin a cat.
* Compiling to a single binary is awesome
* Rich library ecosystem at this point
* Backwards compatibility is a priority so you can be pretty sure code you wrote yesterday will work tomorrow
More Cons:
* Unused variables and imports are a compilation error which is INCREDIBLY annoying during development (number one frustration with the language)
* If you work with a team or a legacy project, you will almost certainly encounter panics from a nil dereference at some point (or in my experience basically all production bugs were the result of one)
* If you work with a legacy project, early lack of generics encouraged copy/paste spaghetti piles
* Due to early lack of real generics, many popular libraries (such as ent) used codegen to make generic behavior possible. Generated code balloons PRs (unless you take care to quarantine them to their own commit and share commit ranges for diffs), and gets in the way of understanding code you care about.