I find it a bit funny to see concurrency dragged out in a case that's pretty much a perfect example of where Ruby handles concurrency quite decently, both in term of performance, and compact, simple code.<p>E.g. his URL example:<p><pre><code> require 'net/http'
require 'uri'
urls = ["http://www.cnn.com","http://espn.go.com/","http://grantland.com","http://www.newyorker.com/"]
urls.collect do |url|
Thread.new do
response = Net::HTTP.get_response(URI.parse(url))
puts "#{url}: #{response.code} #{response.message}"
end
end.each(&:join)
</code></pre>
I'm not so convinced about the performance argument, though. I have a pure-Ruby statsd implementation collecting massive amount of metrics from dozens of servers and calculating averages, feeding time series to Redis, pulling them out and rolling them up back into Redis and to a Couchdb server for longer term storage - it was a "hack" I threw together to replace our (admittedly simplistic) usage of Graphite because Graphite does things to your disks that no hard drive should have to suffer through, and it's not breaking a sweat. I'm sure you can squeeze out a bit more with Go, but for a monitoring setup, if you're not spending most of your time waiting on IO in the kernel, I'm not quite sure what you're doing.<p>I can see their point on packaging and delivery, though, having had to deal with packaging up three sets of patched gems for three different Ruby versions just in our office environment + servers internally for an internal tool. One of the reasons I'm experimenting with my ahead-of-time/"mostly static" compiler for Ruby is that I'm very much for static binaries.<p>But we also already do have jruby which makes packaging a lot easier too. Granted I can understand people not wanting to deal with the JVM.
For completeness sake, here is an example of how to make it parallel in ruby:<p><pre><code> require 'net/http'
require 'uri'
urls = ["http://www.cnn.com","http://espn.go.com/","http://grantland.com","http://www.newyorker.com/"]
threads = urls.map do |url|
Thread.new do
response = Net::HTTP.get_response(URI.parse(url))
puts "#{url}: #{response.code} #{response.message}"
end
end
threads.each &:join</code></pre>
I think go's approach to readability is comparable to "simple English". Both have a minimal set of words (tokens) and syntax constructs. You lose some witty constructs, and you often find yourself writing in a stupid way.<p>But, since the code is always plain and stupid, you go through very few mental twists when you are parsing the language. Since code is usually read much more than written, this advantage is a huge.
I'm a huge fan of Go, but moving from Ruby to Go can't be a decision based on performance gains only.<p>There are a lot of advantages the Ruby language and ecosystem provide. What about programmer happiness and productivity? What about the experienced Ruby devs you surely have? Are they wanting to switch to Go? What about the lack of experience using Go? Are you sure you're going to avoid all the pitfalls of the new and shiny language? Isn't better hardware cheaper than your devs' time?<p>I'm not saying that your decision is wrong, and probably you have put a lot of thought into it, but most of time, developing software is using tools you know well, that are battle hardened and have been proven to deliver fast.
I shall never understand this "Ruby is slow and difficult to parallelize so let's use Go!" mindset. People knew about the negative aspects of Ruby in advance (i.e. GIL + performance) but still chose to use it even though back then (whenever that was) there were other alternatives - no doubt without the big userbase that Ruby had thanks to Rails.
Now there comes Go which makes parallelism easy(er) but introduces challenges of its own and also has some downsides (i.e. polymorphism) which Ruby solved better - but whatever: "a good developer can always work around such challenges".
So in the end, most people are just following the hype and (IMHO) exchanging one bad apple for another...
The Scout team developed a tool based on languages they knew, they proved that there was value and demand in the marketplace, and then they decided to implement a performant architecture that can be optimized to handle a larger volume of traffic.<p>Hopefully this post can help some HN startups from making the mistake of pre-optimization. You're not Google until you are Google.
i've not been paying a lot of attention to golang because it never seemed to solve a need i had, but the recent discussions around the blogosphere about how well it does cross-compilation have got me excited. every time i've tried compiling ocaml code on windows it's been a horrible experience.
"One thing that was getting our nerd juices flowing: Go."<p>I have a hard time believing that statement. Ignoring whatever "nerd juices" may be, surely something that was entirely designed for dead simple imperative syntax isn't getting them flowing.<p>You want something different, I get that. What you really want is something statically compiled and cross-platform.
If you're so serious about your web stack and know it is going to need all these fancy and performance features, why build on Ruby in the first place? Why not use something that is performant with a history of successful apps behind it like Java?<p>It seems that everyone in web is just blindly following whatever flavor of the month tech stack tech bloggers who probably spend more time writing about software than they do writing software are hyping. CRUD apps(IE 90% of web based companies) are probably one of the most solved problems in tech. Why is it that every week there is some post by some inane startup nobody has ever heard of about "why we rewrote our stack from Ruby/Python to X shiny new language that people use buzzwords I probably don't even know the meaning of to describe"? This sort of lines up with that post from yesterday I think about companies just wanting to push out the product as fast as possible rather than caring about the actual quality of it.
Why wait until you need to scale and hire 10 100k/year engineers to rewrite your app into a capable language and migrate it with 0 downtime instead of just doing shit right the first time? Seems like it would be a lot less headache, even if VCs were throwing piles of cash at you. Snapchat, for whatever other things you can fault them technically for like being hacked or whatever, did this right. They built on Java and deployed to App Engine and their application scaled right up.<p>I can understand extreme cases like Twitter(went from Ruby/Rails to Scala), where it was essentially a trivial CRUD application that eventually got so enormous that language performance features became an issue.<p>Also I don't understand why web people are so obsessed with "concurrency". How does concurrency help webapps that are just getting a request, doing some stuff with databases(which have their own well implemented concurrency mechanisms) and sending a response back so some tween can look at pics of their friends and send gossipy messages? Unless you are doing something that requires long running processes like video streaming or an online MMO type game, what is the point of it? Oddly the the parent posts' link's application in question is some kind of server monitoring service, so I really don't know why they chose Ruby.