It’s honestly feature rich enough to do most things that the only other dependencies we really need to pull in is some third-party SDKs (e.g. AWS) and our database driver.
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.
>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)
