5 ms·

This article is from 2016, but it's still relevant. Even in medium sized projects I've been bitten by many of these issues, and for a language that's supposed t

This article is from 2016, but it's still relevant. Even in medium sized projects I've been bitten by many of these issues, and for a language that's supposed to eschew magic, there's an awful lot of wizardry going on. Stopping compilation with an error for every unused import & variable is particularly annoying, so much so that I've patched the go compiler to treat them as warnings instead [1]. Ultimately, I think the problem boils down to a language that outgrew its original design, and hasn't evolved elegantly (yet). [1] https://github.com/kstenerud/go https://github.com/kstenerud/go

maxaf 7y ago
Your fork of Go promotes poor code quality. How’s this different from driving a car with an unbuckled seatbelt draped surreptitiously over the shoulder? The feeling of smug superiority must be intoxicating, but the risk of a violent ejection after a crash and subsequent death is still there.
- macintux 7y ago
  Certainly one difference is this: if I’m developing a one-off tool, or simply in early stages of development, it’s closer to being in a driving simulator with the seatbelt unbuckled. Not every line of code is life or death.
  - solarkraft 7y ago
    To expand on the metaphor: Imagine driving slowly and having to jump out of the car a lot.
    - stcredzero 7y ago
      A new car chassis in development might well get driven around with out a body and windshield attached, slowly around a test track.
- solarkraft 7y ago
  Does it? In my explorations I had to add bogus operations to variables and imports so the compiler wouldn't explode on me while commenting stuff out.
- staticassertion 7y ago
  Unused imports are something I have all over my codebase before I get it to production. It's not worth dealing with in my development loop, and it would just be an annoying distraction
blablabla123 7y ago
Half of these issues are solved by linters which are also well integrated into virtually all common editors/IDEs. Also regarding warnings/errors: time-travelling back into the 90s it was normal that C/C++ code - also in Open Source Projects - was full of warnings and often not portable across compiler/library versions. That was a major pain, I remember myself experimenting a lot with compiler flags (-Weffc++, -strict etc.) for my own code that also prevented stepping into common pitfalls.
- astrange 7y ago
  Warnings are part of the compiler not the code, and if your project is complicated enough you'll always hit false warnings in some version of the compiler, because some gcc contributor just snuck in a false positive, or a library you're using deprecated something. Everything being an error makes this worse not better; if -Wdeprecated turns into an error you're just not going to be able to fix everything in someone else's code. Unused code being an error is easy to fix, but it's so disrespectful. I shouldn't get compile errors as I'm editing when I haven't done anything wrong.
- kstenerud 7y ago
  Yes indeed. Hatred of projects full of warnings is one of the hallmarks of a good programmer. Except that it only happens in C and C++. Why? Because C and C++ were designed to have sharp edges for you to cut yourself. The default behaviors are absolutely bizarre and stupid, and the breadth of things that are undefined behavior guarantees that any given program is non-conformant. Warnings and -Werr and linters were the only possible ways to keep any semblance of sanity and code quality. But we're not talking about those dangerous languages and their sordid history. We're talking about the here and now and modern languages, where an unused import NEVER causes bugs, and where unused values aren't flagged as errors in any other language for good reason: we debug code far more often than we write it, and slowing the debug process for the sake of cleanliness is stupid. And it still astonishes me how unused values are treated as errors in a language that happily allows variable shadowing that is literally one colon away (= vs :=), and doesn't allow file-level variable and function isolation. Those are FAR more dangerous and bug inducing.
cr0sh 7y ago
> Stopping compilation with an error for every unused import & variable is particularly annoying It's been a long while since I last touched Golang, but I recall the process of learning it. My coworker and I were tasked with creating an interface for our employer (a cloud service provider) to allow Rancher (or clients of Rancher - I forget) to use our backend system (which was built out of a combination of PHP, Java, and Bash - among other parts) to provision servers. Neither my coworker or I had ever touched Go; we were PHP developers. But Rancher used it, had examples, and we set out to learn it (while we were employed as PHP developers, we both had extensive prior experience with a number of other languages). It took about a week until we were comfortable enough to begin our implementation, and about a month later we had a working library written in Go that we understood and had documented well, with tests. But the process: Exactly like you noted! We railed, we gritted our teeth! We shook our fists at heaven and loudly proclaimed "WHY?!" Because we were so used to leaving things lying about in PHP; for experimentation, debugging, and other reasons. But Go wouldn't let us - no-siree-bob! - you had to make it just so before it would successfully compile, and we tore our hair out over it. Day after day, week after week...and then: Something changed. We understood. We realized why the designers of Go did what they did, and we also started to wish fervently that PHP could be the same way. We also noticed that by these changes, we no longer needed to leave this "cruft" around, this "dead code" that could possibly cause us to trip up, or wonder if it was needed later, or whatever. Yes, it made development more difficult - but we came to recognise that it helped greatly to prevent errors, or future problems, and kept things very maintainable. But like I said - I haven't used Go in years since that time; there hasn't been a call or need for it, but it is a language that I keep in my "back pocket" just in case I ever need it. Maybe things have changed a lot since then, or maybe they haven't. Regardless, I learned from that experience that sometimes you have to power and struggle through things before the revelation appears. I got to experience a fairly unique language, and I feel that I'm better as a developer for it.
- mixmastamyk 7y ago
  Yes, I think the idea is good. Maybe less annoying if there could be a lax dev mode (-d) that didn't complain about such things until you were ready and in the cleanup stage. Then you'd run format and it would compile in normal mode.
masklinn 7y ago
> Stopping compilation with an error for every unused import & variable is particularly annoying I think the worst part of that decision is I've never seen a bug arise from unused imports and variables (even in languages with ubiquitous importing side-effects like Python, imports and import ordering can cause issues but usually you need the import anyway, you can't just nuke it). Meanwhile variable shadowing / overwriting or unused return values which do cause issues are perfectly fine by the compiler.

maxaf 7y ago

Your fork of Go promotes poor code quality. How’s this different from driving a car with an unbuckled seatbelt draped surreptitiously over the shoulder? The feeling of smug superiority must be intoxicating, but the risk of a violent ejection after a crash and subsequent death is still there.

macintux 7y ago
Certainly one difference is this: if I’m developing a one-off tool, or simply in early stages of development, it’s closer to being in a driving simulator with the seatbelt unbuckled. Not every line of code is life or death.
- solarkraft 7y ago
  To expand on the metaphor: Imagine driving slowly and having to jump out of the car a lot.
  - stcredzero 7y ago
    A new car chassis in development might well get driven around with out a body and windshield attached, slowly around a test track.
solarkraft 7y ago
Does it? In my explorations I had to add bogus operations to variables and imports so the compiler wouldn't explode on me while commenting stuff out.
staticassertion 7y ago
Unused imports are something I have all over my codebase before I get it to production. It's not worth dealing with in my development loop, and it would just be an annoying distraction

blablabla123 7y ago

Half of these issues are solved by linters which are also well integrated into virtually all common editors/IDEs. Also regarding warnings/errors: time-travelling back into the 90s it was normal that C/C++ code - also in Open Source Projects - was full of warnings and often not portable across compiler/library versions. That was a major pain, I remember myself experimenting a lot with compiler flags (-Weffc++, -strict etc.) for my own code that also prevented stepping into common pitfalls.

astrange 7y ago
Warnings are part of the compiler not the code, and if your project is complicated enough you'll always hit false warnings in some version of the compiler, because some gcc contributor just snuck in a false positive, or a library you're using deprecated something. Everything being an error makes this worse not better; if -Wdeprecated turns into an error you're just not going to be able to fix everything in someone else's code. Unused code being an error is easy to fix, but it's so disrespectful. I shouldn't get compile errors as I'm editing when I haven't done anything wrong.
kstenerud 7y ago
Yes indeed. Hatred of projects full of warnings is one of the hallmarks of a good programmer. Except that it only happens in C and C++. Why? Because C and C++ were designed to have sharp edges for you to cut yourself. The default behaviors are absolutely bizarre and stupid, and the breadth of things that are undefined behavior guarantees that any given program is non-conformant. Warnings and -Werr and linters were the only possible ways to keep any semblance of sanity and code quality. But we're not talking about those dangerous languages and their sordid history. We're talking about the here and now and modern languages, where an unused import NEVER causes bugs, and where unused values aren't flagged as errors in any other language for good reason: we debug code far more often than we write it, and slowing the debug process for the sake of cleanliness is stupid. And it still astonishes me how unused values are treated as errors in a language that happily allows variable shadowing that is literally one colon away (= vs :=), and doesn't allow file-level variable and function isolation. Those are FAR more dangerous and bug inducing.

cr0sh 7y ago

> Stopping compilation with an error for every unused import & variable is particularly annoying It's been a long while since I last touched Golang, but I recall the process of learning it. My coworker and I were tasked with creating an interface for our employer (a cloud service provider) to allow Rancher (or clients of Rancher - I forget) to use our backend system (which was built out of a combination of PHP, Java, and Bash - among other parts) to provision servers. Neither my coworker or I had ever touched Go; we were PHP developers. But Rancher used it, had examples, and we set out to learn it (while we were employed as PHP developers, we both had extensive prior experience with a number of other languages). It took about a week until we were comfortable enough to begin our implementation, and about a month later we had a working library written in Go that we understood and had documented well, with tests. But the process: Exactly like you noted! We railed, we gritted our teeth! We shook our fists at heaven and loudly proclaimed "WHY?!" Because we were so used to leaving things lying about in PHP; for experimentation, debugging, and other reasons. But Go wouldn't let us - no-siree-bob! - you had to make it just so before it would successfully compile, and we tore our hair out over it. Day after day, week after week...and then: Something changed. We understood. We realized why the designers of Go did what they did, and we also started to wish fervently that PHP could be the same way. We also noticed that by these changes, we no longer needed to leave this "cruft" around, this "dead code" that could possibly cause us to trip up, or wonder if it was needed later, or whatever. Yes, it made development more difficult - but we came to recognise that it helped greatly to prevent errors, or future problems, and kept things very maintainable. But like I said - I haven't used Go in years since that time; there hasn't been a call or need for it, but it is a language that I keep in my "back pocket" just in case I ever need it. Maybe things have changed a lot since then, or maybe they haven't. Regardless, I learned from that experience that sometimes you have to power and struggle through things before the revelation appears. I got to experience a fairly unique language, and I feel that I'm better as a developer for it.

mixmastamyk 7y ago
Yes, I think the idea is good. Maybe less annoying if there could be a lax dev mode (-d) that didn't complain about such things until you were ready and in the cleanup stage. Then you'd run format and it would compile in normal mode.

masklinn 7y ago

> Stopping compilation with an error for every unused import & variable is particularly annoying I think the worst part of that decision is I've never seen a bug arise from unused imports and variables (even in languages with ubiquitous importing side-effects like Python, imports and import ordering can cause issues but usually you need the import anyway, you can't just nuke it). Meanwhile variable shadowing / overwriting or unused return values which do cause issues are perfectly fine by the compiler.