Comparing that to the go standard library is apples to skyscrapers.
I don't mean to knock on Goravel or things like Apollo, but they got a very very long way to go to even measure up against Django, Rails, or Laravel in terms of functionality.
And for the little that’s not, such as an ORM, there are many third party libraries available if you want to go down that path although it’s not necessary.
There’s nice things about a lot of these frameworks for sure, like ActiveRecord, but you usually just learn the patterns in Go and roll with it. The standard library has its own consistent style.
That's a bold faced lie. In the list, the only things provided by Go are:
- routing: http.ServeMux has a router but until recently it was usually not used in real applications due to very limited capabilities (they finally added proper patterns in 1.22 which, in my view, finally makes it good enough).
- template: it's not even close to laravel's blade capabilities, but yes Go has good enough templating for most tasks.
net/http (even middlewares are just http.HandleFunc)
> database connections
We were using database/sql for the longest of times before switching to pgx since we wanted some convenience functions.
> email sending
net/mail gets you far enough unless you want to scale it.
> logging
log/slog (which is actually production grade compared to log/log)
> view template rendering
text/template, but I also think Laravel is a better choice if that’s your main focus.
Others either need an experimental standard library package (e.g. golang.org/x/crypto/argon2 for stuff like authentication) or finally need third party dependencies. DI is not enforced like other frameworks, but an extremely common pattern in Go.
At this point, do I really want to bring out a whole framework just for the last few requirements?
Go is Turing complete, sure it can do all things Laravel can. But the whole point is that with a proper full-Stack framework, you’ll get everything in a single, maintained, tested, streamlined, coherent, and documented bundle.
>routing, middleware
ogen (OpenAPI code generator), or a similar library
>database connections
from Go's stdlib mostly
>an ORM
sqlx (a lightweight wrapper around Go's stdlib which allows to hydrate results into structs)
>authentication, sessions
homegrown stuff, due to existing complex legacy stuff
>job queues
RabbitMQ's official Go wrapper (rabbitmq/amqp091-go)
>email sending
we delegate to a few separate VMs which already have postfix installed (and have good reputation)
>dependency injection
manual construction, works fine if split correctly
>logging
sirupsen/logrus (structured logger)
>view template rendering
React
>metrics
official Go wrappers for Prometheus
Some of this stuff is already IMHO industry-standard (the default libs people reach to). To streamline creation of new services, we have a tool which can scaffold your project with all these dependencies already set up.
All of the time you spent on building your scaffolding tool, researching on the libraries, checking and updating their version regularly; all of that isn’t necessary with a full-stack framework.
Once more: I’m not dismissing Go, or your way to set up projects, I’m just surprised someone would make the comparison to the Go std lib, which is so obviously not on the same level of integration and battery inclusion.
It's as simple as calling smtp.SendMail("hostname:smtp", nil, from, to, message)
In Go, these are called "channels".
