This video started touching on the problem but they never really get to it. I've been using Rails at my new gig (I hate it) and I've worked with Go professionally for a few years, so here's my two cents as to why Golang doesn't have something like Rails: Ruby, Python, PHP, are all interpreted languages. Big frameworks tend to work better with interpreted languages, for several reasons: You don't need to compile on every change. You can drop to a REPL to test out your changes manually. Dynamic programming is significantly easier Go is a statically typed language that compiles down to a single binary. This makes big frameworks a bit less attractive because as your application and the web framework scale, the size of your binary, its compile times, and its deployment does too. With an interpreted language, all you have to do is deploy the actual scripts themselves. In a containerized environment the interpreter is already built in one of the cached images, so you just copy the scripts over and it works. Another problem is that there's no concept of a REPL or a task runner (like Rake or Celery), so if you want to perform tasks using the big framework, you have to either create a specific Go binary that performs this task or find a Golang specific task running tool. A lot of Rubyists become attached to the Rails framework and will attempt to use the framework for everything. For instance, why write SQL queries if you can just use the Rails models? SELECT * FROM transactions WHERE id = $1 vs. Transaction.find(1) Lastly, Ruby, Python and PHP are all dynamic languages. Go's static typing works against it here. Rails is heavy on the metaprogramming to make it read like the English language. For instance, there are lot of folder and file conventions in Rails that affect its runtime functionality. There's nothing of the sort in Go. Your files are independent of each other and folders form the basis of Go packages. Anyhow, that's why I think there's no big frameworks for Go. Answer from scooptyy on reddit.com