4 ms·

The standard library. 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 (

The standard library. 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.

9dev 2y ago
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.
- ayuhito 2y ago
  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 2y ago
    > 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 2y ago
      > 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 2y ago
        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 2y ago
  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.
  - tgv 2y ago
    > email sending It's as simple as calling smtp.SendMail("hostname:smtp", nil, from, to, message)
    - deleted 2y ago
      [deleted]
    - 9dev 2y ago
      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 2y ago
        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.
        2y ago
- charlie0 2y ago
  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.
- desumeku 2y ago
  >job queues In Go, these are called "channels".
  - 9dev 2y ago
    Channels are equivalent to job queues the same way walkie-talkies are equivalent to emails.

The standard library. 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.

9dev 2y ago

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.

ayuhito 2y ago
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 2y ago
  > 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 2y ago
    > 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 2y ago
      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 2y ago
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.
- tgv 2y ago
  > email sending It's as simple as calling smtp.SendMail("hostname:smtp", nil, from, to, message)
  - deleted 2y ago
    [deleted]
  - 9dev 2y ago
    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 2y ago
      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.
      - 2y ago
charlie0 2y ago
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.
desumeku 2y ago
>job queues In Go, these are called "channels".
- 9dev 2y ago
  Channels are equivalent to job queues the same way walkie-talkies are equivalent to emails.