Hacker News Reader

Comment by bonn1 | Hacker News Reader

Many folks in this thread are expressing that it's the OP's fault and not Ruby's.

The OP made his post as objective as possible, politely written and nobody is loosing his face, neither Ruby as a language nor the Ruby community. But people are still resentful and fire back.

I believe it's not a discussion about Ruby anymore, its strengths, its weaknesses and wether Ruby still fits in 2015—no it's the fear of people that their core competence might be less worth in future. That all the time and energy they invested all the years into one language might be not a good investment anymore. The fear that better tech will replace their tech and that they have to start at zero again.

I know I am going to be heavily downvoted for this post. Before you downvote just think a second again why you'll downvote me.

View on HN

I don't think that's a reasonable view.

The point is that articles about rebuilding entire systems in different languages conflate two things — an architecture change, and a language changes.

This often results in the sort of appraisal you see here – 'Go is better for us than Ruby, because we completely rebuilt a system and it's now better'. That's got some value, but it's frustrating to see it used as something of an absolute metric regarding the suitability of a language when it's conflated by the far more important architectural changes.

So I think your view that there are a bunch of developers who are afraid of the future is a little shallow; rather I suspect there are a bunch of developers who saw exactly the same sort of thing happen when Ruby was becoming popular, and realise that extracting helpful data when there's an ongoing fad ('we're jumping from X to Go') is rather difficult.

But a change of language might bring you more tools, for example to handle thread-pools or process pools (service worker pools). Some of these things might be much easier to do in Go (or Java or C#) than in Ruby and if that part was a reason the new version works better the language change did help. I am no saying it was impossible to improve performance with Ruby but they might believe it was easier with Go. I still think a monolith app can be more performant than micro services in a lot of situations but you might have to use things like thread pools/channels.

Others already mentioned several places you made invalid assumptions. Any good engineer worth their salt is language agnostic. I agree there are some that are threatened simply because their favorite language is no longer hip. I personally couldn't care less what the next language du jour is, be it Go or otherwise. What I do care about is that when posts like these are written they confound too many things and squander away an opportunity to let the larger programmer community double check all the numbers and verify that indeed the language/runtime was the culprit instead of something else. As it stands this is just a good story to justify the sunk cost of a re-write and nothing more.

Reply on news.ycombinator.com