5 ms·

Which framework did you use with go to be as productive as with rails?

by danmaz74 3y ago

lsferreira42 3y ago
That's what i was asking myself, i've been looking for a good batteries included golang web framework
- konart 3y ago
  You should probably stop because this is not a Go-way. And you wan't find anything with "batteries" other than https://github.com/gobuffalo/buffalo https://github.com/gobuffalo/buffalo and https://github.com/beego/beego https://github.com/beego/beego Haven't see anyone actually using them in production though.
  - infecto 3y ago
    Using github stars and some kind of proxy for popularity/usage, Beego looks to be number 2. Seems like it could be production worthy and probably is being used somewhere.
  - lsferreira42 3y ago
    I actually use buffalo as reference to implement somethings, using the modules buffalo uses instead of using it. Tried beego some time ago and everything felt out of place, websites not working, unresponsive dev's on github and so on. Today i'am happy with the standard lib + mux + some otheer libs for other functionalities, it's just more work than rails but this also works!!
- arp242 3y ago
  I've spent a lot of time doing Rails and Go, and I also find that on balance, it doesn't make that much difference. It's hard to measure though. I'm not "against" frameworks, but there are up- and downsides. E.g. in Rails I had quite some trouble with complex forms, which eventually resulted in form_this[1], which actually worked pretty well for the application I was working on. For a lot of apps you don't need this kind of thing, but when you do, it's quite difficult to do something outside the Rails "happy path". Maybe newer versions of Rails handle this better; I haven't really kept up. I found the Rails codebase rather tricky at times. You get things like: [:method1, :method2, :method3].each do |name| define_method name, [..] define_method "#{name}=", [..] define_method "#{name}_foo", [..] end And it's really neat you can do that in Ruby, but it can also make a codebase kind of tricky to debug – it's the old "you need to be twice as clever to debug code than to write it". While I generally found Rails to be pretty good, it does have bugs and quirks. On the flipside with Go you spend a bit more time writing your own code, but that code will be better suited to what you're doing. Sometimes people seem to be afraid to write code, but I found it's not a bad thing and "do it yourself" can be quicker and better than "adapt existing thing to your needs". On balance, it seems to more or less cancel out. Maybe there's some difference one way or the other, but it doesn't seem to be huge. [1]: https://github.com/bluerail/form_this https://github.com/bluerail/form_this
  - bradgessler 3y ago
    Rails form helpers really leave a lot to be desired because they’re difficult to customize without jumping through a lot of hoops. I wrote a clean sheet Rails form helper library at https://github.com/rubymonolith/superform https://github.com/rubymonolith/superform that’s completely customizable and even permits its own strong parameters.
mortallywounded 3y ago
If you measure productivity by how many features you can push in a week, Rails will probably win every time. I look at productivity in the long run. I have been running this product for seven years now and there's a lot of legacy business logic and cruft. The Rails application was difficult to change (but easy to pump new things out). As the product matured, fewer new features were really needed so the edge Rails had was gone and all that was left was an application that was hard to change without breaking something. Go's edge came in and reduced the server's memory footprint and was easy to maintain and make changes. If the Go code compiled, I was confident it would work (I never felt that way with Rails). To answer your question directly: I didn't use any framework. My application only has two external dependencies: gorilla/securecookie (cookie encryption) and lib/pq (database driver for postgres). I could probably do without securecookie, but I was hesitant to do anything encryption related on my own. Everything else is standard library Go code.

Which framework did you use with go to be as productive as with rails?

lsferreira42 3y ago

That's what i was asking myself, i've been looking for a good batteries included golang web framework

konart 3y ago
You should probably stop because this is not a Go-way. And you wan't find anything with "batteries" other than https://github.com/gobuffalo/buffalo https://github.com/gobuffalo/buffalo and https://github.com/beego/beego https://github.com/beego/beego Haven't see anyone actually using them in production though.
- infecto 3y ago
  Using github stars and some kind of proxy for popularity/usage, Beego looks to be number 2. Seems like it could be production worthy and probably is being used somewhere.
- lsferreira42 3y ago
  I actually use buffalo as reference to implement somethings, using the modules buffalo uses instead of using it. Tried beego some time ago and everything felt out of place, websites not working, unresponsive dev's on github and so on. Today i'am happy with the standard lib + mux + some otheer libs for other functionalities, it's just more work than rails but this also works!!
arp242 3y ago
I've spent a lot of time doing Rails and Go, and I also find that on balance, it doesn't make that much difference. It's hard to measure though. I'm not "against" frameworks, but there are up- and downsides. E.g. in Rails I had quite some trouble with complex forms, which eventually resulted in form_this[1], which actually worked pretty well for the application I was working on. For a lot of apps you don't need this kind of thing, but when you do, it's quite difficult to do something outside the Rails "happy path". Maybe newer versions of Rails handle this better; I haven't really kept up. I found the Rails codebase rather tricky at times. You get things like: [:method1, :method2, :method3].each do |name| define_method name, [..] define_method "#{name}=", [..] define_method "#{name}_foo", [..] end And it's really neat you can do that in Ruby, but it can also make a codebase kind of tricky to debug – it's the old "you need to be twice as clever to debug code than to write it". While I generally found Rails to be pretty good, it does have bugs and quirks. On the flipside with Go you spend a bit more time writing your own code, but that code will be better suited to what you're doing. Sometimes people seem to be afraid to write code, but I found it's not a bad thing and "do it yourself" can be quicker and better than "adapt existing thing to your needs". On balance, it seems to more or less cancel out. Maybe there's some difference one way or the other, but it doesn't seem to be huge. [1]: https://github.com/bluerail/form_this https://github.com/bluerail/form_this
- bradgessler 3y ago
  Rails form helpers really leave a lot to be desired because they’re difficult to customize without jumping through a lot of hoops. I wrote a clean sheet Rails form helper library at https://github.com/rubymonolith/superform https://github.com/rubymonolith/superform that’s completely customizable and even permits its own strong parameters.

mortallywounded 3y ago

If you measure productivity by how many features you can push in a week, Rails will probably win every time. I look at productivity in the long run. I have been running this product for seven years now and there's a lot of legacy business logic and cruft. The Rails application was difficult to change (but easy to pump new things out). As the product matured, fewer new features were really needed so the edge Rails had was gone and all that was left was an application that was hard to change without breaking something. Go's edge came in and reduced the server's memory footprint and was easy to maintain and make changes. If the Go code compiled, I was confident it would work (I never felt that way with Rails). To answer your question directly: I didn't use any framework. My application only has two external dependencies: gorilla/securecookie (cookie encryption) and lib/pq (database driver for postgres). I could probably do without securecookie, but I was hesitant to do anything encryption related on my own. Everything else is standard library Go code.