3 ms·

Has anyone tried both Pagoda and GoBuffalo and can compare? GoBuffalo recently archived their github project and basically become unmaintained, which is extrem

by divan 2y ago

Has anyone tried both Pagoda and GoBuffalo and can compare? GoBuffalo recently archived their github project and basically become unmaintained, which is extremely sad for such a mature framework used in production by many.

BoorishBears 2y ago
Is this common in Go? Just this week I was examining moving my early stage stack to Golang, but I repeatedly came across highly recommended packages that were dead. Gorilla had apparently died but come back in some capacity, Echo seems to be actively dying as PRs aren't being addressed, Buffalo was an option I looked at and is now archived Does the "just use the stdlib" mentality mean everyone is just rolling the glue layers on their own 1000x over?
- moomoo11 2y ago
  Can’t speak for buffalo but there are many libraries that have not been updated in a while and there’s a reason for that - they are complete. There is no reason to update them, this isn’t nodejs that depends on one billion packages to do one thing where one of those changing basically affects any downstream users. The std library is awesome, backwards compatible, and lots of libraries just add onto it. The interfaces are compatible and you can just keep your code simple. I used to code a lot in Go. These days I’m back in node because it’s just easier for me to move faster. I’m also not doing anything with concurrency, so haven’t had a real need for Go I think for core critical services I would use Go again just I haven’t needed to yet with my new project.
  - BoorishBears 2y ago
    I can appreciate feature complete software but ignoring PRs and literally archiving the Github project means it's dead, not complete.
- azuanrb 2y ago
  I just started coding in Go professionally over a year now. So far, that's the pattern that I'm seeing as well. I'm not really a fan. Some common answers on why to not use a lib is because it's trivial to rollout your own. I like Go as a language but not so much on the community because of the reasons above. I just don't want to implement cache/cron for the n-th time again. I'd rather spending more time on building a new product instead, which is not the case when I'm using Go.
  - arp242 2y ago
    There's a bunch of caching and cron libraries; you can pick one that best suit your needs, and you don't really need to implement that from scratch.
- tonyhart7 2y ago
  Yeah sadly this is the case for most webframework in Go, but if you want looking for something like that check beego
- divan 2y ago
  No, definitely not common. GoBuffalo had some initial design frustrations, but overall it was such a solid and well maintained project. I was really surprise to discover that the Github repo was just quietly archived. Gophers slack has a channel for buffalo, and users still can provide some help, but still.
cgg1 2y ago
I found Pagoda required me to juggle too many things that were only loosely coupled together. GoBuffalo was great but as soon as I started using, it got archived :’) Now I default to beego. It isn’t as batteries included as a rails or django app, but there’s enough there that I don’t have to write as much boilerplate as with only the stdlib.
Xeoncross 2y ago
It's often the change that happens with experience. Most developers join Go looking for their Laravel, Rails, Next.js, Spring framework. Because it's almost impossible to write something in those languages without a framework. In Go, the longer you use it, the more you realize "just use the stdlib" actually works for most things. A lot of these projects die because most Go devs either 1) need a mux and use httprouter or gorilla or 2) need a more robust multi-instance setup (go-kit, goa.design, smithy, etc..) Most big projects just don't use a MVC (or otherwise framework) as it's more work to use, update and understand than just writing your own glue for the libraries you do need. I might have explained this poorly, but I like to think of Go as a collection of packages where other languages are a collection of frameworks because the packages can't be used together easily and need organization on top to ensure everything works.
- ch4s3 2y ago
  > Because it's almost impossible to write something in those languages without a framework That doesn't sound right to me at all. I've definitely worked on some apps in Ruby that we basically just rack, and a few gems. And good lord, the Java landscape is full of in house architectures. > I might have explained this poorly, but I like to think of Go as a collection of packages This is exactly the approach a lot of JS apps took for a long time. That's what MERN(mongo/express/react/node) was about.

by divan 2y ago

BoorishBears 2y ago

Is this common in Go? Just this week I was examining moving my early stage stack to Golang, but I repeatedly came across highly recommended packages that were dead. Gorilla had apparently died but come back in some capacity, Echo seems to be actively dying as PRs aren't being addressed, Buffalo was an option I looked at and is now archived Does the "just use the stdlib" mentality mean everyone is just rolling the glue layers on their own 1000x over?

moomoo11 2y ago
Can’t speak for buffalo but there are many libraries that have not been updated in a while and there’s a reason for that - they are complete. There is no reason to update them, this isn’t nodejs that depends on one billion packages to do one thing where one of those changing basically affects any downstream users. The std library is awesome, backwards compatible, and lots of libraries just add onto it. The interfaces are compatible and you can just keep your code simple. I used to code a lot in Go. These days I’m back in node because it’s just easier for me to move faster. I’m also not doing anything with concurrency, so haven’t had a real need for Go I think for core critical services I would use Go again just I haven’t needed to yet with my new project.
- BoorishBears 2y ago
  I can appreciate feature complete software but ignoring PRs and literally archiving the Github project means it's dead, not complete.
azuanrb 2y ago
I just started coding in Go professionally over a year now. So far, that's the pattern that I'm seeing as well. I'm not really a fan. Some common answers on why to not use a lib is because it's trivial to rollout your own. I like Go as a language but not so much on the community because of the reasons above. I just don't want to implement cache/cron for the n-th time again. I'd rather spending more time on building a new product instead, which is not the case when I'm using Go.
- arp242 2y ago
  There's a bunch of caching and cron libraries; you can pick one that best suit your needs, and you don't really need to implement that from scratch.
tonyhart7 2y ago
Yeah sadly this is the case for most webframework in Go, but if you want looking for something like that check beego
divan 2y ago
No, definitely not common. GoBuffalo had some initial design frustrations, but overall it was such a solid and well maintained project. I was really surprise to discover that the Github repo was just quietly archived. Gophers slack has a channel for buffalo, and users still can provide some help, but still.

cgg1 2y ago

I found Pagoda required me to juggle too many things that were only loosely coupled together. GoBuffalo was great but as soon as I started using, it got archived :’) Now I default to beego. It isn’t as batteries included as a rails or django app, but there’s enough there that I don’t have to write as much boilerplate as with only the stdlib.

Xeoncross 2y ago

It's often the change that happens with experience. Most developers join Go looking for their Laravel, Rails, Next.js, Spring framework. Because it's almost impossible to write something in those languages without a framework. In Go, the longer you use it, the more you realize "just use the stdlib" actually works for most things. A lot of these projects die because most Go devs either 1) need a mux and use httprouter or gorilla or 2) need a more robust multi-instance setup (go-kit, goa.design, smithy, etc..) Most big projects just don't use a MVC (or otherwise framework) as it's more work to use, update and understand than just writing your own glue for the libraries you do need. I might have explained this poorly, but I like to think of Go as a collection of packages where other languages are a collection of frameworks because the packages can't be used together easily and need organization on top to ensure everything works.

ch4s3 2y ago
> Because it's almost impossible to write something in those languages without a framework That doesn't sound right to me at all. I've definitely worked on some apps in Ruby that we basically just rack, and a few gems. And good lord, the Java landscape is full of in house architectures. > I might have explained this poorly, but I like to think of Go as a collection of packages This is exactly the approach a lot of JS apps took for a long time. That's what MERN(mongo/express/react/node) was about.