gorm

uthor's decision to go from Golang to PHP makes perfect sense if he's building SSR websites.

you do database first. For session handling I use scs github.com/alexedwards/scs , for converting form encoded data to go structs I use github.com/gorilla/schema, for logging I use zap https://github.com/uber-go/zap. For managing roles in an app I use either the voter pattern https://symfony.com/doc/current/security/voters.html in simple cases or casbin github.com/casbin/casbin . For background jobs I used https://github.com/gocraft/work and https://github.com/gocelery/gocelery , for caching i just use redis https://github.com/go-redis/redis , for data validation I used https://github.com/asaskevich/govalidator or https://github.com/go-ozzo/ozzo-validation . For sending mails to customers I used https://github.com/go-gomail/gomail If i need html forms, I first describe form elements as a struct then write form helpers in jet templating to display them like that: type LoginForm struct { Login, Password string Form } func (form *LoginForm) validate(r *http.Request) error { r.ParseForm() form.Decoder().Decode(form, r.Form) form.Errors = map[string][]string{} if err := (requiredValidator{}).validate(form.Login); err != nil { form.Errors["Login"] = append(form.Errors["Login"], err.Error()) } if err := (requiredValidator{}).validate(form.Password); err != nil { form.Errors["Password"] = append(form.Errors["Password"], err.Error()) } return form.getErrors() } func (form LoginForm) LoginFormView() LoginFormView { return LoginFormView{Fields: []Field{ {Name: "Login", Label: "Email", Type: "text", Value: form.Login, Required: true, Errors: form.Errors["Login"]}, {Name: "Password", Label: "Password", Type: "password", Value: form.Password, Required: true, Errors: form.Errors["Password"]}, {Type: "submit", Value: "Submit", Required: true}, {Type: "reset", Value: "Reset", Required: true}, }, Method: "POST", Name: "LoginForm"} } Then I can just write an helper in jet to display the the form view: {* tag attributes *} {{ block attributes() }} {{range .}} {{.Key}}="{{.Value}}" {{end}} {{ end }} {* form field *} {{block field()}} <label> {{.Label}} <br/> {{if .Type == "textarea" }} {* textarea *} <textarea name="{{.Name}}" {{ yield attributes() .Attributes }} >{{.Value}}</textarea> {{ else if .Type == "select" }} {* select *} <select name="{{.Name}}" {{yield attributes() .Attributes }}> {{ range .Options }} <option value="{{.Value}}" {{ if .Selected }} selected {{ end }}>{{.Label}}</option> {{ end }} </select> {{ else }} {* basic input *} <input type="{{.Type}}" name="{{.Name}}" {{ if isset(.Value) }} value="{{.Value}}" {{ end }} {{ yield attributes() .Attributes }} {{ if .Checked == true }} checked {{end}} /> {{ end }} </label> {{end}} {* form template *} {{block form()}} <form action="{{.Action}}" name="{{.Name}}" method="{{.Method}}"> <fieldset> {{ range .Fields }} {{yield field() .}} {{end}} </fieldset> </form> {{end}} This is the exact app structure I use to deal with dependencies and filters : https://medium.com/statuscode/how-i-write-go-http-services-a...

eck. Additionally there was another detail that really turned me off from gorm. Consider the following code: user := User{} db := getGormDB() db.Delete(user) If you were to run that Go code, given an actual gorm DB connection, the gorm ORM would delete every row in the user table. EDIT: I just noticed those benchmarks are pretty old. It's very possible and probably quite likely things have improved since then.

used API driven applications. I'm sure it can be done and I'm sure folks are doing it but if you are trying to build a sprawling Django/Pyramid webapp in Go you will probably not enjoy it as much. Here are some packages (along with the aforementioned gorm) I would recommend taking a look at: Echo: A nice little HTTP framework with a focus on JSON API's. https://echo.labstack.com gRPC: Not really for webapps (and not only for Go) but a framework for building RPC microservices: https://grpc.io/ net/http: A part of the standard library. The Go stdlib HTTP server is prod ready out of the box. You can get quite far with only the stdlib in Go: https://golang.org/pkg/net/http/ encoding/json: If you have used Marshmallow or the DRF in Python you can do most of the serialization you can do with those right out of the box in Go using struct tags and the stdlib json package: https://golang.org/pkg/encoding/json/ struct tags: https://golang.org/ref/spec#Tag

Kit/jet [5] https://github.com/jmoiron/sqlx [6] https://github.com/jinzhu/gorm [7] https://github.com/volatiletech/sqlboiler [8] https://github.com/gobuffalo/buffalo

me my personal opinion is that Go needs fewer, stronger libraries. Well supported, well maintained pieces rather than this illusion of choice that's presented today. I'm sorry if I came off as crass in my reply to the OP but that's simply the state I see in the community today. Ideally there'd be 2-4 ORMs in Go that would be the goto. And half would use a code-generation approach, half would use the reflection based approach. https://github.com/astaxie/beego/tree/master/orm https://github.com/cosiner/gomodel https://github.com/jinzhu/gorm https://github.com/go-gorp/gorp https://github.com/coocood/qbs https://github.com/go-reform/reform https://github.com/vattle/sqlboiler https://github.com/upper/db https://github.com/astaxie/beedb https://github.com/naoina/genmai https://github.com/monochromegane/argen https://github.com/square/squalor https://github.com/theduke/go-dukedb https://github.com/dropbox/godropbox/tree/master/database/sq... (...and more) And now: https://github.com/samonzeweb/godb Do we truly need this? This one in particular feels a lot like upperdb. And if it's for learning only, don't publish it to things like hackers news which makes people seem like it's something you should use as opposed to the more mature libraries out there. This is what I meant by fragmentation, it's an illusion of choice. There are actually very few logging/routing/orm/micro-framework libraries you should really use if you're serious about a project.

dvantages is that Go has much better performance, and run on Windows, etc.