Hacker News Reader

Comment by dkarapetyan | Hacker News Reader

You can begin by addressing all the gaps I found from a cursory glance. Go has many things going for it but you're comparing apples and oranges in your post and confounding the fact that you switched from a monolithic system to non-monolithic system. That alone removes a lot of overhead and blaming that design choice on your tools is just silly.

P.S.: There is no aggression. I'm tired of post-hoc rationalizations for rewrites of systems with bad initial design choices. Every single one of the issues you bring up could have been addressed without switching the language by an engineer well-versed in using the right libraries, celluloid and eventmachine being the first ones that come to mind for all the I/O bound stuff. I also believe in critically assessing all hype related to language and design choices and if I let your article go without criticism some impressionable young mind is going to think you're correct.

View on HN

Our ruby application had memory problems and thats why it needed overhaul, but instead of changing architecture and rewriting same thing in Ruby I choose Go. Sure, rewriting made it better, doing it in Go made it lot better.

One of the thing I said in presentation was "This performance numbers look impressive but ignore them, by rewriting in Ruby could have improve them may be not huge margin but still they would have been better"

I choose Go not because language was better, and not only for performance.

Simple deployment was key point and deployment is not just about deploy and forget, there are entire companies founded around deploying and maintaining Ruby apps for you because it's not simple thing for tiny startup.

Regarding using engineering principles, There is no aggression. I'm tired of post-hoc rationalizations are hardly from engineering discipline. The value of your comments is masked by the aggressive and unforgiving tone.

Sure, I'm not going to disagree. So far no one has addressed anything related to the actual engineering aspects and has talked about tone, aggression, and bleeding. I agree all those are valid concerns but none of them negate the fact that too many things are compounded in that post and teasing apart the language effect vs everything else is a lost cause.

Good for nexneo for re-architecting their codebase. The post could have just as easily been written as we moved from a monolithic architecture to a service based one and saw significant gains. Simple and straight to the point.

How do you think the previous design was bad? It might have been just the right thing for the first 2 years.

Maybe it wasn't but if they're complaining about deploying a Ruby service then something is wrong already in their deployment pipeline so I'm just extrapolating. I've deployed plenty of Ruby codebases and it's no more complicated deploying it than anything else that doesn't neatly fit in a single binary.

Ah, yes. I agree, I've seen quite a few very smooth Ruby deploy pipelines as well.

Reply on news.ycombinator.com