4 ms·

I built my startup in Rails. I eventually re-wrote the entire application in Go as a monolith. In my experience, Go is just as productive if not more productive

I built my startup in Rails. I eventually re-wrote the entire application in Go as a monolith. In my experience, Go is just as productive if not more productive due to fewer errors at runtime. My day to day life is a lot better with Go-- no more exception emails, firefighting, etc. I really liked Rails and used it for several years, but Go came when Rails was making things difficult.. Ruby's heap memory kept growing and not being released or released too slowly. My server was using 12 GB of RAM and could hardly handle 300 concurrent users. The Go version uses 25 MB of RAM and can handle many thousands of concurrent users. edit: I understand the memory/concurrency issues are not Rails' fault entirely. It's likely ActiveRecord and Ruby as a VM that caused most issues, but it's part of the Rails deal. Getting good concurrency with Rails isn't easy, and memory issues are real.

danmaz74 3y ago
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.
pmontra 3y ago
Rails in a way is built on top of ActiveRecord so if AR is the culprit Rails is the culprit too. 300 people working together on your server and almost taking it down seems too low. Maybe you didn't use Rails in the right way but you already found your way with Go, so all is good.
- mortallywounded 3y ago
  300 active users is hardly any-- but keep in mind my product had a very active API and a browser plugin (which was basically a Rails view in an iframe) that users used often. A single user could easily hit the server hundreds (or thousands) of times in a minute.
  - pmontra 3y ago
    Ok, so it's not the typical Rails app. I was thinking about something with long CPU bound operations inside the controller or in background but a lot of hits per user is like having to serve at least 100 times more users.
BilalBudhani 3y ago
what did you use for view layer with Go? whatever I could gather looking at the Go ecosystem it seems you have to go with a JS framework for view layer and write APIs in Go. Rails' deep integration with view layer unlocks a great level of productivity.
- konart 3y ago
  > it seems you have to go with a JS framework for view layer and write APIs in Go Yes. Unless you are builing a static site.
- mortallywounded 3y ago
  I used Go's templates/html package. I simply converted Rails' ERB files into Go tmpl. It's not as pretty, but it works well.
- mozey 3y ago
  Besides the built-in templates/html, there's also this https://github.com/a-h/templ https://github.com/a-h/templ Haven't used it yet, but seems promising
  - mozey 3y ago
    Actually, just remembered why I haven't used it. Although it "Ships with IDE autocompletion", last time I checked that's only on the Go code, not the HTML. Usually I keep my templates as .html files, and find the IDE autocompletion and linter on the HTML more valuable
brightball 3y ago
I don't want to say "there was something horribly wrong with your code" but "there was something horribly wrong with your code." I've worked on a lot of large rails codebases and never seen anything close to the performance numbers you're describing. To each their own though. IMO Rails is significantly faster when it comes to being able to get a complete product to market with all of the trimmings. When it comes to specific programming problems here and there a lot of languages will be able to get the job done. That holistic "get everything done well with a small team so we can be profitable" scenario is where Rails outshines most everything else. Plus, if you're concerned about the runtime, just switch to JRuby.
- mortallywounded 3y ago
  The code itself wasn't very complicated but there was a fair amount (~15KLOC of Ruby). I'm sure there were issues in there, but I could never figure out what they were. I am not a terrible Rails developer either-- prior to building my product I had done Rails professionally for five years at a startup. It's not like I was slinging Rails code like a bootcamp graduate :)
  - brightball 3y ago
    It really sounds like a memory leak based on what you’re describing. Those can be tough to track down too.
- Alifatisk 3y ago
  > That holistic "get everything done well with a small team so we can be profitable" scenario is where Rails outshines most everything else. Well said
eutropia 3y ago
You probably wouldn't still have a startup if you started by building it in Go, though :) The rewrite was definitely a good idea by the sound of it, but of course you had prototyped your way to a stable vision of what you actually want the monolith to do using RoR. Good Job!

danmaz74 3y ago

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.

pmontra 3y ago

Rails in a way is built on top of ActiveRecord so if AR is the culprit Rails is the culprit too. 300 people working together on your server and almost taking it down seems too low. Maybe you didn't use Rails in the right way but you already found your way with Go, so all is good.

mortallywounded 3y ago
300 active users is hardly any-- but keep in mind my product had a very active API and a browser plugin (which was basically a Rails view in an iframe) that users used often. A single user could easily hit the server hundreds (or thousands) of times in a minute.
- pmontra 3y ago
  Ok, so it's not the typical Rails app. I was thinking about something with long CPU bound operations inside the controller or in background but a lot of hits per user is like having to serve at least 100 times more users.

BilalBudhani 3y ago

what did you use for view layer with Go? whatever I could gather looking at the Go ecosystem it seems you have to go with a JS framework for view layer and write APIs in Go. Rails' deep integration with view layer unlocks a great level of productivity.

konart 3y ago
> it seems you have to go with a JS framework for view layer and write APIs in Go Yes. Unless you are builing a static site.
mortallywounded 3y ago
I used Go's templates/html package. I simply converted Rails' ERB files into Go tmpl. It's not as pretty, but it works well.
mozey 3y ago
Besides the built-in templates/html, there's also this https://github.com/a-h/templ https://github.com/a-h/templ Haven't used it yet, but seems promising
- mozey 3y ago
  Actually, just remembered why I haven't used it. Although it "Ships with IDE autocompletion", last time I checked that's only on the Go code, not the HTML. Usually I keep my templates as .html files, and find the IDE autocompletion and linter on the HTML more valuable

brightball 3y ago

I don't want to say "there was something horribly wrong with your code" but "there was something horribly wrong with your code." I've worked on a lot of large rails codebases and never seen anything close to the performance numbers you're describing. To each their own though. IMO Rails is significantly faster when it comes to being able to get a complete product to market with all of the trimmings. When it comes to specific programming problems here and there a lot of languages will be able to get the job done. That holistic "get everything done well with a small team so we can be profitable" scenario is where Rails outshines most everything else. Plus, if you're concerned about the runtime, just switch to JRuby.

mortallywounded 3y ago
The code itself wasn't very complicated but there was a fair amount (~15KLOC of Ruby). I'm sure there were issues in there, but I could never figure out what they were. I am not a terrible Rails developer either-- prior to building my product I had done Rails professionally for five years at a startup. It's not like I was slinging Rails code like a bootcamp graduate :)
- brightball 3y ago
  It really sounds like a memory leak based on what you’re describing. Those can be tough to track down too.
Alifatisk 3y ago
> That holistic "get everything done well with a small team so we can be profitable" scenario is where Rails outshines most everything else. Well said

eutropia 3y ago

You probably wouldn't still have a startup if you started by building it in Go, though :) The rewrite was definitely a good idea by the sound of it, but of course you had prototyped your way to a stable vision of what you actually want the monolith to do using RoR. Good Job!