I've switched from Dotnet to Go and I have some tensions with the language. has anyone resolved these?
I've been writing in C# and ASP.Net for most of my career, and 4 months ago I switched to Go.
So far I really like the concurrency model, how robust the standard lib is with anything to do with networking, and the general "vibe" of the language.
But there are some tensions I feel when I'm writing it that I can't get past, and I'm not sure whether there's a click that needs to happen or that's just the tradeoffs that Go makes.
In Go every package is a dir, every subpackage is a subdir, and marking a subpackage as internal to the package it's in require an "internal" dir. I find myself avoiding splitting logic and concerns into subpackages even when I think I should because I don't want to clutter the repo. Is this just something you have to power through?
I usually favor baking business rules into types, I found it helps catch bugs at development time, It is possible in Go, but it feels like it requires more ceremony, simply declaring a type over a primitive doesn't let you constrain its creation in any way, even with structs it's hard to make constructor functions a must, and with enums and union types not part of the language it takes a lot of code to constrain a field to a closed set of values or blocking invalid combinations of fields from being set together. Are there patterns I should use that make those easier?
I find myself putting a lot of thought into DI, configuration layering, input binding and validation, all stuff I used to get from the framework without putting much effort into it, those are very much "opt in" in Go, how do you make sure the all contributers opt in consistently?
I get that all of those points are by design, the Go philosophy favors small microservices with flat codebases and little abstraction to keep everything explicit, But it seems like keeping a codebase maintainable in Go requires consistent discipline and some craftsmanship across the team, And as an individual contributor, even a senior one, I don't always call the shots, So how do you navigate this in a long running project with people coming and going?