[9dev]

I assume you have never used Django or Rails or Laravel then. With these, you get a web application with routing, middleware, schema validation, database connections, an ORM, authentication, sessions, job queues, email sending, distributed caching, dependency injection, logging,secret handling, view template rendering, websockets, metrics, and much more—right after the installation, set up with conventions allowing other developers to get productive immediately.

Comparing that to the go standard library is apples to skyscrapers.

[charlie0]

It's so obvious when someone hasn't even looked at those 3 frameworks because they think those are just some simple routing/controllers + ORM, lol. That's like 10% of the total functionality they offer, not counting all the extra stuff provided by their respective ecosystem.

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.

[ayuhito]

Almost everything you listed already exists in the standard library.

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.

[tredre3]

> Almost everything you listed already exists in the standard library.

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.

[ayuhito]

> routing, middleware

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?

[9dev]

It’s like you’re saying, „get a Raspberry Pi instead of an iPhone, it can do the same things!“

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.

[kgeist]

Just my two cents how we do it in most of our projects at this point (~70 services in Go):

>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.

[9dev]

Im not saying all of this isn’t possible in Go, or somehow worse. My point is that using eg. Laravel, you don’t even need third-party libraries for these things, just the framework. And all of it is built on the same conventions, documented in the same place, with the same API. Scaffolding is built-in too.

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.

[tgv]

> email sending

It's as simple as calling smtp.SendMail("hostname:smtp", nil, from, to, message)

[9dev]

It’s not. One thing is sending batches of transactional mail to thousands of recipients in a production web application running on a bunch of replicated containers on ephemeral machines, the other is proof that SMTP theoretically works in your programming language.

[desumeku]

It does not take more than 10 lines of code to launch a goroutine (or two, or more, due to how easy worker pools are in Go) that receives email requests and sends them in batches.

[9dev]

And some more to add retries. And then another few to handle attachments. And just some more to generate previews. And multipart messages. And testing. And just like that, you spent a whole lot of time to reinvent something frameworks like Laravel include out of the box, right now. And did I mention it is documented and any other developer familiar with the framework can immediately use, without having to waste time reading library code?

[desumeku]

"A little copying is better than a little dependency."

[desumeku]

>job queues

In Go, these are called "channels".

[9dev]

Channels are equivalent to job queues the same way walkie-talkies are equivalent to emails.