

I rewrote my blog in Go - hermanschaaf
http://www.ironzebra.com/code/103/i-rewrote-my-blog-in-go

======
jbail
_" I am now loading less static assets. I removed the Disqus comments and the
many many lines of CSS from the old site and replaced it with only a couple of
lines of CSS alongside a CDN-hosted copy of Twitter Bootstrap. Finally, the Go
site is deployed to a free instance of Heroku and the MongoDB hosted on a
developer version of Mongolab, while the old Django site was hosted on a
Webfaction shared server."_

So...the Python/Django to Go/Revel comparison is basically worthless then?
These are huge changes that completely invalidate any speed improvement the
author is trying to prove are a result of using Go.

A lot of upvotes for an article with an obviously flawed conclusion.

~~~
asdfologist
Did you read the next sentence?

"All these things influence the validity of a direct speed comparison between
the two versions, but the speed improvement is nevertheless too overwhelming
to attribute only to these small changes. And in fact, many of these changes
might even have negatively impacted the speed of the new version in exchange
for saving on the monthly bills."

~~~
ebbv
That assertion isn't backed up with data, though.

Without showing how many seconds were spent loading Disqus, we don't know how
much of the load time improvement was based on eliminating Disqus vs. the
switch to Go.

Based on experience I'm guessing the lion's share of the gain is due to
eliminating Disqus.

~~~
bdcravens
Isn't Disqus loaded client-side? If so, it's not comparing to Go as much as
rendering comments server-side, which you'd see performance increases with PHP
or Rails as well.

------
onion2k
While rewriting things in different language is fun (and fun is a _great_
reason to do stuff), the speed of delivering what is ostensibly static content
is a solved problem. This was completely unnecessary. Bake the blog post into
static HTML and tune up Nginx to shove it down the wires as fast as possible.
Stick it on an CDN somewhere if it's important. Then move on to a problem that
doesn't already have an optimal solution, and share the solution if you're
nice. That's how _everything_ should be done.

~~~
vidarh
Even if you don't bake it into static HTML, this is a solved problem.

I serve my homepage/blog off a small Sinatra (Ruby) app, and while that's not
slow, mostly because it caches every single page in memory permanently (my
written content grows much slower in size than available memory on dirty cheap
servers) just because it's simple to do and makes my testing easy (it does
stat to check for modifications), there's pretty much no excuse not to have a
CDN or a fast server like Nginx with caching turned on in front of app servers
these days, which makes the backend performance pretty much irrelevant for
cases where you don't have content that needs to be dynamically generated for
a huge percentage of requests.

~~~
patrickdavey
I don't suppose you've put that repo anywhere we can have a look at? :)

------
hamoid
"I removed the Disqus comments"

Wouldn't that by itself be enough to account for the download time
differences?

~~~
carlosrg
Yes:

"I removed the Disqus comments and the many many lines of CSS from the old
site and replaced it with only a couple of lines of CSS alongside a CDN-hosted
copy of Twitter Bootstrap. Finally, the Go site is deployed to a free instance
of Heroku and the MongoDB hosted on a developer version of Mongolab, while the
old Django site was hosted on a Webfaction shared server. All these things
influence the validity of a direct speed comparison between the two versions"

Indeed, all these things _invalidate_ the direct speed comparison between the
two versions.

~~~
ceol
I don't see how he can say, "Well I moved stuff to a CDN and changed hosts off
of a shared server and greatly reduced my CSS file size, but surely it was the
fact I changed languages that caused my page times to increase!"

No, author, Go had very little to do with your page load times. Both Go and
Django are going to serve a simple blog at the same speeds.

------
islon
It seems that people on hn just fell in love with go. So many new articles
lately. It's like the node.js fever all over again.

~~~
pjmlp
Or Ruby on Rails, Arc, or whatever is the flavour of the year.

Additionally it is funny to see the usual comparisons of young developers
discovering execution and compilation speeds already possible in 16 bit
systems.

~~~
vidarh
I was surprised at how amazed people on one of the recent Go threads was with
Go compilation speeds, given that _gcc_ delivers similar compilation speeds
for C code per line of code for me on my old, slow home server.

As for 16 bit systems, I'd love to see a comparison with the Turbo Pascal
compiler, for example, on modern hardware. Maybe my memory is deceiving me and
the program sizes just weren't comparable, but it sure did seem like it was
just _flying_ on a 4.77MHz 8086 based PC. It'd be an interesting comparison.

Especially given I remember how frustrated I was with a lot of other
contemporary compilers (whether for C, Pascal, dBase or others). The only
other compiler I remember fondly for being fast was the AmigaE compiler (by
Wouter van Oortsmerssen, the strlen.com / Cube engine guy, who I see is now
working at Google on Android gaming - nothing but good can possibly come of
that)

~~~
robfig
Is this true?

I'm not sure about C, but it's definitely the case that Go compiles magnitudes
faster than C++, for any reasonable sized project. For example, the ~200k
lines of Go standard library compiles in about 14 seconds on my workstation,
while random C++ libraries frequently take much longer (just my anecdotal
impression from waiting on "brew install").

~~~
pjmlp
C++ compiles pretty slow due to templates being in the header files, and the
need to re-parse them in every compilation unit.

Also the language is quite complex and requires multiple analyses at parse
time to decide what the developer is really trying to do.

C code can be compiled fast if not many optimizations are being made. For
example the Tiny C compiler was compiling the Linux kernel around 15s in 2004,
not sure about which modules were configured though.

Any proper compiler for a language with modules should anyway be able to beat
C and C++ compilers hands down.

~~~
ternaryoperator
The slowness of C++ compilation is more complicated than you imply. Walter
Bright details the causes here:
[http://www.drdobbs.com/228701711](http://www.drdobbs.com/228701711)

~~~
pjmlp
I know, but that is why Walter's information is an article and not a plain
simple post. There is too much compiler related information to discuss.

------
lbarrow
How did you achieve a 16 second response time for your _blog_? What the heck
were you doing?

~~~
BetaCygni
Yeah, it's not surprising that any change would make it faster. Plot twist: OP
was previously typing the server response BY HAND.

~~~
reeses
Those cookies can be a real pain if you make a typo.

------
learc83
I built a small site in Go and I didn't really see the need to use a
framework. Here's what I did for routes.

    
    
      func getRoutes() map[string]customHndlrFnc {
    	  r := make(map[string]customHndlrFnc)
    
    	  //routes
    	  r["/route_to_url"] = handler 
    	  r["/route_to_url2"] = handler2
    
    	  return r
      }
    
      for key, value := range getRoutes() {
    	http.HandleFunc(key, handlerWrapper(value))
      }
    

All of my routes for this sample were get requests but it could easily be
extended.

~~~
james4k
Why do that versus:

    
    
      http.HandleFunc("/route_to_url", handlerWrapper(handler))
      http.HandleFunc("/route_to_url2", handlerWrapper(handler2))
    

Is the map used elsewhere?

------
ChikkaChiChi
After playing around with an Arduino in my spare time, I've realized how
important it is to start thinking in multi-threaded concepts in programming.
Nothing makes a better example than watching delay(); physical prevent your
sketch from taking the next step.

Golang (Still can't believe Google would release a language so piss poor for
SEO) WILL be the language I pursue when I start down this path, but right now
I don't have any projects that force me to start rebuilding my libraries from
scratch.

~~~
bad_user
Save yourself the pain and go with Scala and the JVM ... mature platform with
battle tested GCs, all the libraries and concurrency idioms you'll ever need
and a modern FP language designed for scale.

~~~
TylerE
Only if you don't mind paying approximately an order of magnitude penalty in
RAM usage, which has long been an achilles heel of JVM languages.

[http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...](http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=scala&lang2=go&data=u64)

~~~
dubbledidu
It uses exactly as much memory as you specify. It would be pretty stupid to
have plenty of RAM and NOT using it. With enough memory GC becomes essentially
free, by not having to do any work.

~~~
TylerE
Nonsense. I'm talking about the SAME data taking more memory to represent.
Plus, all things being equal a larger memory space will take more time to GC,
and GCs become longer, not shorter.

The JVM does things suboptimally in a number of ways. Object memory overhead
is relatively high - typically 8 or 16 bytes per object, strings as UTF-16 (vs
Go's UTF-8), etc. It really adds up, and funtional languages tend to churn
lots of GC.

~~~
pcwalton
> strings as UTF-16 (vs Go's UTF-8), etc.

Strings aren't traced, so that has no impact on GC time.

~~~
TylerE
It does, however, impact memory usage quite substantially if your data is
string-heavy, which most web-apps are.

------
rartichoke
I'm not sure why you wouldn't cache anything. It doesn't matter if x is faster
than y. If both were cached the difference might be milliseconds and in the
real world that is what will happen.

------
cocoflunchy
OT but please don't put the solutions for Project Euler problems on GitHub, it
is directly against the rules
([http://projecteuler.net/about](http://projecteuler.net/about), section "I
learned so much solving problem XXX so is it okay to publish my solution
elsewhere?").

You can put the solutions in the dedicated thread on the site though if you
want to share :)

~~~
jcurbo
First, just a note, you can only see that section if you're logged in.

Second, I disagree that it is 'directly against the rules' \- no where there
does it say specifically that you must not post solutions elsewhere. I think
the intent is there - but if someone simply cribs off another answer
somewhere, they're not really learning anyway and are really robbing
themselves. Project Euler is altruistic anyway and there's really no
'advantage' to stealing answers. (I guess someone could show off their
progress, but I don't think that's much of an advantage, since they aren't
really learning anything)

I have learned quite a bit from looking at Project Euler answers from others
and am glad they published their solutions. For example, there are many
different ways to do #2 in Haskell and it is enlightening to see how they
work.

~~~
onuras
let me guess, you only managed to solve "publicly available" problems right?

~~~
jcurbo
In the interests of full disclosure, I have only answered 3 problems on
Project Euler, and I did them all myself, because I have the willpower to
_not_ look at other answers before creating my own. (I have the same username
there:
[http://projecteuler.net/profile/jcurbo.png](http://projecteuler.net/profile/jcurbo.png))
Anyone looking to learn something and not just check boxes will do the work
and exert the same willpower to ignore solutions already out there.

The core of this problem exists in education at all levels; the learner must
be coerced or convinced that it is in their best interest to actually learn
the content rather than cheat.

------
Jgrubb
For the record, this is the same graph after moving my Drupal based blog from
Media Temple to Linode. Nothing else changed. So yes, hosting can make that
magnitude of a difference.
[http://i.imgur.com/8esmvJS.png](http://i.imgur.com/8esmvJS.png)

------
mcantrell
You forgot to provide an RSS feed of your blog posts.

------
OhHeyItsE
~15 secs to load a blog post??? Sorry - that's not a problem w/ Django.
Something else goofy going on here. Whether or not Go/Revel is ninjarockstar
faster than Python/Django, I don't think this is the benchmark to prove it.

------
philip1209
Source code:

[https://github.com/hermanschaaf/ironzebra](https://github.com/hermanschaaf/ironzebra)

------
jwcrux
|and I decided to give it a go.

Never gets old.

------
vph
I think the comparison is a little misleading as the author admitted that the
newer version is slimmer and tighter. Django is heavy. It'd be interesting if
somehow the author could have used Bottle (Python) and compare it to Revel
(Go).

------
bdcravens
Anytime you move rendering off the client (Disqus) you'll see performance
increases. Everyone is focused on server-side speed, though most of the load
time is network latency and DOM rendering.

------
ukandy
Heroku, MongoDB, Go, Revel, Bootstrap, with a sprinkling of overkill..

~~~
bulte-rs
Your absolutely right, this article sucks... No mention of mythical horselike
one-horned creature whatsoever. :)

------
boromi
How many Go articles do we need a day? Google must be desperate.

Tomorrow: How I rewrote my bedroom and kitchen using Go and saved lives.

