8 ms·
I rewrote my blog in Go
- hamoid 13y ago"I removed the Disqus comments" Wouldn't that by itself be enough to account for the download time differences?
- carlosrg 13y agoYes: "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 13y agoI 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.
- chrismorgan 13y agoSure would be. I would expect that to have quite significantly more effect than any of the other changes, probably more than all the other changes put together.
- bulte-rs 13y agodoesn't disqus start replacing a specific div on a page ready event? If so, disqus loading is 'postponed' to after page loading? Or is it taken into account?
- minimaxir 13y agoDisqus replaces the div on page load, then loads the comments asynchronously. I have Disqus on my Jekyll/Octopress blog and still get millisecond loads.
- lbarrow 13y agoHow did you achieve a 16 second response time for your blog? What the heck were you doing?
- BetaCygni 13y agoYeah, it's not surprising that any change would make it faster. Plot twist: OP was previously typing the server response BY HAND.
- reeses 13y agoThose cookies can be a real pain if you make a typo.
- z92 13y agoOn my site I figured out abnormally high load time is caused by under powered mobile devices accessing the site.
- robfig 13y agoThat's a graph from webmaster tools. It may be that the Google Bot is hitting some pathological case with the Django (e.g. server-side sessions) or Disqus. I don't think he ever tested the latency directly.
- eterm 13y agoThis struck me as really weird too. I Was half expecting "and I removed FullHDLogo.BMP but it's probably Go!" toward the end. 16 seconds is crazy slow, a sure sign that previously Something Wasn't Right.
- jwcrux 13y ago|and I decided to give it a go. Never gets old.
- onion2k 13y agoWhile 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.
- sanderjd 13y agoCounterpoint: if you're learning a new language (or a new anything, really), it is much easier to reinvent than to invent. Just depends on what your goals are; whether you care more about the project you're working on or learning the thing you're learning.
- vidarh 13y agoEven 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 13y agoI don't suppose you've put that repo anywhere we can have a look at? :)
- psadauskas 13y agoIts his personal blog, what do you care what he writes it in? Maybe if it was 10 years ago and getting slashdotted was still a concern you could point out a better way, but if a free Heroku instance can keep up with HN traffic, then perhaps "doing it right" no longer matters. It seems the OP wanted to learn something and see if it could be done, so I'd say he achieved his goals. Getting all butthurt that he didn't achieve yours instead just seems silly.
- rartichoke 13y agoI'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.
- islon 13y agoIt 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 13y agoOr 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 13y agoI 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)
- pjmlp 13y agoThat was also my experience with Turbo Pascal, having used all MS-DOS versions and the 1.5 Windows version. 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.
- robfig 13y agoIs 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").
- mcantrell 13y agoYou forgot to provide an RSS feed of your blog posts.
- cocoflunchy 13y agoOT 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 :)
- jjindev 13y agoSo um, Euler owns "Largest prime factor" now? 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.'"
- jcurbo 13y agoFirst, 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.
- cocoflunchy 13y agoOk, it may not be "directly against the rules", but it is definitely dicouraged: > 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.
- ChikkaChiChi 13y agoAfter 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 13y agoSave 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.
- swah 13y agoScala problems (in the old days): - 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?
- dubbledidu 13y agoIt has gotten a lot better on all fronts.
- asdasf 13y ago>You can't find people to work on it If you felt that was a problem before, you will almost certainly still feel that way. >Unbounded complexity, type-masturbation No idea what you mean. >Slow compilation Still terrible. >Might as well use Java, the tooling for Java is great The tooling for java is better, but java the language is unbearable.
- TylerE 13y agoOnly 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?test=all&lang=scala&lang2=go&data=u64 http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...
- philip1209 13y agoSource code: https://github.com/hermanschaaf/ironzebra https://github.com/hermanschaaf/ironzebra
- jbail 13y ago"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 13y agoDid 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 13y agoThat 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 13y agoIsn'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.
- ignostic 13y agoAnd the very next sentence: >"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.
- vph 13y agoI 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).
- OhHeyItsE 13y ago~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.
- ukandy 13y agoHeroku, MongoDB, Go, Revel, Bootstrap, with a sprinkling of overkill..
- bulte-rs 13y agoYour absolutely right, this article sucks... No mention of mythical horselike one-horned creature whatsoever. :)
- learc83 13y agoI 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 13y agoWhy do that versus: http.HandleFunc("/route_to_url", handlerWrapper(handler)) http.HandleFunc("/route_to_url2", handlerWrapper(handler2)) Is the map used elsewhere?
- bdcravens 13y agoAnytime 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.
- Jgrubb 13y agoFor 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
- boromi 13y agoHow 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.