4 ms·
So many wrongs and confounding variables that I don't even know where to begin but I'll try anyway. 1) Ruby is a complex language: Ruby is quite simple. Everyt
by dkarapetyan 12y ago
So many wrongs and confounding variables that I don't even know where to begin but I'll try anyway.
1) Ruby is a complex language:
Ruby is quite simple. Everything is an object, every method call is a message send that follows the exact same protocol of dispatch. Also, completely irrelevant to the main thrust of the article.
2) Memory consumption and speed:
Can't really refute anything since by their own admission they were running a monolithic system.
3) Concurrency:
Plenty of options. I like celluloid personally and if you switch to JRuby then you can do all sorts of other stuff as well with automatically managed thread pools.
4) Backcompat:
Ruby is not an enterprise ecosystem. Some people call that speed and agility. In their case they really should have gone with Java since they are basically serving an enterprise customer. This is not a knock on Java. I think the language and its ecosystem is by design made for stuff like this.
5) PDF generation:
I'm guessing the Ruby code was calling some C library to do the rendering and they swapped out all of it for Go. I don't know what library Go is using to render PDFs if it is the same library then there is something interesting happening here. If it is a different library then they are comparing apples and oranges and there's nothing to see here.
6) Alert service:
Completely bound by I/O so doesn't matter what language you use. Bad design for keeping many processes around because you only need to spin them up during spikey times which can be easily handled with better engineering. Also eventmachine and celluloid for the worker internals would have been another option so again they didn't do their research.
7) Gradebook service:
No idea again. Thin on details so nothing to refute really.
8) Deployment:
Sure. Why not. Single binary is easier or JRuby and a single jar which is just as easy.
In conclusion, they re-wrote everything and I'm sure removed a lot of cruft in the process and called it a victory for Go. In a year or so they're going to run into similar issues and Go is not going to save them because from what I read all I saw was bad engineers blaming their tools.
- deleted 12y ago[deleted]
- dkarapetyan 12y agoYou 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.
- Argorak 12y agoHow do you think the previous design was bad? It might have been just the right thing for the first 2 years.
- dkarapetyan 12y agoMaybe 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.
- Argorak 12y agoAh, yes. I agree, I've seen quite a few very smooth Ruby deploy pipelines as well.
- nexneo 12y agoOur 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.
- wglb 12y agoRegarding 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.
- dkarapetyan 12y ago
- patio11 12y agoThis comment is more aggressive than comments should be on HN. I would exercise a bit of humility when commenting about other people's architectural decisions: they have bled all over that codebase and infrastructure, but I have not. They see it in their dreams, and I do not. They may from time to time decide to tell the community about their adventures. That is an excellent opportunity for me to learn from another engineering team's perspective and experiences, rather than an opportunity for me to demonstrate my intellectual superiority over them. They do not, as a function of having written about their experiences, owe me responses to my off-the-cuff analysis of their engineering tradeoffs.
- dkarapetyan 12y agoIn that case it's excellent story telling and nothing more. We're an engineering discipline and use case studies in engineering disciplines are measured by different standards, humility and hubris aside. You can bleed and dream about your architecture all you want but as a community we should be more analytical than that and not fall into the all the usual mental traps just because we bled for some engineering decisions. Teasing apart confounding variables and showing pros and cons of the various approaches and adding a bit more detail about the actual libraries would have made this a much better post. If he had provided all those details then some of us could have double checked the numbers with some benchmarks and learned from it but that opportunity was squandered. Once again, I'm not aggressive but I am critical. nexneo has since addressed all the issues people have brought up and if he'd done that initially then I would have been much less critical.