4 ms·

I was a Java dev for many years and I vastly prefer Go. A lot of it for me has to do with the inversion of control libraries providing "fake" simplicity, but be

I was a Java dev for many years and I vastly prefer Go. A lot of it for me has to do with the inversion of control libraries providing "fake" simplicity, but becoming a nightmare when you have to try and figure out what thing in the background is know causing a bean conflict. The extremely straight control flow of Go makes it much easier to maintain in the long term IMO.

closeparen 3y ago
Part of maintainability is readability and ease of debugging, and I agree that Go shines here. But another part is the ease of refactoring and rewriting. My experience is that Go codebases which aren't fundamentally doing very much nevertheless become ossified through sheer volume. This is especially the case when you have layered packages (MVC, etc) and consequently a lot of mocks. Most conceivable changes implicate dozens to hundreds of mock expectation lines, and thus become more trouble than they're worth. This is largely because fully explicit control flow needs to be fully explicitly unit tested every single time. Those tests weigh a lot.
- matrix87 3y ago
  > Most conceivable changes implicate dozens to hundreds of mock expectation lines, and thus become more trouble than they're worth. I've experienced the same thing in java, and similarly with testing different conditionals/exception cases in java Usually most of the mock annoyingness I've personally dealt with is from repetitive, unrefactored test coverage
bigEnotation 3y ago
Does go have something similar to spring, or is there a framework baked into the language
- liampulles 3y ago
  You can write service structs which depend on service structs similar to spring, and there are libraries which can generate the code that does the wiring for you. I've always wired my stuff manually in Go though, which is useful if I want to optionally load different subsystems because of some config, etc.

closeparen 3y ago

Part of maintainability is readability and ease of debugging, and I agree that Go shines here. But another part is the ease of refactoring and rewriting. My experience is that Go codebases which aren't fundamentally doing very much nevertheless become ossified through sheer volume. This is especially the case when you have layered packages (MVC, etc) and consequently a lot of mocks. Most conceivable changes implicate dozens to hundreds of mock expectation lines, and thus become more trouble than they're worth. This is largely because fully explicit control flow needs to be fully explicitly unit tested every single time. Those tests weigh a lot.

matrix87 3y ago
> Most conceivable changes implicate dozens to hundreds of mock expectation lines, and thus become more trouble than they're worth. I've experienced the same thing in java, and similarly with testing different conditionals/exception cases in java Usually most of the mock annoyingness I've personally dealt with is from repetitive, unrefactored test coverage

bigEnotation 3y ago

Does go have something similar to spring, or is there a framework baked into the language

liampulles 3y ago
You can write service structs which depend on service structs similar to spring, and there are libraries which can generate the code that does the wiring for you. I've always wired my stuff manually in Go though, which is useful if I want to optionally load different subsystems because of some config, etc.