5 ms·

I would imagine that Go has the advantage of being significantly faster than Racket. Although if people still loves to do things in Ruby maybe performance is le

I would imagine that Go has the advantage of being significantly faster than Racket. Although if people still loves to do things in Ruby maybe performance is less than a concern in web development.

TylerE 13y ago
You'd be wrong. Go IS faster, but not significantly so, and it's not a clear cut winner either. http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=racket&lang2=go&data=u64 http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...
- pmelendez 13y ago
  Well five out of ten Go is at least 2X faster (that's significant enough to me). In any case, probably the difference won't be noticeable since the bottleneck for most websites is the database side.
  - TylerE 13y ago
    But compare either, with, say, Python or Ruby and the difference is more than lost in the noise.
- amaranth 13y ago
  I'm pretty sure at least one of those tests Racket does better at is essentially a GC benchmark. Go's GC is still fairly weak.
bhauer 13y ago
> Although if people still loves to do things in Ruby maybe performance is less than a concern in web development. As a user of web sites (and a web developer), I find it disappointing and frustrating to use web sites designed by people who clearly have not made performance a priority. So just as a tangential point: if you are one of those web developers who loves doing things on slower platforms, believing that it's just fine to disregard performance, please think of your users! We are the ones who suffer! 250ms here, 500ms there, sometimes over 1,000ms before the server responds with the first byte! It adds up to an annoying user experience. Among popular sites, those that are slow tend to really irk me, and I seek out alternatives. For example, there is this very popular source code social network site...
- VeejayRampay 13y ago
  User-perceived response time has little to do with the choice of language on the server. Access to DBs, lack of proper caching strategies, CDNs, minification of CSS and Javascript play a much larger role in the big picture. Only when you've extracted all the juice from all those lower-hanging fruits must you start to blame the language or framework used to developer a website IMHO.
  - bhauer 13y ago
    I'm not talking about a client-side performance issue. Those are tangential matters. We should all endeavor to comply with best practices for delivery of static assets to improve client-side performance including minification, strategic concatenation, use of content delivery networks, caching strategies, and so on. Let's put that aside, however. What I am talking about is a real request to a non-cachable dynamic page or service endpoint. It's the frustration of "Waiting for [servername]..." status bar messages. It's the frustration of looking at the Network panel in Chrome or Firebug and realizing that it's just spinning waiting for the first byte of the response. It might be a server-templated HTML page. It might be an API call fetching some JSON. But the sorry state even in 2013 is that a disturbingly large number of sites will spend hundreds of milliseconds, and in some cases full seconds to respond to dynamic requests that ultimately deliver quite trivial response payloads. I for one want developers to stop sweeping these performance failures under the rug by deflecting server-side performance failure with client-side cover.
- drdaeman 13y ago
  I believe, in most cases of those milliseconds amount to network and database/storage latency, not site code's performance. So it's just insignificant (performance-wise) whenever you write site in carefully optimized C or just write some Ruby magic that performs, say, 100x slower. 1ns vs 100ns is insignificant when it's your database that responds in 300ms.
  - TylerE 13y ago
    You couldn't be more wrong. PHP and Ruby page generation times can easily exceed 1000ms if the programmer isn't careful. Nanoseconds is just rubbish. Even the fastest template engines typically take on the order of a few ms.

I would imagine that Go has the advantage of being significantly faster than Racket. Although if people still loves to do things in Ruby maybe performance is less than a concern in web development.

TylerE 13y ago

You'd be wrong. Go IS faster, but not significantly so, and it's not a clear cut winner either. http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=racket&lang2=go&data=u64 http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...

pmelendez 13y ago
Well five out of ten Go is at least 2X faster (that's significant enough to me). In any case, probably the difference won't be noticeable since the bottleneck for most websites is the database side.
- TylerE 13y ago
  But compare either, with, say, Python or Ruby and the difference is more than lost in the noise.
amaranth 13y ago
I'm pretty sure at least one of those tests Racket does better at is essentially a GC benchmark. Go's GC is still fairly weak.

bhauer 13y ago

> Although if people still loves to do things in Ruby maybe performance is less than a concern in web development. As a user of web sites (and a web developer), I find it disappointing and frustrating to use web sites designed by people who clearly have not made performance a priority. So just as a tangential point: if you are one of those web developers who loves doing things on slower platforms, believing that it's just fine to disregard performance, please think of your users! We are the ones who suffer! 250ms here, 500ms there, sometimes over 1,000ms before the server responds with the first byte! It adds up to an annoying user experience. Among popular sites, those that are slow tend to really irk me, and I seek out alternatives. For example, there is this very popular source code social network site...

VeejayRampay 13y ago
User-perceived response time has little to do with the choice of language on the server. Access to DBs, lack of proper caching strategies, CDNs, minification of CSS and Javascript play a much larger role in the big picture. Only when you've extracted all the juice from all those lower-hanging fruits must you start to blame the language or framework used to developer a website IMHO.
- bhauer 13y ago
  I'm not talking about a client-side performance issue. Those are tangential matters. We should all endeavor to comply with best practices for delivery of static assets to improve client-side performance including minification, strategic concatenation, use of content delivery networks, caching strategies, and so on. Let's put that aside, however. What I am talking about is a real request to a non-cachable dynamic page or service endpoint. It's the frustration of "Waiting for [servername]..." status bar messages. It's the frustration of looking at the Network panel in Chrome or Firebug and realizing that it's just spinning waiting for the first byte of the response. It might be a server-templated HTML page. It might be an API call fetching some JSON. But the sorry state even in 2013 is that a disturbingly large number of sites will spend hundreds of milliseconds, and in some cases full seconds to respond to dynamic requests that ultimately deliver quite trivial response payloads. I for one want developers to stop sweeping these performance failures under the rug by deflecting server-side performance failure with client-side cover.
drdaeman 13y ago
I believe, in most cases of those milliseconds amount to network and database/storage latency, not site code's performance. So it's just insignificant (performance-wise) whenever you write site in carefully optimized C or just write some Ruby magic that performs, say, 100x slower. 1ns vs 100ns is insignificant when it's your database that responds in 300ms.
- TylerE 13y ago
  You couldn't be more wrong. PHP and Ruby page generation times can easily exceed 1000ms if the programmer isn't careful. Nanoseconds is just rubbish. Even the fastest template engines typically take on the order of a few ms.