Though Go is not my favorite language, I’m glad that it’s the favorite language of a growing number of programmers. I really like when a piece of software that I want to use is written in Go, because installation is usually just copying a statically-linked executable in my $PATH. Quite the difference from software written in Python where I have to run them in a venv or software written in Node.js which requires downloading hundreds of megabytes of dependencies.
I don’t use it for my own projects, but I agree with a lot of the things here, and it makes contributing to Go projects a breeze, regardless of what I think of the language as such.
I remember back in the day, there was something weird about paths and whatnot? It never made sense to me, but these days it seems to Just Work.
Have gopls installed and just do the thing, never any trouble scratching my own itch and landing patches.
Originally one would have to keep all of their Go code under the $GO_PATH/src directory. I only briefly used Go during this time so I my recollection is foggy. But thankfully the Go people and the community settled around Go modules.
I legitimately do not understand why people rank code formatting as such an important feature. It’s fine. It’s a nice convenience, but I can take or leave it.
I’ve worked in projects with strict formatting, and loose everything-goes policies. Code formatting has literally never been a major pain point for me in more than fifteen years of software.
I worked before the days of code formatting and there were a lot of places that would have at least a few programmers who would bicker in code reviews about stupid style stuff. Go didn’t invent code formatting, but it was the first language with a single standard across the entire ecosystem.
What you’re describing is a serious social problem, not a technical one, and “solving” it with a technical solution is inappropriate because people like that will just find another thing to bicker about.
Not necessarily. Most programmers would agree that it’s important for a code base to have a single, consistent style and you either do that automatically or you invite engineers to police style in code review with all of the incumbent pedantry and drama. You contend that a technical solution can’t solve a social problem, but I think that framing is bad–the social problem is requiring people to choose between a consistent style and policing style stuff in code review; this “technical solution” allows us to have both.
Even if you prefer your “technical solution can’t solve social problem” framing, it’s a matter of theory versus evidence. You theorize that a code formatting tool can’t work, but in practice it seems to work very well. By your own admission, programmers generally rank it as an important feature.
Most programmers would agree that it’s important for a code base to have a single, consistent style
Why? Does this actually impact code quality in a way that matters? Or is it just papering over more serious social issues in the team? You’re begging the question.
You contend that a technical solution can’t solve a social problem, but I think that framing is bad–the social problem is requiring people to choose between a consistent style and policing style stuff in code review; this “technical solution” allows us to have both.
No, my contention is that this argument is a waste of everyone’s time and a sign of dysfunction. I believe this is a clear case of bikeshedding.
You theorize that a code formatting tool can’t work, but in practice it seems to work very well.
I never said you can’t perform automatic formatting. I am saying that it’s not important. My argument is that just because you can automate something doesn’t mean it’s providing value.
Why? Does this actually impact code quality in a way that matters? Or is it just papering over more serious social issues in the team? You’re begging the question.
The argument, which you can choose to accept or not, is that consistent style makes it easier to understand code. Maybe you could argue that programmers’ professed inability to work as effectively in a codebase with/out standard style is a “social issue” on their part, but as a hiring manager I would rather spend 5 minutes slapping on a code formatter than finding candidates who work as effectively in a code base with standard style as without. Similarly, you could argue an airplane “papers over gravity issues”, but I’d rather just book a flight than try and fix the underlying “gravity issue”.
No, my contention is that this argument is a waste of everyone’s time and a sign of dysfunction. I believe this is a clear case of bikeshedding.
I think everyone agrees that arguing about style is bikeshedding; you and I disagree about whether formatters obviate the bikeshedding problem. You seem to contend it will just shift the bikeshedding elsewhere rather than allow a group of people (who are explicitly selected for their attention to detail) to focus on more substantive problems. Your theory doesn’t line up with my experience, and I suspect it doesn’t line up with the experiences of the majority of programmers, which would explain your observation (and bewilderment) that most programmers value code formatters.
I never said you can’t perform automatic formatting. I am saying that it’s not important. My argument is that just because you can automate something doesn’t mean it’s providing value.
I didn’t argue that you argued that you can’t perform automatic formatting. :)
You said it won’t fix the social problem because people will find something else to bicker about, but I think most programmers would assert from experience that it does indeed fix (or significantly attenuate) the bickering issue. A 2 minute technical solution allows a coworker (whose pedantry in other contexts is called “attention to detail”) to become an asset rather than a “social problem” with the incumbent HR interventions and so forth.
The argument, which you can choose to accept or not, is that consistent style makes it easier to understand code
Well… Yes. But how much easier? A tiny bit. If you read the article about cognitive load submitted this week here on lobsters, the things mentioned there completely dwarf whatever miniscule benefit or auto formatting. Every single principle listed in that article has a greater impact on readability than formating.
But the problem is not formating. It’s linting. The absurd strictness. A extra blank line will prevent a commit from building. The developer will have to spend minutes because of a character ignored by the compiler. Is this really worth it? If you gather a team of experienced programmers with a track record of successful software, noone of them will care about linting. They simply don’t need it.
The fact that people spend man hours with linting when their codebases are full of blatant offenses puzzles me. I never once been in a situation where where I felt the need for linting.
Well… Yes. But how much easier? A tiny bit. If you read the article about cognitive load submitted this week here on lobsters, the things mentioned there completely dwarf whatever miniscule benefit or auto formatting. Every single principle listed in that article has a greater impact on readability than formating.
To be clear, I’m not arguing that code formatting is some overriding concern, but I think having a clear consistent style does a lot more to improve readability than people realize. Virtually everyone who comes to Go from other languages (at least back before formatting caught on) remarked that they were surprised at how much of an improvement it was to have a standard style across the ecosystem. Similarly, I’ve worked at C++ and Python shops where code bases are a mix of everyone’s personal styles, and it’s definitely a cognitive burden. At one of those shops, we persuaded the organization (most of whom were very reluctant) to adopt a code formatter and after a couple weeks almost everyone admitted that it was a good thing and the people who previously held catastrophic views about automatic code formatting had shifted their opinions to something much more neutral.
It seems to make a surprisingly big difference in practice, if these anecdotes are indicative (and if they’re not indicative, I’d like to hear some alternate explanation for why code formatters have been such an enduring fad and why so many people perceive such a significant benefit).
But the problem is not formating. It’s linting. The absurd strictness. A extra blank line will prevent a commit from building. The developer will have to spend minutes because of a character ignored by the compiler. Is this really worth it? If you gather a team of experienced programmers with a track record of successful software, noone of them will care about linting. They simply don’t need it.
I don’t feel super strongly about linting, but I’m glad for it nearly 20 years into my programming career–linting still finds quite a few errors (you may be similarly surprised to find that experienced programmers also appreciate other static analysis tools, such as type checkers or borrow checkers). It’s annoying to find linting errors late, but the solution to that problem is also technical: integrate the linter into your IDE. Even when the linter (or other static analysis tools) aren’t finding problems in the code I write, I’ve never been on a team in which all members were veteran, high-performing programmers–invariably there are junior engineers for whom static analysis tools are inexpensive guardrails. Moreover, some times you have low quality senior, staff, principal, etc engineers and static analysis tools are also a cheap way to limit the damage they can do. If you have the luxury of working in an organization of exclusively infallible programmers, then by all means eschew your analysis and formatting tools, but for the rest of us they’re pretty handy. :)
as a hiring manager I would rather spend 5 minutes slapping on a code formatter than finding candidates who work as effectively in a code base with standard style as without
If a slight difference in how a function is formatted is a sticking point… how effective are these people actually going to be? Why not just enforce a timebox on arguing trivialities?
There is a cost to adding process. It creates friction in actually getting things done. Just tacking on more process is an any easy fix, but the problem of 1,000 process papercuts making the project a slog to work on is much worse, and much harder to fix.
Process should be lightweight, just enough to solve a problem, and no more. I frequently work in a codebase that follows all these best-practices, and it still sucks. Not only does the code quality suffer, the process to actually get something merged feels like a gauntlet.
My position is that we should all be inherently skeptical of process and demand hard evidence for its adoption. If it truly is providing value, then it should be trivial to provide more than a vague anecdote in its favor.
I find worrying about formatting to be a very tiny, very constant distraction from the task of writing the code I want, and automatic formatting is therefore very important to me. It’s like no longer having a fly in the same room buzzing around.
If you don’t get why than you’re probably less easily distracted?
I think that’s essentially u/chreke’s argument: if you’re leaning on socially-enforced conventions, then you either have to have perfect conventions before you start writing code or you have to constantly deal with updating your code base as your conventions evolve.
Developers get deceived. Writing elegant easy to read software is a craft that takes knowledge, experience and a fair bit of skill. Many developers lack some of all of these and hence have no way to access what is good maintainable code, let alone authoring it.
Code formating is something they understand and they end up conflating formating correctness with quality. This is likely due to the fact the the software industry grew too large and became much more inclusive (skill wise) than it once was.
But code formating isn’t even the first incarnation of this. Back in the day, even upper vs lower case conventions were not a big deal at all. But the culture of “it’s like this” got so strongly established, that many present day developers will look into that as the most urgent thing to fix in a code base.
Of course none of those things is THAT important. The reasons presented by other users here are, of course, valid. They are just less important than other more realistic quality indicators. Such as: amount of deep nested blocks, repetitiveness/dryness, good descriptive naming, reasonable separation of concerns, manageable code size blocks, intuitive management of conditionals, and so on.
It can get really silly. In the case of go… what’s the point of making a syntax that allows for formatting that won’t be allowed? Why isn’t formatting part of the syntax then? Ultimately is beacause the syntax is not very good. Otherwise what’s the point of writting non valid syntax. It just silly. C like syntax works ok, but we know now from other languages that we have much more usefull and ergonomic alternatives.
On top of that, the ubiquity of the internet, and the social aspect of publishing code online, lends itself to cults, trends, fads. From a scientifical and purely technical point of view, none of this should matter. Tehcnical merits should stand on their own. A trend is irrelevant when solving a technical problem. Many will claim that pleasing a larger crowd will ensure a brighter future for a language.That can’t be denied, but we never see the disclaimer saying “even if that means making inferior technical choices”. This is very much the case of go. It’s a cloud pleaser, it caters to all these silly idiosincrasies of the masses. On top of that it does have some inovations and some nice aspects to it.
Thank you for your thoughtful reply. I think you are broadly correct here.
This dovetails nicely with my (controversial) thoughts on linting, which is to say: sometimes we automate things, not because they objectively improve quality, but because they are easy to automate.
While it’s not often a major pain point, it can be the source of some cognitive load, especially when contributing to open source projects - you not only have to figure out how the project works and how to fit your changes in, but then you have to figure out their coding style and match it.
It’s not a hard requirement for me to like a language, but it’s a bonus. I personally like languages with a formatter like gofmt because it makes it so you don’t need to spend any time thinking about or convincing people to use a specific code style.
I feel like the only language with more boilerplate is Java and Java-like langs (Dart, etc.). No wonder the Go people like IDE’s and formatters and (probably) LLM’s that pump out all that boilerplate for them.
I’ve been evaluating this thing called https://pieces.app and after wondering what the fuss is about, I decided it’s useless for me since I almost never need to reuse code snippets in Elixir, all of its code is precise and specific AF and it has the least boilerplate thanks to its pattern matching and functional style as well as its “let it fail” philosophy.
The post here on Lobsters comes at an interesting time. For a few weeks now, I’ve also been thinking about doing a refresher in Go again and using the language in my projects.
Though Go is not my favorite language, I’m glad that it’s the favorite language of a growing number of programmers. I really like when a piece of software that I want to use is written in Go, because installation is usually just copying a statically-linked executable in my
$PATH. Quite the difference from software written in Python where I have to run them in avenvor software written in Node.js which requires downloading hundreds of megabytes of dependencies.I don’t use it for my own projects, but I agree with a lot of the things here, and it makes contributing to Go projects a breeze, regardless of what I think of the language as such.
I remember back in the day, there was something weird about paths and whatnot? It never made sense to me, but these days it seems to Just Work.
Have gopls installed and just do the thing, never any trouble scratching my own itch and landing patches.
Originally one would have to keep all of their Go code under the $GO_PATH/src directory. I only briefly used Go during this time so I my recollection is foggy. But thankfully the Go people and the community settled around Go modules.
I legitimately do not understand why people rank code formatting as such an important feature. It’s fine. It’s a nice convenience, but I can take or leave it.
I’ve worked in projects with strict formatting, and loose everything-goes policies. Code formatting has literally never been a major pain point for me in more than fifteen years of software.
I worked before the days of code formatting and there were a lot of places that would have at least a few programmers who would bicker in code reviews about stupid style stuff. Go didn’t invent code formatting, but it was the first language with a single standard across the entire ecosystem.
What you’re describing is a serious social problem, not a technical one, and “solving” it with a technical solution is inappropriate because people like that will just find another thing to bicker about.
Not necessarily. Most programmers would agree that it’s important for a code base to have a single, consistent style and you either do that automatically or you invite engineers to police style in code review with all of the incumbent pedantry and drama. You contend that a technical solution can’t solve a social problem, but I think that framing is bad–the social problem is requiring people to choose between a consistent style and policing style stuff in code review; this “technical solution” allows us to have both.
Even if you prefer your “technical solution can’t solve social problem” framing, it’s a matter of theory versus evidence. You theorize that a code formatting tool can’t work, but in practice it seems to work very well. By your own admission, programmers generally rank it as an important feature.
Why? Does this actually impact code quality in a way that matters? Or is it just papering over more serious social issues in the team? You’re begging the question.
No, my contention is that this argument is a waste of everyone’s time and a sign of dysfunction. I believe this is a clear case of bikeshedding.
I never said you can’t perform automatic formatting. I am saying that it’s not important. My argument is that just because you can automate something doesn’t mean it’s providing value.
The argument, which you can choose to accept or not, is that consistent style makes it easier to understand code. Maybe you could argue that programmers’ professed inability to work as effectively in a codebase with/out standard style is a “social issue” on their part, but as a hiring manager I would rather spend 5 minutes slapping on a code formatter than finding candidates who work as effectively in a code base with standard style as without. Similarly, you could argue an airplane “papers over gravity issues”, but I’d rather just book a flight than try and fix the underlying “gravity issue”.
I think everyone agrees that arguing about style is bikeshedding; you and I disagree about whether formatters obviate the bikeshedding problem. You seem to contend it will just shift the bikeshedding elsewhere rather than allow a group of people (who are explicitly selected for their attention to detail) to focus on more substantive problems. Your theory doesn’t line up with my experience, and I suspect it doesn’t line up with the experiences of the majority of programmers, which would explain your observation (and bewilderment) that most programmers value code formatters.
I didn’t argue that you argued that you can’t perform automatic formatting. :)
You said it won’t fix the social problem because people will find something else to bicker about, but I think most programmers would assert from experience that it does indeed fix (or significantly attenuate) the bickering issue. A 2 minute technical solution allows a coworker (whose pedantry in other contexts is called “attention to detail”) to become an asset rather than a “social problem” with the incumbent HR interventions and so forth.
Well… Yes. But how much easier? A tiny bit. If you read the article about cognitive load submitted this week here on lobsters, the things mentioned there completely dwarf whatever miniscule benefit or auto formatting. Every single principle listed in that article has a greater impact on readability than formating.
But the problem is not formating. It’s linting. The absurd strictness. A extra blank line will prevent a commit from building. The developer will have to spend minutes because of a character ignored by the compiler. Is this really worth it? If you gather a team of experienced programmers with a track record of successful software, noone of them will care about linting. They simply don’t need it.
The fact that people spend man hours with linting when their codebases are full of blatant offenses puzzles me. I never once been in a situation where where I felt the need for linting.
To be clear, I’m not arguing that code formatting is some overriding concern, but I think having a clear consistent style does a lot more to improve readability than people realize. Virtually everyone who comes to Go from other languages (at least back before formatting caught on) remarked that they were surprised at how much of an improvement it was to have a standard style across the ecosystem. Similarly, I’ve worked at C++ and Python shops where code bases are a mix of everyone’s personal styles, and it’s definitely a cognitive burden. At one of those shops, we persuaded the organization (most of whom were very reluctant) to adopt a code formatter and after a couple weeks almost everyone admitted that it was a good thing and the people who previously held catastrophic views about automatic code formatting had shifted their opinions to something much more neutral.
It seems to make a surprisingly big difference in practice, if these anecdotes are indicative (and if they’re not indicative, I’d like to hear some alternate explanation for why code formatters have been such an enduring fad and why so many people perceive such a significant benefit).
I don’t feel super strongly about linting, but I’m glad for it nearly 20 years into my programming career–linting still finds quite a few errors (you may be similarly surprised to find that experienced programmers also appreciate other static analysis tools, such as type checkers or borrow checkers). It’s annoying to find linting errors late, but the solution to that problem is also technical: integrate the linter into your IDE. Even when the linter (or other static analysis tools) aren’t finding problems in the code I write, I’ve never been on a team in which all members were veteran, high-performing programmers–invariably there are junior engineers for whom static analysis tools are inexpensive guardrails. Moreover, some times you have low quality senior, staff, principal, etc engineers and static analysis tools are also a cheap way to limit the damage they can do. If you have the luxury of working in an organization of exclusively infallible programmers, then by all means eschew your analysis and formatting tools, but for the rest of us they’re pretty handy. :)
If a slight difference in how a function is formatted is a sticking point… how effective are these people actually going to be? Why not just enforce a timebox on arguing trivialities?
There is a cost to adding process. It creates friction in actually getting things done. Just tacking on more process is an any easy fix, but the problem of 1,000 process papercuts making the project a slog to work on is much worse, and much harder to fix.
Process should be lightweight, just enough to solve a problem, and no more. I frequently work in a codebase that follows all these best-practices, and it still sucks. Not only does the code quality suffer, the process to actually get something merged feels like a gauntlet.
My position is that we should all be inherently skeptical of process and demand hard evidence for its adoption. If it truly is providing value, then it should be trivial to provide more than a vague anecdote in its favor.
I find worrying about formatting to be a very tiny, very constant distraction from the task of writing the code I want, and automatic formatting is therefore very important to me. It’s like no longer having a fly in the same room buzzing around.
If you don’t get why than you’re probably less easily distracted?
What I find about this is that if
was this a meta comment? lol
yes!
I think it’s one of those problems which isn’t hard to deal with but it’s really hard to fix after the fact.
I must disagree with you, AST-based formatting is by definition easier to apply after-the-fact than socially-enforced conventions.
I think that’s essentially u/chreke’s argument: if you’re leaning on socially-enforced conventions, then you either have to have perfect conventions before you start writing code or you have to constantly deal with updating your code base as your conventions evolve.
Developers get deceived. Writing elegant easy to read software is a craft that takes knowledge, experience and a fair bit of skill. Many developers lack some of all of these and hence have no way to access what is good maintainable code, let alone authoring it.
Code formating is something they understand and they end up conflating formating correctness with quality. This is likely due to the fact the the software industry grew too large and became much more inclusive (skill wise) than it once was. But code formating isn’t even the first incarnation of this. Back in the day, even upper vs lower case conventions were not a big deal at all. But the culture of “it’s like this” got so strongly established, that many present day developers will look into that as the most urgent thing to fix in a code base.
Of course none of those things is THAT important. The reasons presented by other users here are, of course, valid. They are just less important than other more realistic quality indicators. Such as: amount of deep nested blocks, repetitiveness/dryness, good descriptive naming, reasonable separation of concerns, manageable code size blocks, intuitive management of conditionals, and so on.
It can get really silly. In the case of go… what’s the point of making a syntax that allows for formatting that won’t be allowed? Why isn’t formatting part of the syntax then? Ultimately is beacause the syntax is not very good. Otherwise what’s the point of writting non valid syntax. It just silly. C like syntax works ok, but we know now from other languages that we have much more usefull and ergonomic alternatives.
On top of that, the ubiquity of the internet, and the social aspect of publishing code online, lends itself to cults, trends, fads. From a scientifical and purely technical point of view, none of this should matter. Tehcnical merits should stand on their own. A trend is irrelevant when solving a technical problem. Many will claim that pleasing a larger crowd will ensure a brighter future for a language.That can’t be denied, but we never see the disclaimer saying “even if that means making inferior technical choices”. This is very much the case of go. It’s a cloud pleaser, it caters to all these silly idiosincrasies of the masses. On top of that it does have some inovations and some nice aspects to it.
Thank you for your thoughtful reply. I think you are broadly correct here.
This dovetails nicely with my (controversial) thoughts on linting, which is to say: sometimes we automate things, not because they objectively improve quality, but because they are easy to automate.
While it’s not often a major pain point, it can be the source of some cognitive load, especially when contributing to open source projects - you not only have to figure out how the project works and how to fit your changes in, but then you have to figure out their coding style and match it.
It’s not a hard requirement for me to like a language, but it’s a bonus. I personally like languages with a formatter like
gofmtbecause it makes it so you don’t need to spend any time thinking about or convincing people to use a specific code style.I feel like the only language with more boilerplate is Java and Java-like langs (Dart, etc.). No wonder the Go people like IDE’s and formatters and (probably) LLM’s that pump out all that boilerplate for them.
I’ve been evaluating this thing called https://pieces.app and after wondering what the fuss is about, I decided it’s useless for me since I almost never need to reuse code snippets in Elixir, all of its code is precise and specific AF and it has the least boilerplate thanks to its pattern matching and functional style as well as its “let it fail” philosophy.
The post here on Lobsters comes at an interesting time. For a few weeks now, I’ve also been thinking about doing a refresher in Go again and using the language in my projects.
One of the three caveats at the end was packaging, which has been fixed since 2017. :-)