4 ms·
Honestly, frameworks like Rails or Django are an anti-pattern for Golang. The standard library makes it very easy to build web services and there’s a couple or
by rufius 6y ago
Honestly, frameworks like Rails or Django are an anti-pattern for Golang.
The standard library makes it very easy to build web services and there’s a couple or popular packages for making routes and dealing with HTTP requests/responses simple.
There’s projects like Micro that try to do a little more batteries included but I wouldn’t consider them to be pervasive in the way Django or Rails are.
Beyond that, it’s just app logic and the typical Golang boiler plate.
Source: I’ve built a few big Golang services for a couple companies.
- sk5t 6y agoContrary perspective: only avoid frameworks when you can be assured your project is (and will remain) so narrow that it has no need of validation libraries and the like.
- treis 6y ago>Honestly, frameworks like Rails or Django are an anti-pattern for Golang. Which is, IMHO, the biggest thing holding Go back. The standard library does a lot but a lot is also missing. Authentication, db migration, admin panels, ORM, Asset pipeline and probably more. It's a lot of custom work to do or pulling in various libraries.
- CameronNemo 6y agoI don't think Go will see something even close to Django until generics are merged.
- rufius 6y agoI have mixed feelings on this. I go back and forth on whether I agree or disagree. For example, once an application becomes sufficiently complex, I've found ORM's to be more of a hindrance. The abstraction gets leaky and I end up having to tune custom queries to get around some pathological edge case. That said - most of my experience is with Rails and a lot of the implicit nature of it is problematic. On the other hand, I've not had this experience with Laravel. Which one is right? I dunno. Lately though, writing sizable web applications in Golang is working out well so I guess I'll keep doing that.
- leetrout 6y agoRails implicit magic is so painful. I’ll disagree and agree on the ORM front. A good ORM has a clean escape handle for tuning hot spots and otherwise saves you time with boilerplate queries. Add a new field? Update the class / structs, generate a migration and move on. Without the ORM you write the migration yourself, you have to find and update all the queries and if you’re centralizing all your query building then you’re just using your own ORM-light without the battle hardened trials of other users using something open source and popular. I insisted we use sql alchemy and alembic in our latest Go project — and I’m eyeballing Buffalo’s Soda and Fizz as a replacement. Its generally just nerdcore navel gazing to insist on raw sql across a project in my opinion. Especially web apps / SaaS where you churn tables a lot. Simple migrations from simple models is what I love about Django and Flask/Fast API with SQL Alchemy.
- treis 6y ago>once an application becomes sufficiently complex, Perhaps, but most applications don't start off complex. Most of them start off pedal to the metal develop as fast as you can. Its also a gentler introduction to Go. I've wanted to use it on past side projects but the upfront cost of learning the language + figuring out how to get everything else was too steep of a curve.
- CameronNemo 6y agoCan golang auto generate forms based on database models? An alternative explanation for why there is no Django for Go is that Go is not expressive enough to support such levels of abstraction.
- number6 6y agoI would have chosen user authentication as an example. Better have a team looking over this stuff than to write this up on you own except you know exactly what you are doing. Might end somewhere with you users passwords public readable in an elastic bean stack...