Moving to Go

http://blog.toggl.com/2012/09/moving-to-go/?utm_source=rss&utm_medium=rss&utm_campaign=moving-to-go

by markokocic • 14 years ago

82 31 14 years ago

blog.toggl.com

lukeholder2• 14 years ago

How is this continuing to rise on HN while the site is down the whole time? Just the title?

nexneo• 14 years ago

Yeah. It may not be about "Go" people thinking.

EwanToo• 14 years ago

I think it says a lot about current voting on here...

cageface2• 14 years ago

A lot of things make onto the front page these days thanks to rings of vote stuffers.

cageface2• 14 years ago

Downvote if you like, but it's true, although perhaps not for this particular article.

eckyptang• 14 years ago

Because we're clever enough to view the cached version:

http://webcache.googleusercontent.com/search?q=cache:3vDKN5A...

markokocic3• 14 years ago

The page works now. Seems like they switched to another (static?) version of the page. It looks quite different than it looked when I posted it.

Seems like their switch to Go didn't go so well if HN entry with 7 upvotes can break it ;)

lukeholder2• 14 years ago

The page is still not live.

toggl• 14 years ago

Sorry, our self-hosted Wordpress blog did not scale with the traffic. Blog is now relocated, works better.

avbor• 14 years ago

How big of an impact did each change you made have on the load? Say, would have just upgrading to Redis 1.9 reduce the load time by a few seconds?

ricardobeat• 14 years ago

I'm curious about the LABjs usage. In my own testing it ends up not having any significant impact in load times, sometimes it's even slower (same for other loaders). Just concatenating+minifying files has a huge effect already, the added complexity doesn't justify itself.

latchkey• 14 years ago

Agreed. I recently moved from LABjs to RequireJS. I regret ever going down the LJS route because it really doesn't encourage / enable you to modularize your JS. It was over complicated to get my head around RJS, but once I did, it really cleaned up a lot of my code and I'm super glad that I made the switch.

timmillwood2• 14 years ago

Why would anyone use Go?

pjmlp2• 14 years ago

If you look for the stream of articles that invaded HN in the last weeks, it is usually because someone implemented a web site in Ruby or Python and when it gets scalability problems all is heaven on earth with Go.

Of course if you're doing server side development already with more performant languages and runtimes, there is little incentive.

sunkencity• 14 years ago

Or you could use a caching strategy, like enabling cache in apache.

acuozzo• 14 years ago

> Why would anyone use Go?

Why would anyone senselessly troll HN?

timmillwood2• 14 years ago

It as a serious question. I spent a few minutes looking into Go and could find little reason for it. So wondered what the use case was.

nagnatron2• 14 years ago

What's going on with all the upvoting of technology enumeration posts on HN? Is it so interesting that someone uses a different language or library?

watty• 14 years ago

Yes, it is. I like to keep up with new technologies so I can better determine which language to choose for my next projects.

nagnatron2• 14 years ago

Let me help you out then:

    I switched from ruby to clojure because jvm is awesome
    and it's a lisp and I also use coffescript, backbone,
    requirejs and raphael. I've been using this stack for
    about a month and a half, it's awesome.

Does this help? How does this help you solve your problem? I'm going to go with "It doesn't". All of these posts boil down to that form.

The good ones start with: "Over the last year we deployed [insert stack] into production..". And then tell me what sucked because not everything is awesome.

rickdale• 14 years ago

I agree we do see a lot of these posts. But of all types the posts that are becoming popular, these are welcome.

larrywright• 14 years ago

I've got nothing against Go, but this smells fishy. 5-20 second load times on a page in Rails? That doesn't sound like an issue with the programming language, it sounds like an underpowered server, lack of proper caching, or an under-tuned database (or data model).

rb2k_• 14 years ago

The only interesting thing would be to see how much of a performance improvement each of the separate changes brought.

Phrases like "Most of the time was spent by the server to compile the necessary dataset of time entries, but also related data." seems to hint at:

a) missing profiling (was it database queries, actual computation, network I/O, disk I/O, ... ?)

b) architectural problems (a database schema that didn't perform, missing indexes, ...)

I'm sure Go is a nice language, but I don't see how Go could improve any of those besides maybe a more managable approach to parallel computations.

Given the amount of seemingly parallel changes that happened, it's pretty much impossible to determine what actually caused the improvement (at least with the information in this blogpost).

eranation• 14 years ago

A layman's question, I'm not a Ruby expert, but I was wondering - did you try jRuby and were not happy with the performance? or you already run on the JVM? My narrow notion on the Ruby world was that if it doesn't scale, put it on the JVM and you are done, am I living in fantasy land?

Moving to Go

Related Stories