Live data from Hacker News

Replacing Ruby on Rails: Let's Go

madebymany.com

71–80 of 89 posts

Re: Replacing Ruby on Rails: Let's Go

#71

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.

Re: Replacing Ruby on Rails: Let's Go

#72
post #14

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 app…

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.

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...

Re: Replacing Ruby on Rails: Let's Go

#73
post #14

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 app…

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.

Re: Replacing Ruby on Rails: Let's Go

#74
post #41
post #36

Earlier quoted context omitted.

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.

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.

Re: Replacing Ruby on Rails: Let's Go

#75
post #54

Earlier quoted context omitted.

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.

> 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.

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.

Re: Replacing Ruby on Rails: Let's Go

#76
post #63

Earlier quoted context omitted.

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 se…

> 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.

Re: Replacing Ruby on Rails: Let's Go

#77
post #73

Earlier quoted context omitted.

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.

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.

Potentially what you're already doing.

Re: Replacing Ruby on Rails: Let's Go

#78
post #77
post #73

Earlier quoted context omitted.

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.

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. Potentially what you're already doing.

Yep.

Re: Replacing Ruby on Rails: Let's Go

#79
post #43
post #14

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 app…

Same stack for Starfighter?

We are Rails, Golang, and Postgres, with most of our code in Golang.

Re: Replacing Ruby on Rails: Let's Go

#80
post #41
post #36

Earlier quoted context omitted.

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.

Go requires knowledge of types, which already puts its cognitive complexity ahead of PHP for the typical content creator.

Are data types that complex a concept to grasp? When I started programming in VB I don't remember it being.
Post reply on HN