Replacing Ruby on Rails: Let's Go(madebymany.com)
madebymany.com
Replacing Ruby on Rails: Let's Go
http://madebymany.com/blog/replacing-rails-part-1-lets-go
88 comments
I for one would like to see a serious Go-based alternative to Wordpress. Virtually every major CMS out there uses PHP, and all of them are highly prone to hacking.
Question to Matt Mullenweb, co-founder of WordPress and Automattic: If you could instantly rewrite WordPress in any programming language, which would it be?
Answer: http://www.reddit.com/r/IAmA/comments/1jg781/i_am_matt_mulle...
Answer: http://www.reddit.com/r/IAmA/comments/1jg781/i_am_matt_mulle...
I don't think you're going to see a serious competitor to Wordpress in anything but PHP for a long time. The core target audience for a CMS is content creators and designers without strong compsci backgrounds. The things that make it hackable (trivial to modify in-place, extremely forgiving of type errors, no internal sandboxing, etc.) are the very things that make it attractive to non-developers.
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.
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.
The beauty (which can also be seen as a disadvantage) is that writing Go does not exactly require comp sci skills. I suspect that Go is even simpler than modern PHP as a language.
You can of course go full comp sci implementing clever algorithms in Go, but you could do that in PHP, too, and none of content creators is usually interested in this.
You can of course go full comp sci implementing clever algorithms in Go, but you could do that in PHP, too, and none of content creators is usually interested in this.
Go requires knowledge of types, which already puts its cognitive complexity ahead of PHP for the typical content creator.
Go's types can be explained as some sort of templates for values (especially record types). Any CMS user knows about templates.
Are data types that complex a concept to grasp? When I started programming in VB I don't remember it being.
Data types aren't the bottleneck, the deployment model is. Editing a Go application requires the following steps:
1. Edit the project's files.
2. Open the (scary and alienating) command line.
3. Run `go build` and hope it works right.
4. Find and stop the old running server process and start the new version
1. Edit the project's files.
2. There is no step 2.
Maybe not, but it definitely requires you to sit down and learn & understand what's going on, often longer than most of these people want to spend on one particular subject that may not be part of their regular job.
Prone to hacking because of PHP or just bad programming habits and poor plugins?
There's already http://gohugo.io/, along with a starter project described in both these places:
https://medium.com/@juanbrodriguez/hugulp-a-hugo-gulp-toolch...
http://jbrodriguez.io/mobile-friendly-website-2/
I would also like to see a serious Go-based alternative for forums. Simple Machines is truly excellent, but it's still in PHP. Go would be a far better alternative to build upon from the standpoint of security.
> Virtually every major CMS out there uses PHP
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.
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.
It's honestly one of the main reasons I got so late into the "my own web project" game. PHP and Perl to me are a ghetto. I refuse to touch them, learn them, look at them, know about them. And combine that with MySQL which is still worse IMO than Postgresql and "open source" web programming with the LAMP stack was just.................ugly.
I sound like a bad person. I can't help it.
I sound like a bad person. I can't help it.
I'm working on Journey[1] which, while "just" a blogging engine, has plugin support via Lua in the development branch. That feature is not stable yet, but hopefully in the next few days.
[1] https://github.com/kabukky/journey
[1] https://github.com/kabukky/journey
I've had the same thought, but using Node (which is more accessible to a wider group of people). Part of the (sad) state of affairs that made WordPress so popular was accessibility to the code. Can't be overlooked.
Ghost (https://ghost.org) is built with Node
Would you say that they are prone to hacking solely because they are written in PHP? Is secure PHP impossible?
Secure PHP is certainly possible, and not even that difficult. The problem is that insecure PHP is even easier to write.
In my experience, most vulnerabilities tend to come from insecure, poorly written, unvetted third party plugins and libraries.
Someone writes a plugin that creates a widget, security is either a non-thought or an afterthought. They think someone else might like the widget so they publish it. Thousands of people find it useful, even years after originally released. They are all unknowingly using an insecure piece of software.
In my experience, most vulnerabilities tend to come from insecure, poorly written, unvetted third party plugins and libraries.
Someone writes a plugin that creates a widget, security is either a non-thought or an afterthought. They think someone else might like the widget so they publish it. Thousands of people find it useful, even years after originally released. They are all unknowingly using an insecure piece of software.
Even Node or Ruby based static site generators can't compete with WP & PHP on the server. The ubiquity of PHP on web server installations is astounding and the ease of use of WP sp. for non techies in contrast with the technical knowledge and expertise expected to build and maintain a Jekyll powered website or [insert your favorite Nodejs generator] powered website.
Sorry but that's doesn't seem like a compelling argument. We're not talking about editors... You don't choose the language based on the ubiquity of the language on UNIX/Windows servers, otherwise everything would be running on Perl probably.
I guess most people, like me, choose the language they know/like and then setup the server accordingly.
I guess most people, like me, choose the language they know/like and then setup the server accordingly.
We're talking about two completely different market segments here; the corporate/enterprise market which provides more room for creative & cutting edge solutions to be implemented and then there's the SME & consumers which favor more conventional, user-friendly and "popular" solutions like WP and the likes.
> I just don't see a monolithic web framework being high up on the list of "must haves".
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.
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.
In fact, Go's standard library is fantastic, so you don't need Martini for many things. I think it provides a nice layer on top of the code for comprehensibility when reading through code
I totally agree and yeah, I used Martini to make it a little easier to read
Understood, the community really needs more idiomatic examples for building web apps. Someone should take this up.
The idea that programming languages are "worlds apart" and "vastly different" is hyperbole that would make Turing frown or maybe giggle. Have you considered that Ruby is written in C [0], and that you can do plenty of things with a general purpose programming language and some good ideas?
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
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
Your blood is 92% water. Seawater is somewhere around 95% water. Despite being incredibly similar, replacing one with the other in any great amount would be catastrophic. You share half of your DNA with a banana, but you're still completely different from a banana in any way anyone cares about.
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:
So I think it is quite possible for languages to be worlds apart while still being able to compute everything a Turing machine can.
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.
A car salesman matched a competitors price, and rounded down two dollars. He told me he is offering me a better price than the competitor. I said, "it is true you are beating their price, but not in a way that matters to me".
Different languages have tradeoffs which matter to people.
Different languages have tradeoffs which matter to people.
Different people conflate languages and frameworks to their detriment.
Framework programmers without a solid CS background dont always get it.
I've had nothing but bad experiences trying to do things I'd ordinarily do in Rails in Golang instead (and I really like Golang). Writing "Rails apps" in Golang feels a like like writing them in Sinatra used to feel: good at first, but halfway through you realize you're just wasting time reimplementing a buggier version of half of Rails.
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.
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.
I've taken a similar path as you - trying "Go for all", and ending up front-ending them with Rails,Node, etc. I felt sort of dirty doing it - but the Go ecosystem specifically around web projects is not nearly as far along for "basic things" as Rails. Heck, I saw last night that people were arguing on the right way to create basic web auth in Go!
Factoring out microservices into Go (I assume where you need better performance or concurrency) seems like a really interesting way to go rather than cutting over wholesale. Anything about it particularly difficult or interesting, or was it pretty straight forward?
Why use Rails as a frontend? One of the reasons I'm using Go for service decoupling is to get rid of Rails long startup times. I just route the requests using Nginx and skip Rails altogether.
Because it's much faster to build functionality in Rails than in Golang, and not every feature of an app has the same performance requirements.
This is what we've done. Start with Rails behind nginx, add varnish caching when needed, redis when needed, node (or golang or w/e) when necessary for the real time bits, etc.
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...
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...
I like Go, and I am replacing aspects of Rails apps with Go, but for a lot of web app uses, Rails is really, really good.
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.
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.
I commented above that I felt dirty taking the Rails for web applications, and Go for "Other" approach. But it was the best I had come up with. Thanks for the link - It was helpful and mirrors my experience.
Odd. RoR and Go address entirely different app domains.
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.
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.
Yes, and I remember how a lot of .Net people moved from .Net to ruby because of the type system. Now you are going to move to an inferior type system that doesn't even support generics and with worse type inference.
What do you see the app domains of Rails and Go as?
I've worked (as a freelancer) on a number of apps recently using Rails for the "front back-end" and either Erlang or Go for the "back back-end" and it's been working great.
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.
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.
> 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.
Nothing that Go cannot do. The only difference between Go/web and Rails is the maturity of the libraries.
Of course Go libs are way less mature for various "business tasks".
Nothing that Go cannot do. The only difference between Go/web and Rails is the maturity of the libraries.
Of course Go libs are way less mature for various "business tasks".
You can do that in Go, yet like pointed out in [1], it tends to take more effort (well, this has been my experience at least).
But well: do what works for you, really :-) I'm not commenting to persuade you, I'm just sharing one data point.
[1] http://blog.gopheracademy.com/advent-2014/atlas/
But well: do what works for you, really :-) I'm not commenting to persuade you, I'm just sharing one data point.
[1] http://blog.gopheracademy.com/advent-2014/atlas/
Did you write Gopher academy (fellow french?) ?
No I didn't! Yet I felt exactly the same. Sorry if my message was confusing :-) (I'm french indeed).
Everything can be done in Go, sure, but at least the current direction of Go is to provide small reusable libraries, not frameworks. And there's a huge difference between the two.
I don't like frameworks like RoR or ASP.NET MVC. Too much magic. Things break in weird places. They're slow. But they give programmers some kind of safe, happy sandbox that hides the "scary" web.
It's a whole different philosophy I think. Almost every week I see a new rubyists on golang-nuts looking for the "RoR equivalent" in Go-land.
I don't like frameworks like RoR or ASP.NET MVC. Too much magic. Things break in weird places. They're slow. But they give programmers some kind of safe, happy sandbox that hides the "scary" web.
It's a whole different philosophy I think. Almost every week I see a new rubyists on golang-nuts looking for the "RoR equivalent" in Go-land.
It's also 'nothing that C cannot do', but we still don't generally find it being used for such!
I've tried writing web front-ends in Go. It's a fiddly pain in the arse, and the benefits aren't really obvious. If it works for your situation then use it, but IME they're targeted at different problem domains.
I've tried writing web front-ends in Go. It's a fiddly pain in the arse, and the benefits aren't really obvious. If it works for your situation then use it, but IME they're targeted at different problem domains.
With RoR it's pretty much in the description. Monolithic web apps with relatively standard and simple domain logic (i.e. CRUD). Lots of presentation code (HTML templates, handling of static assets and what not).
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.
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.
Rails is still the best framework for building CRUD applications. It shouldn't be used for every scenario but if you want to build a traditional CRUD app, nothing is better than Rails in my opinion.
I'm surprised he chose to use Martini for the web component since the author himself has chosen to discontinue development of Martini in favor of a different approach with Negroni.
These days most people I know that use anything outside of the Golang stdlib seem to reach for Gin.
These days most people I know that use anything outside of the Golang stdlib seem to reach for Gin.
I was also surprised. Here is the relevant article:
http://codegangsta.io/blog/2014/05/19/my-thoughts-on-martini...
http://codegangsta.io/blog/2014/05/19/my-thoughts-on-martini...
The choice of library names in Go makes your comment here sound like a scene out of Mad Men.
One of the things I still think Go is weak at is the internationalisation and localisation.
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.
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.
If you come from RoR, Go is the last language/ecosystem I would think of. Elixir, Scala/Play seems to me so much more naturally fitting the Rails paradigm and the Ruby language flexibility. Go is so much different, it's not replacing Ruby on Rails, it's replacing your programming style and philosophy completely.
I like Ruby/Rails I like Go. I use Go for all backend stuff but as a web framework Rails is miles better than anything on Go currently. E.g: templating in Go...no thx
There is a tool for every job, and not every tool is a hammer.
"Framework XYZ can't do ABC, I'm switching" never holds any water.
"Framework XYZ can't do ABC, I'm switching" never holds any water.
So what's around that has a chance of replacing Wordpress? Java!
Sigh.
Sigh.
Working with CQ5 gives me the chills.
Great dayrates as a contractor doing CQ5 in London. I'm almost certain it's not worth it, but hey, you never know.
Thats because the Adobe sales people have jammed the product down a lot of enterprises. In my opinion a COTS product is never good enough to solve complex problems.
> Simply "not using Rails" anymore however is, well, not that simple!
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...
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...
If you are set to learn Go. Martini -though powerful- is not the most idiomatic. Why not try the gorilla toolbox instead? http://www.gorillatoolkit.org/. The maker of Martini wrote an interesting post last year: http://codegangsta.io/blog/2014/05/19/my-thoughts-on-martini...
When talking about Rails, you can't take Ruby out of the equation. To me, the joy of coding Ruby is unmatched by any other language. And it does have a very mature ecosystem.
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.
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.
the author has not written a single good reason why he has moved from Rails to Go. Could you please enlighten ?
I don't know why this post got so many likes? Many Go fans here?
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.
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.
Go seems like a terrible choice for any programming problem that requires data modeling/manipulation. Basic structs, slices+maps, and loops are all you have.
Go is good at plenty of things, but building abstractions is not one of them.
Go is good at plenty of things, but building abstractions is not one of them.
Sorry, I'm not from around here I guess. What do you mean? Have you seen etcd https://github.com/coreos/etcd or sync.pool?
I read your posts and I don't know if I just don't understand you or if you are trolling.
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).
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).
I never personally learned Rails so I'm just an interested observer, but can someone explain the problems with Rails currently? And why the switch in language rather than just making fixes to the framework? After looking through the article it doesn't seem like there was a very strong case made for Go. Thanks!
In a nutshell: Rails isn't shinny anymore. By migrating from (now) old Rails to new shiny Go, people can write these kinds of articles and pretend to be cutting edge and forward thinking.
its a bit more complicated than not being shiny anymore. For a lot of veterans, what's touted as best practices in the Rails community lead to maintenance headaches and performance issues in large scale long-lived applications. Rails apps tend to have a high degree of coupling internally and to gems that Just Work™ (except for when they Just Don't™).
Also, as the industry has shifted away from monolithic web frameworks to tightly controlled 'microservices' then the relevance of something as heavy as RoR wanes.
Right, although personally I think there'll be a heavy backlash against microservices (that's already begun in some circles.)
Yeah, the whole industry cycles between ideals; each generation rediscovering the benefits and drawbacks of each. Hence the renaissance of event driven applications.
It's all good. Go with the flow and learn. ;)
It's all good. Go with the flow and learn. ;)
The library author for Gorm should have done a quick Google search first. Grails has had Gorm has an ORM for years.
There's a similar problem with the name "GVM" being used in both the Groovy and Golang ecosystems, with Golang using the name first. So perhaps the library author for Gorm did do a Google/Baidu search. The Groovy/Grails project manager started the tit-for-tat by changing the meaning of "Groovy" from a language spec used for building implementations, to a specific implementation used by his Grails software.
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".