I like Ruby/Rails, I like Go. I like frameworks that make your life easier when starting a new project.
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".
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?
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.
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.
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.
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'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.
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.
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.
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.
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.
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've been using negroni. Its by the maker of Martini after he learned about 'idiomatic Go'. Very solid framework that does what it needs to and does it quickly.
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.
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:
f = open("somefile.txt")
f.write("Hello world")
f.close()
with open("somefile.txt") as f:
f.write("Hello world")
They're effectively the same, and could conceivably even be compiled to the same object code, but the latter is less error-prone — we can't accidentally leave the file open. A language that only allows the former is inherently more brittle. There's a whole world of variation like this (and also a lot unlike this) that doesn't affect whether the language is equivalent to a Turing machine, but does have a real impact on your program.
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.
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.
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.
I think jlhonora just means to proxy from nginx directly for the services that aren't powered by rails. Like 90% of the site served from rails and the high performance services are just different nginx backends.
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...
> 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.
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.
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.
> 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".
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.
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.
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.
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.
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
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...
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.
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.
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.
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 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.
Yeah, the whole industry cycles between ideals; each generation rediscovering the benefits and drawbacks of each. Hence the renaissance of event driven applications.
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".