3 ms·

> Enums, immutables, and generics aren't good because they're exciting. They're good because they give us expressive tools to write descriptive, type safe syste

by jahaja 6y ago

> Enums, immutables, and generics aren't good because they're exciting. They're good because they give us expressive tools to write descriptive, type safe systems that manage state better. The main problem is just that these expressive tools scales poorly with regards to the number of people involved in the code base and its age. The amount of time to write and/or duplicate code is just a fraction of the amount of time it takes to read/understand/debug code that have degenerated over time due to the number of people involved and various amounts of "expressiveness". And no, a style guide isn't enough because these idioms change over time and there are a lot of social factors involved. Where for example the senior devs are actually the ones that a few years back decided that these overly-expressive code is the best thing since sliced bread.

tsimionescu 6y ago
I completely disagree. Code duplication is one of the worse things for readability, and generics quickly make up for their weight in gold on this front. Go code is very hard to read and review especially because it has so much repetition where little details can hide. "Is that a regular error check that logs and returns, or did I miss some actual logic there?", "Is that loop just trying to find a value in an array, or is it also doing something else?" etc - boilerplate upon boilerplate, which you learn to glaze over, until it's not really boilerplate and you miss something.
- jahaja 6y ago
  I think Go is pretty well known for being easy to read so I'm not sure what exactly you find hard to read. Duplicated code is not inherently unreadable. Code shouldn't be abstracted away and be made "reusable" before it's been duplicated once anyways. I also believe that the amount of additional code duplication created by the lack of expressive language features is overestimated. The examples you give doesn't seem to be specific to Go? In Go the error checks are, as most point quickly out, very explicit and often just err != nil checks. Not sure how they can be confusing, albeit repetitive. I'm a bit surprised by the amount of down votes my reply has received given that this is a pretty common sentiment among very experienced devs within the game dev industry.
  - deleuze 6y ago
    Readability has multiple dimensions, of which "difficulty" is only one. The parent post is not talking about golang being confusing, but rather being verbose and low density, which makes it easier for bugs to hide when reviewing.
    - jahaja 6y ago
      Yeah, it does indeed. But compared to what? Reviewing high density code can surely hide bugs as well when reviewing? Either way, it's also easier to debug low density code so there are more things to consider.
      - tsimionescu 6y ago
        The biggest problem when reading Go code is that, like C, it tends to contain a lot of details that have to do with the language implementation, instead of the problem domain. Errors are bubbled up manually. Loops often use array indices, instead of expressing the desired operations. You often need to use pointers instead of values just to avoid the cost of constantly copying structs. And every time you encounter one of these things, you get to spend some time thinking about why this or that was chosen,or if you're missing some detail. Java is much more readable, because it has far fewer of these concerns. Every time you see a catch block, you know it is there for a reason. If someone is making a copy of an object, you know they wanted to make sure the original isn't changed. With Streams, if I want to write an operation which filters a list, I can use filter(), not 'create a new array, go through the original, every time you find an element matching the condition, write it at some index in the new array, increment that index'.
        jahaja 6y ago
        I think we'll have to agree to disagree on this one. That standard for loops are less readable just doesn't make any sense to me. Neither do the preference of exceptions which is pretty much the first things most experienced people turn off and ban in C++.

by jahaja 6y ago

tsimionescu 6y ago

I completely disagree. Code duplication is one of the worse things for readability, and generics quickly make up for their weight in gold on this front. Go code is very hard to read and review especially because it has so much repetition where little details can hide. "Is that a regular error check that logs and returns, or did I miss some actual logic there?", "Is that loop just trying to find a value in an array, or is it also doing something else?" etc - boilerplate upon boilerplate, which you learn to glaze over, until it's not really boilerplate and you miss something.

jahaja 6y ago
I think Go is pretty well known for being easy to read so I'm not sure what exactly you find hard to read. Duplicated code is not inherently unreadable. Code shouldn't be abstracted away and be made "reusable" before it's been duplicated once anyways. I also believe that the amount of additional code duplication created by the lack of expressive language features is overestimated. The examples you give doesn't seem to be specific to Go? In Go the error checks are, as most point quickly out, very explicit and often just err != nil checks. Not sure how they can be confusing, albeit repetitive. I'm a bit surprised by the amount of down votes my reply has received given that this is a pretty common sentiment among very experienced devs within the game dev industry.
- deleuze 6y ago
  Readability has multiple dimensions, of which "difficulty" is only one. The parent post is not talking about golang being confusing, but rather being verbose and low density, which makes it easier for bugs to hide when reviewing.
  - jahaja 6y ago
    Yeah, it does indeed. But compared to what? Reviewing high density code can surely hide bugs as well when reviewing? Either way, it's also easier to debug low density code so there are more things to consider.
    - tsimionescu 6y ago
      The biggest problem when reading Go code is that, like C, it tends to contain a lot of details that have to do with the language implementation, instead of the problem domain. Errors are bubbled up manually. Loops often use array indices, instead of expressing the desired operations. You often need to use pointers instead of values just to avoid the cost of constantly copying structs. And every time you encounter one of these things, you get to spend some time thinking about why this or that was chosen,or if you're missing some detail. Java is much more readable, because it has far fewer of these concerns. Every time you see a catch block, you know it is there for a reason. If someone is making a copy of an object, you know they wanted to make sure the original isn't changed. With Streams, if I want to write an operation which filters a list, I can use filter(), not 'create a new array, go through the original, every time you find an element matching the condition, write it at some index in the new array, increment that index'.
      - jahaja 6y ago
        I think we'll have to agree to disagree on this one. That standard for loops are less readable just doesn't make any sense to me. Neither do the preference of exceptions which is pretty much the first things most experienced people turn off and ban in C++.