Go is a powerful language known for its simplicity, speed, and concurrency model. But the Go community also traditionally takes a strong stance a...
For further actions, you may consider blocking this person and/or reporting abuse
I've wrestled with Go's blank slate vibe before and it really does slow me down sometimes - these kinds of frameworks make it way less annoying. Respect for anyone still doing it all by hand though, that's a grind.
Am I the only one to whom this post seems like Encore.go promo? There is huge amount of web frameworks available in go: awesome-go.com/web-frameworks/
It's an opinion piece written by me, and I work on Encore, not trying to hide that fact at all. It's written from the perspective of someone working on a framework in the Go community and even though there are several others, there's a strong culture against using framework.
I love Go’s simplicity, but for larger teams, the lack of structure can slow things down. Encore’s built-in tools and conventions help solve that by providing structure without sacrificing Go’s flexibility.
This is so timely man, thanks. As a junior developer who's primary language is Go. I came to ship a product so fast in django without knowing python deeply. I've been terrified to jumpstart my personal project and was considering django again, but thanks for this, I'll dive straight into encore
All of the issues you discuss aren't really issues when you have a good Tech Lead or Architect who takes care of establishing team standards and ensuring they're followed by good code review.
In fact, I've found that frameworks are really helpful when you start out a new project for all the reason you discussed, but oftentimes become a hindrance when a project is well-established. Particularly, very opinionated frameworks can get in the way of innovation when you need to do something that's not already covered by the framework. After a while of working in a project, you end up subverting the framework's standard designs so that you can make it fit new and changing requirements.
I tried out encore a bit, and my impression of it was that it was too opinionated, and got too much in the way of just making a go app. It not only establishes its own conventions, it actively prevents you from following established go conventions. You don't write go apps. You write encore apps that happen to be in go (or TypeScript).
"We don't need community driven frameworks if there's a dedicated six-figure salary on the team creating an ad hoc framework."
#ad
That's what I was thinking about
The less code you write, the less tests you have to write. Django exactly does this. You still have to take care of DB constraints by yourself and test them out anyways, but with class based views(with smaller apps) you are moving much faster.
"In Go, many common tasks like background jobs, database migrations, and routing are handled through third-party libraries rather than built-in tooling"-> I don't think that's true in the least, go has the best standard library out of all the languages, so don't know what you're talking about really
I'm always surprised at how many "developers" know a framework but don't know the language. For example, many React developers don't know JavaScript...
There are quite a few Go frameworks for web development, such as Fiber, Echo, Revel, Gin, and others. They make life much nicer! 😄