I don't think Go is anywhere near the list of languages to build a Rails successor on top of. Rails can do so much of the cool stuff it does because Ruby is an incredibly flexible language.
Go, on the other hand, could be described as "inflexible as a feature". You have a beautifully simple language that optimizes for concurrency and other issues that simply aren't considerations in the Ruby world.
The two languages are worlds apart and designed to solve vastly different problems. I support new tools for Go, but I just don't see a monolithic web framework being high up on the list of "must haves".
Answer: http://www.reddit.com/r/IAmA/comments/1jg781/i_am_matt_mulle...
Nothing is going to dethrone Wordpress unless it's at least as easy to cargo cult, and anything that does will more or less by definition annoy experienced developers more than what it replaced.
This probably has to do with the majority of cheap web hosts out there offering only PHP, Perl, and (if you're really lucky) Rails.
And I think that's what makes Go so welcome to many people. In fact, I'm tired of frameworks that do everything for me because they tend to do everything just "well enough".
And I noticed the OP is using Martini - which isn't necessarily bad - but it's not needed. It does make learning a language like Go a lot easier for newcomers though... I do think this sheds some wrong light on how people should be using Go. Martini isn't the answer, you should be using interfaces to make your code easier to work with, especially since they are implemented in Go so well.
Edit: Would you care to substantively explain the downvote(s)? The parent is so preoccupied with frameworks he's overlooking the basics.
[0] http://en.wikipedia.org/wiki/Ruby_%28programming_language%29
The fact that Prolog, Fortran and Ruby are all Turing-complete is useful to know from a computer science standpoint, but from a perspective of actual use, it just isn't that relevant. A language — whether human or computer — isn't just about the algorithms it can express, but about the ways it lets you express them, understand them and combine them. And Turing equivalence tells us very little about that sort of thing.
This is a bit abstract, so here's a tiny but concrete example of how differences in how you express an algorithm can have a tangible effect:
f = open("somefile.txt")
f.write("Hello world")
f.close()
with open("somefile.txt") as f:
f.write("Hello world")
So I think it is quite possible for languages to be worlds apart while still being able to compute everything a Turing machine can.
Different languages have tradeoffs which matter to people.
On the other hand, I've had very good experiences factoring subsets of Rails apps out into trivial HTTP/JSON services, and frontending them with Rails. That's how Microcorruption.com works, for instance.
Get's a bit messy with all these moving parts, but I think that's the just the nature of large projects. Elixir + Phoenix looks interesting though...
The only thing that connects them is that RoR was trendy yesterday, and Go is trendy today.
If this is the rationale for replacement, the author will be writing plenty of "replacing" articles in the years forward.
Rails works great for things like authentication, creating a nice and maintainable UI, handling billing code, sending emails, managing the database schema, and all the web related stuff.
Erlang and Go work nicely for all the "heavy work", think sending tens of million of push notifications quickly, crunching data etc.
They can communicate using a shared, Rails-maintained database, and things like Redis to trigger updates or orders.
You can even do Erlang-backend processing of Sidekiq payloads, pushed from the Rails side etc.
All in all: use each tool for its own strengths.
Go is for writing small, focused, paralellizable and likely distributed services. If I wanted to crunch data, I'd try Go.
I'd expect, say, a RoR app to connect to a Go service for some of its heavier domain logic. I'd neither write a RoR-type app in Go, nor a Go-type service in RoR.
These days most people I know that use anything outside of the Golang stdlib seem to reach for Gin.
http://codegangsta.io/blog/2014/05/19/my-thoughts-on-martini...
Sigh.
Go is good at plenty of things, but building abstractions is not one of them.
I believe what the parent post refers to is that Ruby - being a dynamic language - is way more flexible with types and data structures. On top of that it has very convenient methods for data manipulation. This allows you to express solutions in a fewer lines of code compared to lower languages (with the added downside of slowness of course).
Hashicorp, who has a very high Go competence, migrated away from Go to Rails for their web service.
http://blog.gopheracademy.com/advent-2014/atlas/
> Once we decided to evaluate other technologies for our web service, we had a few choices. Based on having Rails experience and the maturity of that tooling we saw it as the most pragmatic option. As we began our initial port, we realized that over two weeks worth of work in Go had been replaced in just a few hours in Rails. We were sold.
There is nothing as feature-rich and widely adopted as the Django equivalents for translation https://docs.djangoproject.com/en/1.8/topics/i18n/translatio... formatting of dates and times https://docs.djangoproject.com/en/1.8/topics/i18n/formatting... or for handling timezone conversions https://docs.djangoproject.com/en/1.8/topics/i18n/timezones/ .
Ideally the Go core, or the Go community, would provide a great experience (consistent, idiomatic, documented, supported) for developers coming from Rails, Django and other platforms.
Right now I recommend Go for backend and APIs, but I stop short of recommending replacing your Rails or Django with Go. There's still an enormous amount of work you would have to do to come close to the kind of web app support you'll find in platforms that are already mature and focused on delivering front-end web experiences.
"Framework XYZ can't do ABC, I'm switching" never holds any water.
After the OP has described why he likes Rails ("good toolset", "Ruby gems cover everything"), I would've really liked to know why OP wants to switch away from Rails.
> so what's around that has a chance of replacing Rails? Go!
Again, the OP gives no reason why he switched to Go instead of looking at another web framework for Ruby, and also not why he chose the particular Go frameworks to replace Rails.
That's what would've really interested me, after the introduction I didn't quite see a Go-tutorial coming...
Ruby and Go are both awesome, I could write you a love letter about both of them. But in my mind they have way too different use cases and coding styles to be brought up in the same sentence.
I personally think any language that compiles to JavaScript and are quite similar are the perfect language for web. Since you can re-use code from client and the server. Right now my bet is TypeScript.