[Townley]

Any Go developers with past experience in "heavier" frameworks have thoughts on giving it a try?

I enjoy working with "batteries included" frameworks currently, and value the approach of "Here's an ORM... here's a template language... here's an auth system... use or remove them as you see fit"

I've been told that the Go standard library is fully-featured enough that it can be considered a framework in its own right, but I haven't heard how converts from the Django/Rails world feel about the completeness of that "framework"

[majewsky]

I have written several HTTP-based services in Go. When you only expose an API, net/http is 99% of what you need. There are some useful addons like https://github.com/gorilla, and you'll probably pull in a library for auth.

For services with a web GUI, net/http is not comparable to the likes of Rails or Django. There is a templating library, but it's pretty barebones and you'll have to put quite a lot of boilerplate (or additional libraries) on top to make it work for anything beyond hello-world scale. Also you need libraries for all those secondary concerns that are usually handled on the framework level, like CSRF protection.

[ptman]

you might not need more advanced csrf protection than a cookie samesite policy.

[zadokshi]

Then throw a hidden input field with a CSRF token in your form and your done.

Not sure what the big deal is here.

[zchrykng]

> ... Go standard library is fully-featured enough that it can be considered a framework in its own right...

Maybe compared to writing a server in C/C++... ORM doesn't exist in the standard library. Templating is okay. Auth doesn't exist.

[zadokshi]

People choose go to escape the world of bloated ORM tools.

SQL sprinkled with a little bit of prudent caching works pretty well in go.

[ptman]

There's revel, which is rails-inspired. And beego, and aah and buffalo. But after those I'm looking into stdlib + chi and libraries over frameworks.