5 ms·

You're just looking at one set of trade-offs and mistaking it for the best. Since people do not unanimously use large batteries-included frameworks, you must r

• JetJaguar 10y ago
  And Go does? What does "win" mean in this case? Productivity....market share??? 'cause, um no.
• brightball 10y ago
  Never said it was the best, just that there are a lot of pain points that come from trying to use Go for a full stack development experience. Command line, workers, network and api layers are GREAT. If you have something that needs a custom solution...great. But the experience around managing a polished view layer, assets, routing, middleware, sessions, routing, redirects, migrations, database access, etc can get fragmented and tedious when roll-your-own becomes the defacto mode of operation. When a language doesn't have all of the web-native stuff built in by default (like PHP, JS and Go) the community around the language tends to organize around a framework experience that will eventually lead to a common development experience that people can further develop tooling around. It's not a knock on Go itself, it's just something that creates a noticeable side effect in the community in terms of fragmentation. People clearly WANT frameworks, because they keep rebuilding them. Doesn't mean you always need one, but it does mean that having a "winner" could be good for the community.