5 ms·

Conversely, the Go community tends to actively shun frameworks, especially anything Rails-like, and will tell you to just use the standard library. Which is goo

Conversely, the Go community tends to actively shun frameworks, especially anything Rails-like, and will tell you to just use the standard library. Which is good advice, the standard library really does have everything you need. But it's also roughly on a par with what's available in Rust (though as someone said above, the Go stdlib routines have been heavily, massively, tested in production by now, and are fully mature and load-bearing).

the__alchemist 5mo ago
Interesting! Are Go backend building custom auth, admin, DB ORM/migrations/auto migrations, templates, email, dev server etc for each project? Or each person and org has their own toolkit they use?
- marcus_holmes 5mo ago
  We tend not to use ORMs, because they're evil. There are various libraries people use for auth, etc. But rolling your own isn't hard - Go has (e.g.) bcrypt in the standard library, so most of the heavy lifting is already done, you can write a solid auth implementation in <50 lines of code using that. Generally Go prefers libraries to frameworks. Wrap the hard bits up into a library that can then be used widely in any implementation, rather than rolling it into a one-size-fits-all implementation that doesn't really suit anyone properly.
  - p2detar 5mo ago
    I second that no-ORM statement. I even follow that in Java. Object mapping is fine, but I’ll write my own SQL, rather than debug obscure (to me) HQL queries.
  - st3fan 5mo ago
    please don’t generalize. there is no “we” .. “we” are all different and i can tell you from experience that there are also many people and teams who use go and prefer ORMs and frameworks and do not build everything from scratch …
    - marcus_holmes 5mo ago
      true, but there does tend to be a consensus (or has been) in the Go community around a lot of this stuff.
  - hota_mazi 5mo ago
    > We tend not to use ORMs, because they're evil. This is typical Go culture. If it is not readily available in the language or the standard library, it's evil. It's an easy cop out to explain away the gaps in the ecosystem. Not long ago, the Go team was saying that generics are evil for that very same reason.
    - the__alchemist 5mo ago
      Rust backend is like this too, albeit softer. The gaps are explained as "Why would I want that/I don't need that" instead of "evil". My GitHub is dominated by rust projects, and I think it's the nicest overall language. But not nice enough to write bespoke solutions for problems that have had robust solutions since before I started programming! There is a basic set of functionality most web apps use, and that hasn't changed in a decade+; I don't want to re-write my own version of this, nor fight compatibility problems from (comparatively) poorly-integrated and documented libs. I am trying to make good decisions, and am weighing "This long-standing solution does everything I need, and is easy to use and well-documented etc" vs "People on the internet are telling me I don't need it, or I can use X rust lib instead". It feels like the "We have McDonald's at home" meme.
    - Orygin 5mo ago
      ORMs considered harmful even for other programming languages/ecosystems
    - tracker1 5mo ago
      I think it's contextual... IMO IoC/DI in JavaScript/TypeScript is evil, because there's a built in reference system and it's easy enough to override in testing frameworks already, so IoC/DI has much less real value and is more likely to cause harm than help. I would say that ORMs are often similar, in that depending on the environment and Object Mapper is more than enough for most use cases, again in my opinion.
- ruicraveiro 5mo ago
  I tend to use whatever I perceive to be the most fitting library for each of those concerns (except ORM), but not complete frameworks.
- whstl 5mo ago
  Most projects I see use the standard library for almost everything, but everyone leverage a few libraries here and there for one thing or the other. It's just a different philosophy, but it's really not unlike Rails users importing Devise or Sideqik or RSpec.
- phillmv 5mo ago
  >Are Go backend building custom auth, admin, DB ORM/migrations/auto migrations, templates, email, dev server etc for each project? lmao, basically, yes. except when you bring this up ppl think it's not a big deal / a means for self-expression. having to sort through which libraries you prefer to glue together is a kind of freedom, if you squint hard enough.
  - marcus_holmes 5mo ago
    I get the "you're reinventing the wheel!" thing, but trying to fit a formula 1 car wheel to my horse-and-cart system really isn't working for me. I need a different wheel, so I'll just build my own. Luckily there's a ton of good libraries available that have all the tricky bits covered so it's relatively easy to build my own wheel.
- Quothling 5mo ago
  Yes. I think few people would want to use an ORM for the stuff you use Go for, but there are things like SQLC which can generate a lot of your "dynamic DB magic" without actually being a real dependency. You can set SQLC up to run in a container in a completely isolated environment, and then use the output, but you can frankly also just maintain the SQL which frankly isn't that different than using an ORM once you've set up the automation with ridicilously strict policies. We use Go for some of our more vital backend parts. We mainly use Python for entirely different reasons, but since we're an energy company it's nice to have a standard library that can do everything without any sort of external dependencies. It's not because we have some sort of "not invented here" fetish, it's because we have to write and maintain a literal fuckton of complaince documents for every external dependency we use and it's already a full time job for just for Python in our information security department.

the__alchemist 5mo ago

Interesting! Are Go backend building custom auth, admin, DB ORM/migrations/auto migrations, templates, email, dev server etc for each project? Or each person and org has their own toolkit they use?

marcus_holmes 5mo ago
We tend not to use ORMs, because they're evil. There are various libraries people use for auth, etc. But rolling your own isn't hard - Go has (e.g.) bcrypt in the standard library, so most of the heavy lifting is already done, you can write a solid auth implementation in <50 lines of code using that. Generally Go prefers libraries to frameworks. Wrap the hard bits up into a library that can then be used widely in any implementation, rather than rolling it into a one-size-fits-all implementation that doesn't really suit anyone properly.
- p2detar 5mo ago
  I second that no-ORM statement. I even follow that in Java. Object mapping is fine, but I’ll write my own SQL, rather than debug obscure (to me) HQL queries.
- st3fan 5mo ago
  please don’t generalize. there is no “we” .. “we” are all different and i can tell you from experience that there are also many people and teams who use go and prefer ORMs and frameworks and do not build everything from scratch …
  - marcus_holmes 5mo ago
    true, but there does tend to be a consensus (or has been) in the Go community around a lot of this stuff.
- hota_mazi 5mo ago
  > We tend not to use ORMs, because they're evil. This is typical Go culture. If it is not readily available in the language or the standard library, it's evil. It's an easy cop out to explain away the gaps in the ecosystem. Not long ago, the Go team was saying that generics are evil for that very same reason.
  - the__alchemist 5mo ago
    Rust backend is like this too, albeit softer. The gaps are explained as "Why would I want that/I don't need that" instead of "evil". My GitHub is dominated by rust projects, and I think it's the nicest overall language. But not nice enough to write bespoke solutions for problems that have had robust solutions since before I started programming! There is a basic set of functionality most web apps use, and that hasn't changed in a decade+; I don't want to re-write my own version of this, nor fight compatibility problems from (comparatively) poorly-integrated and documented libs. I am trying to make good decisions, and am weighing "This long-standing solution does everything I need, and is easy to use and well-documented etc" vs "People on the internet are telling me I don't need it, or I can use X rust lib instead". It feels like the "We have McDonald's at home" meme.
  - Orygin 5mo ago
    ORMs considered harmful even for other programming languages/ecosystems
  - tracker1 5mo ago
    I think it's contextual... IMO IoC/DI in JavaScript/TypeScript is evil, because there's a built in reference system and it's easy enough to override in testing frameworks already, so IoC/DI has much less real value and is more likely to cause harm than help. I would say that ORMs are often similar, in that depending on the environment and Object Mapper is more than enough for most use cases, again in my opinion.
ruicraveiro 5mo ago
I tend to use whatever I perceive to be the most fitting library for each of those concerns (except ORM), but not complete frameworks.
whstl 5mo ago
Most projects I see use the standard library for almost everything, but everyone leverage a few libraries here and there for one thing or the other. It's just a different philosophy, but it's really not unlike Rails users importing Devise or Sideqik or RSpec.
phillmv 5mo ago
>Are Go backend building custom auth, admin, DB ORM/migrations/auto migrations, templates, email, dev server etc for each project? lmao, basically, yes. except when you bring this up ppl think it's not a big deal / a means for self-expression. having to sort through which libraries you prefer to glue together is a kind of freedom, if you squint hard enough.
- marcus_holmes 5mo ago
  I get the "you're reinventing the wheel!" thing, but trying to fit a formula 1 car wheel to my horse-and-cart system really isn't working for me. I need a different wheel, so I'll just build my own. Luckily there's a ton of good libraries available that have all the tricky bits covered so it's relatively easy to build my own wheel.
Quothling 5mo ago
Yes. I think few people would want to use an ORM for the stuff you use Go for, but there are things like SQLC which can generate a lot of your "dynamic DB magic" without actually being a real dependency. You can set SQLC up to run in a container in a completely isolated environment, and then use the output, but you can frankly also just maintain the SQL which frankly isn't that different than using an ORM once you've set up the automation with ridicilously strict policies. We use Go for some of our more vital backend parts. We mainly use Python for entirely different reasons, but since we're an energy company it's nice to have a standard library that can do everything without any sort of external dependencies. It's not because we have some sort of "not invented here" fetish, it's because we have to write and maintain a literal fuckton of complaince documents for every external dependency we use and it's already a full time job for just for Python in our information security department.