The library author for Gorm should have done a quick Google search first. Grails has had Gorm has an ORM for years.
Replacing Ruby on Rails: Let's Go
71–80 of 89 posts
Re: Replacing Ruby on Rails: Let's Go
#72I'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.
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
#73I'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.
Re: Replacing Ruby on Rails: Let's Go
#74Earlier 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.
Re: Replacing Ruby on Rails: Let's Go
#75Earlier 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.
I sound like a bad person. I can't help it.
Re: Replacing Ruby on Rails: Let's Go
#76Earlier 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".
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
#77Earlier 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.
Potentially what you're already doing.
Re: Replacing Ruby on Rails: Let's Go
#78Earlier 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.
Re: Replacing Ruby on Rails: Let's Go
#79I'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?
Re: Replacing Ruby on Rails: Let's Go
#80Earlier 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.