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.

>"All these things influence the validity of a direct speed comparison between the two versions"

I hope the author wasn't trying to say, "Go is better always forever." I read it more as, "hey I rebuilt my site in Go, and it's fast." Go has potential - I'll be excited to see what people come up with.

Why not just measure/compare the response time of the single request that fetches the (presumably) HTML response, and leave all of the ancillary asset delivery and script execution as an aside? If this is about Go versus Python, all I care about is the portion where those are actually involved. And it would be easy to see in the network panel of the developer tools window in Chrome or Firefox.

Of course, the hosting environment also changed, so... there's that still.

"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."

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.

However, in the browser, they felt like the same site. The 199ms head start resulted in only 50-75ms difference in the browser. Anyway, it turned our focus from backend work to CSS and image improvements.

If your back-end is slow, just cache it and forget about it. Front-end is almost always the bottleneck (the exceptions to this rule being near-real-time dynamic sites like New Relic or GoSquared).

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.

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

"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.

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.

If so, disqus loading is 'postponed' to after page loading? Or is it taken into account?

I have Disqus on my Jekyll/Octopress blog and still get millisecond loads.

Still, Disqus has basically a no/low-impact

Disqus loads almost entirely async.

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

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)

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").

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.

Other languages with module systems also compile quite fast.

It would be interesting to see a table of compilation speed comparisons of compilers for languages with module systems for applications of an considerable size.

16 seconds is crazy slow, a sure sign that previously Something Wasn't Right.

  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))
  }

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

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.

http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...

http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...

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.

One reason for why JVM apps appear to consume so much memory is because the JVM allocates more memory than it needs. It does so because the garbage collectors are generational and compacting (well, CMS is non-compacting, but when the memory gets too fragmented, the VM does fallback to a stop-the-world compaction of memory). In a server context the JVM also does not release the free memory it has to the operating system, because allocating that memory in the first place is expensive and so it keeps it for later usage ... the result is that memory allocation on top of the JVM is as efficient as stack allocation, since all the JVM does is to increment a pointer, and deallocation of short-lived objects is nearly as innexpensive as stack unwinding, since the GC is generational and deallocates stuff in bulk. These capabilities come at a cost, as the GC also needs memory to move things around, but it's also memory well spent (e.g. Firefox has been plagued by memory fragmentation for years).

Speaking of Golang, it has some of the shittiest GCs in existence ... non-generational, non-compacting, non-concurrent and "mostly precise". Of course, it used to be fully conservative, which meant you could easily end up with really nasty memory leaks on 32bits systems, because the GC wasn't able to make a difference between Ints and pointers.

The only thing saving Go is the ability to work in many cases with the stack, alleviating the stress that the GC faces, but this low-level capability will also prevent it from having a good GC anytime soon, like the JVM has had for years.

And really, in terms of memory usage, you should see how the JVM's CMS or G1 behaves in production, as it makes all the difference. Our web-service (written in Scala) that's being hit by more than 30,000 requests per second that must be served in under 100ms per request, was at some point hosted on Heroku, using only 8 instances, instances which have less than 400 MB of usable RAM. It was absolutely superb seeing it in action, as the processes themselves were not exceeding 200 MB of real usage - Heroku even told us that we are costing them more than we are paying them.

So yeah, you can talk bullshit about strings being UTF-16, but the real wold disagrees.

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

There will always be better tools, you just can't beat yourself up trying to pre-optimize for each one per project.

- You can't find people to work on it - Unbounded complexity, type-masturbation - Slow compilation (you need a better computer/SSD) - Might as well use Java, the tooling for Java is great

Do you know if those are still true?

Scala is many things, but that is not one of them. Scala is an OO language with some FP influence.

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

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.

    > I learned so much solving problem XXX so is it okay to publish 
    > my solution elsewhere?

    It appears that you have answered your own question. 
    There is nothing quite like that "Aha!" moment when you finally
    beat a problem which you have been working on for some time.
    It is often through the best of intentions in wishing to share our 
    insights so that others can enjoy that moment too. Sadly, 
    however, that will not be the case for your readers. Real 
    learning is an active process and seeing how it is done is a 
    long way from experiencing that epiphany of discovery. 
    Please do not deny others what you have so richly valued yourself.

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.

Seriously the web is big, github is big, Euler is pretty big. Overlap is unavoidable. The [thing,] I'd think would be to ask for no direct linkages. "Go ahead, share your prime factor code, but for goodness sake [do] not document it as a 'Euler Problem.'"

https://github.com/hermanschaaf/ironzebra

Never gets old.

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