4 ms·

My intuition is that Golang people dislike frameworks.

by imafish 3y ago

DeathArrow 3y ago
So they roll their own stuff each time they do a web app?
- maccard 3y ago
  A lot of go apps bolt together libraries yeah.
- giraffe_lady 3y ago
  From what I've seen yes. So in practice every go app is a custom & unique framework. Same problem as react. This was also the norm in php until laravel got popular a few years ago. IMO it's a rough way to make a web page but people keep doing it so it must have some advantages.
- rmilejczz 3y ago
  It’s not that we roll all our own stuff it’s just that most of us avoid opinionated frameworks. Example I’d wager most go backends are using gorm or sqlx because rolling your own orm would be insane for most
- jamil7 3y ago
  Not a go dev but I have dabbled. I get the impression that the sweet spot for go is not in building standard crud web apps but for specialised network services and tooling. For those reasons big heavy frameworks don’t seem popular.
- Philip-J-Fry 3y ago
  Composition is king. The standard library defines some decent interfaces already around HTTP handling and SQL calls. Most libraries are built to integrate with them. Then interfaces like io.Reader and io.Writer mean you can pretty much use anything to read requests and write responses. This means that usually you're composing libraries and some application code together, rather than building everything on top of some jack of all trades framework. You get to choose the best tool for each job.
  - kaba0 3y ago
    > Then interfaces like io.Reader and io.Writer mean you can pretty much use anything to read requests and write responses. Yeah, that’s not the hard part at all. What about routing, converting from/to json/params/cookies safely, sessions, authz/n..
    - maccard 3y ago
      I'm a fan of gin over the builtins but: > What about routing, converting from/to json/params/cookies safely All supported out of the box with the standard library. It's also table stakes, and not the hard part. > sessions, authz/n This is where you need to step out of the standard
- out_of_protocol 3y ago
  Yes and that's frustrating

My intuition is that Golang people dislike frameworks.

DeathArrow 3y ago

So they roll their own stuff each time they do a web app?

maccard 3y ago
A lot of go apps bolt together libraries yeah.
giraffe_lady 3y ago
From what I've seen yes. So in practice every go app is a custom & unique framework. Same problem as react. This was also the norm in php until laravel got popular a few years ago. IMO it's a rough way to make a web page but people keep doing it so it must have some advantages.
rmilejczz 3y ago
It’s not that we roll all our own stuff it’s just that most of us avoid opinionated frameworks. Example I’d wager most go backends are using gorm or sqlx because rolling your own orm would be insane for most
jamil7 3y ago
Not a go dev but I have dabbled. I get the impression that the sweet spot for go is not in building standard crud web apps but for specialised network services and tooling. For those reasons big heavy frameworks don’t seem popular.
Philip-J-Fry 3y ago
Composition is king. The standard library defines some decent interfaces already around HTTP handling and SQL calls. Most libraries are built to integrate with them. Then interfaces like io.Reader and io.Writer mean you can pretty much use anything to read requests and write responses. This means that usually you're composing libraries and some application code together, rather than building everything on top of some jack of all trades framework. You get to choose the best tool for each job.
- kaba0 3y ago
  > Then interfaces like io.Reader and io.Writer mean you can pretty much use anything to read requests and write responses. Yeah, that’s not the hard part at all. What about routing, converting from/to json/params/cookies safely, sessions, authz/n..
  - maccard 3y ago
    I'm a fan of gin over the builtins but: > What about routing, converting from/to json/params/cookies safely All supported out of the box with the standard library. It's also table stakes, and not the hard part. > sessions, authz/n This is where you need to step out of the standard
out_of_protocol 3y ago
Yes and that's frustrating