IMO it’ll be slower to write crud apis and there are some missing batteries you have to look for, it’s fairly verbose but I think some of that will change with generics and hopefully more pattern matching.
On the flip side when you deploy it, it will like just work and run smoothly. Also very easy to add full integration tests as you can create a mock http server at runtime, paired with some db tools (go migrate) it’s very easy spin up a whole env and test it. It’s also very easy to get at lower level things like headers and cookies without it getting in the way. Also much of the web middleware is interchangeable or a few lines away from an adapter as there is a common interface in the std lib.
OK thanks for this, the easily mock thing is indeed very nice to have. And maybe Generics will improve things.
I don't get why there isn't a function to remove element from a slice (there's some append[:i],[i+1] trick instead) why wouldn't this be wrapped in a stdlib function? call it delete or something. I keep hearing good things about the stdlib - what am I missing?
It's that do it yourself mentality I really don't like, and taking huge compromises on readability to preserve low language keyword count (like the lack of private keyword / capitalization the article discussed and the consequences) and then calling this whole setup "simple".
There's nothing major but many many small things I think that make it a subpar experience. I don't care that much about performance and concurrency though which I think are Go's strong suits.
Rails. A bit of Django and Node. All 3 were better in my eyes but as I said in another comment I care very little about performance and concurrency so maybe I'm not Go's target audience.
