Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Replacing Ruby on Rails: Let's Go

madebymany.com

Post reply on HN
Print view View original

81–89 of 89 posts

Re: Replacing Ruby on Rails: Let's Go

#81

Post by Grazester »

vec wrote: post #15
higherpurpose wrote: post #5

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.

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…

Prone to hacking because of PHP or just bad programming habits and poor plugins?

Re: Replacing Ruby on Rails: Let's Go

#82

Post by socceroos »

merb wrote: post #60
xasos wrote: post #38

Earlier quoted context omitted.

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

Better use gin or negroni, since martini is slow due to reflections

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.

Re: Replacing Ruby on Rails: Let's Go

#83

Post by socceroos »

karmajunkie wrote: post #62
BSousa wrote: post #56

Earlier quoted context omitted.

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.

Re: Replacing Ruby on Rails: Let's Go

#84

Post by karmajunkie »

socceroos wrote: post #83
karmajunkie wrote: post #62

Earlier quoted context omitted.

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

Re: Replacing Ruby on Rails: Let's Go

#85

Post by socceroos »

karmajunkie wrote: post #84
socceroos wrote: post #83

Earlier quoted context omitted.

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

Re: Replacing Ruby on Rails: Let's Go

#86

Post by ddoolin »

Grazester wrote: post #80
cheald wrote: post #41

Earlier quoted context omitted.

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.

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.

Re: Replacing Ruby on Rails: Let's Go

#87

Post by jlhonora »

rapind wrote: post #77
tptacek wrote: 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.

Exactly

Re: Replacing Ruby on Rails: Let's Go

#88

Post by vec »

Grazester wrote: post #80
cheald wrote: post #41

Earlier quoted context omitted.

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.

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
Oh, and you'd better hope step 3 goes smoothly, because a tiny mistake anywhere in your application will cause this weird thing called a "compiler error" that means that the entire thing will break. Editing a Wordpress site, on the other hand, looks like this:

  1.  Edit the project's files.
  2.  There is no step 2.
As developers, we're comfortable with the first workflow. We happily accept the added complexity because of all the other nice things it gives us and because we're probably using other tools like version control that end up making our experience much more uniform between the two. But to a user whose primary experience is with editing Word documents there is a huge jump there.

Re: Replacing Ruby on Rails: Let's Go

#89

Post by Omnipresent »

bshimmin wrote: post #22
Omnipresent wrote: post #7

Earlier quoted context omitted.

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.
Post reply on HN