5 ms·

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

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.

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.