6 ms·

The Kubernetes codebase is huge, but in my (limited) experience I really felt like it was delivering on Go’s promise: that I can read any given file and underst

by jitl 5y ago

The Kubernetes codebase is huge, but in my (limited) experience I really felt like it was delivering on Go’s promise: that I can read any given file and understand what’s happening. At least when I needed to debug Kubernetes issues 4 years ago, I could grep around, dive into a file, and command-click to “go to definition” and quickly build a local understanding of the code around my problem. No spooky action. Everything explicit, verbose but plain spoken. Yes there is a lot of code, but I would be very surprised to be able to dive into a C++, Java, Python, or TypeScript project of the same scope and be anywhere as near productive. > partly due to me getting bored having to deal with all of the different numeric data types […]. This tedium killed my love of the language (I'm sure it's a better experience in 2022) That’s the very tradeoff Go is designed to make. It is not expressive. It is tedious. But it’s objective is not to make you as an individual fast. It is to make large programming projects cheaper over the long run, and to reduce the variance between the best programmer on a project and the worst.

reedjosh 5y ago
> It is tedious. > to reduce the variance between the best programmer on a project and the worst. In my experience the only way this can be done as with trying to level anything is to bring down the level of the best. I find this awful.
- AnimalMuppet 5y ago
  It may be awful to the best programmer. But if you're looking at the team as a whole, well, how many of the best do you have on the team? It's really hard to create large teams where the average programmer on the team is better than the average programmer in the country. If you can bring up the lower half of the team, that may be a net win, even if it brings down the best one on the team. The effect of that may be that the best programmers leave the team, though...
  - gmfawcett 5y ago
    If the skill difference among your devs is really high, it may be preferable to have the best programmer leave, or at least change roles (architect, team lead, trainer), as this may increase productivity of the median workers. At least the skill difference should be treated as a risk and properly mitigated.
    - tonyarkles 5y ago
      In the role in my sibling comment, I somewhat filled the role of the developer that went away. Hardcore Java/Spring Boot guy who could wrap his head around these amazingly complex code bases he made that the younger/less experienced devs could not manage on their own. I spent a ton of time mentoring in my role, and hopefully helped undo some of the mental damage the previous guy did :D. Things were running much smoother when I left then they did when I first joined at least, with teams that could have chosen whatever language they wanted choosing Go voluntarily.
  - tonyarkles 5y ago
    I used Go (didn’t choose it exactly) at an olds job of mine 4 or 5 years ago. I was definitely the most senior and very likely the best developer at the company. Organizationally, many of their backend services were Java-based using Spring Boot, although there were a few Python and NodeJS ones as well. My general observation was: The people who called themselves Java programmers or Python programmers or JavaScript programmers complained a ton about Go. The people who weren’t committed to any particular language didn’t seem to mind at all. (I am in the whatever-language-let’s-write-code camp myself) We weren’t in love with it. I don’t use it for spare time projects (woo Common Lisp with SBCL). The only super positive feedback I really remember is “wow! It’s so easy to just walk through from when the program starts to knowing where all the endpoints are and where you can find the source!” which isn’t so much praise of Go but an indictment of Spring Boot.
  - dhzhzjsbevs 5y ago
    Meh, the best developers sound like whiny brats. I'm not the best developer but I've been around long enough to know that bringing the bottom half of development up to the plate does more for me in my day job than catering to what magic bullshit the "best" developers are pumping.
- BobbyJo 5y ago
  I've found Go's compromises help good programmers too over the long run. It isn't lowering the variance by slowing down the quick, it does it by shrinking the space of possible solutions. Bad programmers and good programmers wind up making similar "good enough" design choices. You don't wind up with over engineered frameworks for every bit of logic in you backend.
- mathattack 5y ago
  For small companies, variance can be good. For large companies, avoiding surprises is everything. So they cram a bunch of processes to make everyone a B player. That’s great if you’re naturally a C player, and can be less work if you’re a B+ player who wants to coast. But it’s hell hell if you’re an A player who is now working with handcuffs, and getting paid the same as the C player.
  - reedjosh 5y ago
    ^^ This!
    - cudgy 5y ago
      I guess the correct language depends on the ratio of good/bad developers in this case.
  - Cthulhu_ 5y ago
    Can you consider yourself an A player if you think yourself too good to work with B / C players in a language that, as you say, handcuffs you? I mean it frees you up mentally to think about the bigger problems, beyond the bit of code you're working on right now. In the end, the person writing the code is just a cog in the machine. You can try and pretend you're an Important cog by being Very Clever and using very smart code, but in the end you're not actually important. If you want to be important, you need to let that code go and move up, towards architecture and company level.
    - mathattack 5y ago
      It’s not the people who handcuff, it’s the process. I will use Sales since the metrics less ambiguous there. In a startup, without a lot of structure, a great salesperson will find deals that others can’t, and will close many more of them. They will have the autonomy to get things done and are rewarded when they crush their quotas. In large companies, there are all kinds of Marketing and Sales support programs that lift the average salesman. But a great salesman is told “Only talk to companies on your list” and “All your deals must get approved by the deal desk” and “Don’t sell more than X because it will ruffle feathers downstream” These processes are good in aggregate but drive top performers nuts.
- Cthulhu_ 5y ago
  > In my experience the only way this can be done as with trying to level anything is to bring down the level of the best. > I find this awful. It mitigates risk; if "the best" is at a level above the other developers, to the point where a lot of things hinge on this individual, it's a huge company risk. You never want to rely on "the best"; see also https://en.wikipedia.org/wiki/Bus_factor https://en.wikipedia.org/wiki/Bus_factor Go is a language that tells people to put their ego aside. The problem you're solving is already complicated enough, no need to add complexity with a complex language. Dumb and verbose code is better than concise but complex and hard to comprehend code.
  - thesz 5y ago
    Errors are introduced at constant ratio per line of code that is not syntactically checked by compiler. The ratio is specific to developer and language used. E.g., you can't make a mistake on a line that contains only curly bracket, but you can make (one-off) mistake on line "i += 10;" The more verbose code, the more lines of code that are not syntactically checked. The more errors you introduce during development. Why I talk about syntax and not types? Because type system of go and some other languages like C (and C#, C++ and some other including OCaml, for that matter) are not rich enough to express long dependencies as is done in Rust with its borrow checker. Rust has its own failing, of course. In some cases of type systems [1] it is possible to express environments with long dependencies without resorting to hacking of a compiler. But most languages do not have that luxury, the only dependence checking are balancing brackets and missing variable declarations. [1] http://blog.sigfpe.com/2009/02/beyond-monads.html http://blog.sigfpe.com/2009/02/beyond-monads.html The axiom of (not only) software engineering says that cost to fix a defect is directly propotional to the time between introduction and discovery of said defect. The funnel of defect filtering (personal review, colleague code review, CI, QA, beta, etc) is not perfect, it still allows for some defects to fall through. The more defects are on wide part of the funnel, the more defects are on the narrow part of it. And for these defects that pass through, the time between introduction and discovery is bigger than for all other defects. The more verbose code in some language, the more defects developer will generate using that language. The more defects will pass through defect detection funnel. The biger will be the cost to fix them and cost of software user to, well, use the software. Google can afford that, because they can afford extremely long funnel with prolonged code reviews, big QA teams and long lasting betas. They can afford that because of money they got. Practically everyone else cannot afford that. Ego is not even a problem when you factor all other problems you get with simple or good enough verbose solutions.
snotrockets 5y ago
What I wonder, is if by designing a language to enable happy corporates, rather than happy programers, is Go not shooting itself in the foot, as the now less happy programmers (because corp mandated Go) would move to other corps, creating more cost to the corporate than if they had use a more joy-inducing language. IOW, Go is probably great if you're quite big. But like most Google created dev tools, the questions we need to ask ourselves is "are they a good fit outside Google?"
- geodel 5y ago
  I have asked to myself and answer seems yes. I wrote a tool many years ago in Go. It has saved me at least 100 times the hours I put in to code it. And I put in couple of weeks at max. The point here is I created a tool (my application) using another tool (Go) and I care quite a bit more about my tool, features, usability and so on. Programing language provided few features like single binary so I can install on VMs, desktop and not downloading whole internet to build that project. Its been working fine for half a decade or so. So it does its job and saved time is spent somewhere else like reading interesting books, cooking or watching documentaries etc. I can understand people who sweat on perfect error handling, sum type and what not will be eternally unhappy with Go. Hopefully they find whatever suits their taste, considering we are in a new PL boom nowadays.
  - snotrockets 5y ago
    I don't care about past tense. If you had to write every day in Go, would you still be happy about it? (I sure wouldn't)
    - Cthulhu_ 5y ago
      I write Go every day, and have done so for the past two years or so (along Typescript, JS and PHP, the latter two for a 'legacy' application), and I'm happy with the language. If I were to criticise it, there's a few things that come to mind: - Struct tags don't feel right; it's string-based annotations and some libraries design whole DSLs in them. - The community seems to push towards using hexagonal or clean design, but unless I'm getting it wrong, this leads to a lot of really tedious conversion / adapter code. - There's not many good tools out there (yet?) to make things easier, e.g. database abstraction layers. Writing lower level SQL and some utilities to help with that is still better, but it's tedious and voluminous (like using raw JDBC and iterating over ResultSets). I've used ent (which required manual mapping between every struct field and every column, unless I got it wrong) and gorm (which breaks down when you nest deeper than one level), currently have about 40 tables. But these are issues that show up, I think, in any larger application.
mmcdermott 5y ago
I hadn't thought of it that way. Trading verbosity for clarity was always COBOL's shtick. I had always thought of Java as this gen's COBOL, but maybe the reflection oriented frameworks in common use undercut that use case and Golang would do it better.

by jitl 5y ago

reedjosh 5y ago

> It is tedious. > to reduce the variance between the best programmer on a project and the worst. In my experience the only way this can be done as with trying to level anything is to bring down the level of the best. I find this awful.

AnimalMuppet 5y ago
It may be awful to the best programmer. But if you're looking at the team as a whole, well, how many of the best do you have on the team? It's really hard to create large teams where the average programmer on the team is better than the average programmer in the country. If you can bring up the lower half of the team, that may be a net win, even if it brings down the best one on the team. The effect of that may be that the best programmers leave the team, though...
- gmfawcett 5y ago
  If the skill difference among your devs is really high, it may be preferable to have the best programmer leave, or at least change roles (architect, team lead, trainer), as this may increase productivity of the median workers. At least the skill difference should be treated as a risk and properly mitigated.
  - tonyarkles 5y ago
    In the role in my sibling comment, I somewhat filled the role of the developer that went away. Hardcore Java/Spring Boot guy who could wrap his head around these amazingly complex code bases he made that the younger/less experienced devs could not manage on their own. I spent a ton of time mentoring in my role, and hopefully helped undo some of the mental damage the previous guy did :D. Things were running much smoother when I left then they did when I first joined at least, with teams that could have chosen whatever language they wanted choosing Go voluntarily.
- tonyarkles 5y ago
  I used Go (didn’t choose it exactly) at an olds job of mine 4 or 5 years ago. I was definitely the most senior and very likely the best developer at the company. Organizationally, many of their backend services were Java-based using Spring Boot, although there were a few Python and NodeJS ones as well. My general observation was: The people who called themselves Java programmers or Python programmers or JavaScript programmers complained a ton about Go. The people who weren’t committed to any particular language didn’t seem to mind at all. (I am in the whatever-language-let’s-write-code camp myself) We weren’t in love with it. I don’t use it for spare time projects (woo Common Lisp with SBCL). The only super positive feedback I really remember is “wow! It’s so easy to just walk through from when the program starts to knowing where all the endpoints are and where you can find the source!” which isn’t so much praise of Go but an indictment of Spring Boot.
- dhzhzjsbevs 5y ago
  Meh, the best developers sound like whiny brats. I'm not the best developer but I've been around long enough to know that bringing the bottom half of development up to the plate does more for me in my day job than catering to what magic bullshit the "best" developers are pumping.
BobbyJo 5y ago
I've found Go's compromises help good programmers too over the long run. It isn't lowering the variance by slowing down the quick, it does it by shrinking the space of possible solutions. Bad programmers and good programmers wind up making similar "good enough" design choices. You don't wind up with over engineered frameworks for every bit of logic in you backend.
mathattack 5y ago
For small companies, variance can be good. For large companies, avoiding surprises is everything. So they cram a bunch of processes to make everyone a B player. That’s great if you’re naturally a C player, and can be less work if you’re a B+ player who wants to coast. But it’s hell hell if you’re an A player who is now working with handcuffs, and getting paid the same as the C player.
- reedjosh 5y ago
  ^^ This!
  - cudgy 5y ago
    I guess the correct language depends on the ratio of good/bad developers in this case.
- Cthulhu_ 5y ago
  Can you consider yourself an A player if you think yourself too good to work with B / C players in a language that, as you say, handcuffs you? I mean it frees you up mentally to think about the bigger problems, beyond the bit of code you're working on right now. In the end, the person writing the code is just a cog in the machine. You can try and pretend you're an Important cog by being Very Clever and using very smart code, but in the end you're not actually important. If you want to be important, you need to let that code go and move up, towards architecture and company level.
  - mathattack 5y ago
    It’s not the people who handcuff, it’s the process. I will use Sales since the metrics less ambiguous there. In a startup, without a lot of structure, a great salesperson will find deals that others can’t, and will close many more of them. They will have the autonomy to get things done and are rewarded when they crush their quotas. In large companies, there are all kinds of Marketing and Sales support programs that lift the average salesman. But a great salesman is told “Only talk to companies on your list” and “All your deals must get approved by the deal desk” and “Don’t sell more than X because it will ruffle feathers downstream” These processes are good in aggregate but drive top performers nuts.
Cthulhu_ 5y ago
> In my experience the only way this can be done as with trying to level anything is to bring down the level of the best. > I find this awful. It mitigates risk; if "the best" is at a level above the other developers, to the point where a lot of things hinge on this individual, it's a huge company risk. You never want to rely on "the best"; see also https://en.wikipedia.org/wiki/Bus_factor https://en.wikipedia.org/wiki/Bus_factor Go is a language that tells people to put their ego aside. The problem you're solving is already complicated enough, no need to add complexity with a complex language. Dumb and verbose code is better than concise but complex and hard to comprehend code.
- thesz 5y ago
  Errors are introduced at constant ratio per line of code that is not syntactically checked by compiler. The ratio is specific to developer and language used. E.g., you can't make a mistake on a line that contains only curly bracket, but you can make (one-off) mistake on line "i += 10;" The more verbose code, the more lines of code that are not syntactically checked. The more errors you introduce during development. Why I talk about syntax and not types? Because type system of go and some other languages like C (and C#, C++ and some other including OCaml, for that matter) are not rich enough to express long dependencies as is done in Rust with its borrow checker. Rust has its own failing, of course. In some cases of type systems [1] it is possible to express environments with long dependencies without resorting to hacking of a compiler. But most languages do not have that luxury, the only dependence checking are balancing brackets and missing variable declarations. [1] http://blog.sigfpe.com/2009/02/beyond-monads.html http://blog.sigfpe.com/2009/02/beyond-monads.html The axiom of (not only) software engineering says that cost to fix a defect is directly propotional to the time between introduction and discovery of said defect. The funnel of defect filtering (personal review, colleague code review, CI, QA, beta, etc) is not perfect, it still allows for some defects to fall through. The more defects are on wide part of the funnel, the more defects are on the narrow part of it. And for these defects that pass through, the time between introduction and discovery is bigger than for all other defects. The more verbose code in some language, the more defects developer will generate using that language. The more defects will pass through defect detection funnel. The biger will be the cost to fix them and cost of software user to, well, use the software. Google can afford that, because they can afford extremely long funnel with prolonged code reviews, big QA teams and long lasting betas. They can afford that because of money they got. Practically everyone else cannot afford that. Ego is not even a problem when you factor all other problems you get with simple or good enough verbose solutions.

snotrockets 5y ago

What I wonder, is if by designing a language to enable happy corporates, rather than happy programers, is Go not shooting itself in the foot, as the now less happy programmers (because corp mandated Go) would move to other corps, creating more cost to the corporate than if they had use a more joy-inducing language. IOW, Go is probably great if you're quite big. But like most Google created dev tools, the questions we need to ask ourselves is "are they a good fit outside Google?"

geodel 5y ago
I have asked to myself and answer seems yes. I wrote a tool many years ago in Go. It has saved me at least 100 times the hours I put in to code it. And I put in couple of weeks at max. The point here is I created a tool (my application) using another tool (Go) and I care quite a bit more about my tool, features, usability and so on. Programing language provided few features like single binary so I can install on VMs, desktop and not downloading whole internet to build that project. Its been working fine for half a decade or so. So it does its job and saved time is spent somewhere else like reading interesting books, cooking or watching documentaries etc. I can understand people who sweat on perfect error handling, sum type and what not will be eternally unhappy with Go. Hopefully they find whatever suits their taste, considering we are in a new PL boom nowadays.
- snotrockets 5y ago
  I don't care about past tense. If you had to write every day in Go, would you still be happy about it? (I sure wouldn't)
  - Cthulhu_ 5y ago
    I write Go every day, and have done so for the past two years or so (along Typescript, JS and PHP, the latter two for a 'legacy' application), and I'm happy with the language. If I were to criticise it, there's a few things that come to mind: - Struct tags don't feel right; it's string-based annotations and some libraries design whole DSLs in them. - The community seems to push towards using hexagonal or clean design, but unless I'm getting it wrong, this leads to a lot of really tedious conversion / adapter code. - There's not many good tools out there (yet?) to make things easier, e.g. database abstraction layers. Writing lower level SQL and some utilities to help with that is still better, but it's tedious and voluminous (like using raw JDBC and iterating over ResultSets). I've used ent (which required manual mapping between every struct field and every column, unless I got it wrong) and gorm (which breaks down when you nest deeper than one level), currently have about 40 tables. But these are issues that show up, I think, in any larger application.

mmcdermott 5y ago

I hadn't thought of it that way. Trading verbosity for clarity was always COBOL's shtick. I had always thought of Java as this gen's COBOL, but maybe the reflection oriented frameworks in common use undercut that use case and Golang would do it better.