4 ms·
Honest question,but am I the only one who find really hard to read and follow quite big golang projects? Maybe is true that I can understand what is happening
by siscia 8y ago
Honest question,but am I the only one who find really hard to read and follow quite big golang projects?
Maybe is true that I can understand what is happening in every single line of code in my screen, what I found really hard is to understand how those line interact with the rest of the code base.
I honestly believe that there are some part of the code base that should manage the low level stuff like managing files, writing to buffers or interact with the file system and other part that should compose/manage/move those low level parts.
Using go and its focus on "simplicity" it feels like these basic abstraction fall apart and that in every part of the code base I can find something doing quite low level stuff.
I find go quite good for small, self contained projects but honestly I believe that big projects like docker could benefit more from a more structured approach.
Am I the only one feeling this pain?
- dnomad 8y agoYou're definitely not the only one. It's a very strange phenomenon: Golang developers insist their language is boring and uber-simple but every non-trivial Go codebase I've encountered has been anything but. It seems like the end result always involves a bad reinvention of exceptions using panic/recover, code that isn't type safe that has too many curly brackets... and lots and lots of code generation. Combined with immature tooling the result is horrifying. I'm by no means a Go expert and perhaps I'm just unlucky but that's been my experience. I certainly no longer volunteer dive into strange Go codebases like I might do with Java. At this point I have to wonder if in 10 years the Golangers will actually find themselves in a good place. I don't see these codebases aging well at all.