5 ms·

Moving to Go

82 points by markokocic 14y ago

lukeholder 14y ago
How is this continuing to rise on HN while the site is down the whole time? Just the title?
- nexneo 14y ago
  Yeah. It may not be about "Go" people thinking.
- heretohelp 14y ago
  http://webcache.googleusercontent.com/search?q=cache:3vDKN5Ah7o8J:blog.toggl.com/+&cd=2&hl=en&ct=clnk&gl=us http://webcache.googleusercontent.com/search?q=cache:3vDKN5A...
- EwanToo 14y ago
  I think it says a lot about current voting on here...
- cageface 14y ago
  A lot of things make onto the front page these days thanks to rings of vote stuffers.
  - cageface 14y ago
    Downvote if you like, but it's true, although perhaps not for this particular article.
    - markokocic 14y ago
      I don't know if Go or Toggl fans rallied and upvoted this article, but I don't have anything with that. That being said, I'd like to see if HN could provide some kind of fraud protection for upvotes/downvotes. I know that, for example, ad providers have some kind of algorithm detecting if the click is valid. Does anyone know of something like that in use in some of the community recommendation sites like HN? As it is now, it would be fairly easy to game HN for karma or marketing reasons. All it takes for an article to take off is less than 10 votes at the right moment.
      - espeed 14y ago
        HN has a ring detection algorithm.
        markokocic 14y ago
        Have more info to share? I wasn't able to find anything related to it on HN.
        dchuk 14y ago
        Most spam protection technologies are not discussed publicly as that would defeat the purpose
        deleted 14y ago
        [deleted]
- eckyptang 14y ago
  Because we're clever enough to view the cached version: http://webcache.googleusercontent.com/search?q=cache:3vDKN5Ah7o8J:blog.toggl.com/&hl=en&client=firefox-a&gl=uk&prmd=imvns&strip=1 http://webcache.googleusercontent.com/search?q=cache:3vDKN5A...
- markokocic 14y 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 ;)
  - lukeholder 14y ago
    The page is still not live.
    - louhike 14y ago
      You should maybe try to empty your cache as I can visit the page.
heretohelp 14y ago
Apparently they should move their blog to Go. Site's been down a lot, and I'm not fond of the campaign tracking stuff in the original URL, so here's the text: Moving to Go Posted on September 19, 2012 [by Alari?] During the last few months we have systematically improved both front-end user interface, and backend server code for the Toggl main time tracking page. It was motivated by the fact that we found it increasingly hard to cope with the steady growth of users and traffic, resulting in serious slowdowns of the system and in some cases even downtime. The majority of Toggl program code originated from the time when our user base was 10x smaller, so the system needed a major overhaul. There were also several functional shortcomings, for example entries were not refreshed automatically when changes were made elsewhere (e.g. mobile phone). Also we had no offline support of any kind on the web. Our situation in May this year It took 5-7 seconds to load a time tracking page in Toggl, quite often even up to 20 seconds and more. Most of the time was spent by the server to compile the necessary dataset of time entries, but also related data. The whole backend was based on Ruby on Rails, we used Ruby 1.8 at that time. User interface could not be used offline. Javascript code was bloated and contained a lot of unnecessary code (for example we had multiple date parsing/formatting libraries, etc) The loading and parsing of Javascript started to block our UI because of its size. Backend API calls were not optimized for the purpose, we requested too much data which strained both the database and bandwidth. New implementation After careful consideration we decided to re-use the offline-enabled time tracking code that is also used in our mobile apps and in Toggl Desktop, only retaining the visual of the existing time tracking page. So basically we decided to replace the whole backend code of that page. We had run some experiments with the Go programming language (http://golang.org/ http://golang.org/) before, and decided that we should re-implement some parts of our backend with this new platform. So far, it has paid off, as the development process was fast, and deployment surprisingly simple. The resulting code is a big improvement in terms of speed. We’ll continue to replace our backend code with Go. Secondly we implemented a Redis-backed (http://redis.io/ http://redis.io/) WebSocket server in Go to enable realtime synchronization between different Toggl clients – so your time entries, projects etc. would be updated automatically if you use Toggl on multiple devices. Thirdly we added HTML5 manifest and local storage to support offline usage of Toggl. This served also as the speed enabler. Offline was already implemented with our mobile interface m.toggl.com, so we reused a lot of that. In frontend Javascript code, we’re moving to Backbone.js (http://backbonejs.org/ http://backbonejs.org/). As the amount of Javascript code is increasing fast, this library enables to structure it better. For parsing, formatting and manipulating dates in Javascript, we’ve moved to Moment.js (http://momentjs.com/ http://momentjs.com/) It has simplified our code a lot. Following Google Page Speed (https://developers.google.com/speed/pagespeed/ https://developers.google.com/speed/pagespeed/) tips, we’ve started to use a Javascript loader to reduce resource blocking. At the moment, we’re using LABjs (http://labjs.com/ http://labjs.com/). Another update we made was to upgrade to Ruby 1.9. The upgrade gave the system another speed boost. Finally we spent time measuring HTML/CSS/JS load times and optimizing the milliseconds there. Our goal was to get the load time to under 1 second, or even faster. While the tracking page now loads faster, it’s still a work in progress as we’re doing too many API requests when loading the timer. Also, we’re still using Javascript libraries that are quite bloated – for example for the sidebar report charts. We still like Ruby on Rails a lot, and at the moment, will continue using it for serving user interface. Go will be used together with PostgreSQL and Redis for backend data crunching and efficient API calls. Incremental launch These changes encompassed several risks, as there were a lot of potential critical bugs associated. That’s why we decided to roll the update out incrementally. We started in early July, and slowly and cautiously added new users until we had approximately 10% using it. This amount of users gave us enough feedback on system stability and bugs. After 4 weeks it had stabilized enough to start rolling it out more aggressively. By now all users have been converted to the new version. As mentioned before, speed is an important feature in Toggl. Robustness and speed is something you, our users, keep telling us if we ask what are the most important things you need from Toggl. We have gained some valuable lessons with the latest upgrade, and will continue implementing those also in other parts of Toggl.
toggl 14y ago
Sorry, our self-hosted Wordpress blog did not scale with the traffic. Blog is now relocated, works better.
- sophiabatka464 14y ago
  Barfi 2012 streaming free movie download http://freemoviesite24.blogspot.com/2012/09/barfi-2012-streaming-free-movie-download.html http://freemoviesite24.blogspot.com/2012/09/barfi-2012-strea...
- avbor 14y 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 14y 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 14y 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.
timmillwood 14y ago
Why would anyone use Go?
- pjmlp 14y 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 14y ago
    Or you could use a caching strategy, like enabling cache in apache.
    - pjmlp 14y ago
      That would work as well, yes.
- acuozzo 14y ago
  > Why would anyone use Go? Why would anyone senselessly troll HN?
  - timmillwood 14y 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.
nagnatron 14y 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 14y 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.
  - deleted 14y ago
    [deleted]
  - nagnatron 14y 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.
    - hkarthik 14y ago
      This is very cyclical. We're in the honeymoon period with some of these technologies. Two years ago you saw a lot of posts proclaiming that NodeJS and MongoDB were fantastic, world changing technologies. Now you see a lot of posts saying "We're switching from MongoDB to Postgres/Riak because of X, Y, and Z". I suspect we'll start seeing similar posts about Node.js very soon. No telling what will happen with Go, but just enjoy the honeymoon period for what it is and stay tuned to find out what happens later.
- rickdale 14y 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 14y 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_ 14y 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 14y 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

82 points by markokocic 14y ago

lukeholder 14y ago

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

nexneo 14y ago
Yeah. It may not be about "Go" people thinking.
heretohelp 14y ago
http://webcache.googleusercontent.com/search?q=cache:3vDKN5Ah7o8J:blog.toggl.com/+&cd=2&hl=en&ct=clnk&gl=us http://webcache.googleusercontent.com/search?q=cache:3vDKN5A...
EwanToo 14y ago
I think it says a lot about current voting on here...
cageface 14y ago
A lot of things make onto the front page these days thanks to rings of vote stuffers.
- cageface 14y ago
  Downvote if you like, but it's true, although perhaps not for this particular article.
  - markokocic 14y ago
    I don't know if Go or Toggl fans rallied and upvoted this article, but I don't have anything with that. That being said, I'd like to see if HN could provide some kind of fraud protection for upvotes/downvotes. I know that, for example, ad providers have some kind of algorithm detecting if the click is valid. Does anyone know of something like that in use in some of the community recommendation sites like HN? As it is now, it would be fairly easy to game HN for karma or marketing reasons. All it takes for an article to take off is less than 10 votes at the right moment.
    - espeed 14y ago
      HN has a ring detection algorithm.
      - markokocic 14y ago
        Have more info to share? I wasn't able to find anything related to it on HN.
        dchuk 14y ago
        Most spam protection technologies are not discussed publicly as that would defeat the purpose
      - deleted 14y ago
        [deleted]
eckyptang 14y ago
Because we're clever enough to view the cached version: http://webcache.googleusercontent.com/search?q=cache:3vDKN5Ah7o8J:blog.toggl.com/&hl=en&client=firefox-a&gl=uk&prmd=imvns&strip=1 http://webcache.googleusercontent.com/search?q=cache:3vDKN5A...
markokocic 14y 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 ;)
- lukeholder 14y ago
  The page is still not live.
  - louhike 14y ago
    You should maybe try to empty your cache as I can visit the page.

heretohelp 14y ago

Apparently they should move their blog to Go. Site's been down a lot, and I'm not fond of the campaign tracking stuff in the original URL, so here's the text: Moving to Go Posted on September 19, 2012 [by Alari?] During the last few months we have systematically improved both front-end user interface, and backend server code for the Toggl main time tracking page. It was motivated by the fact that we found it increasingly hard to cope with the steady growth of users and traffic, resulting in serious slowdowns of the system and in some cases even downtime. The majority of Toggl program code originated from the time when our user base was 10x smaller, so the system needed a major overhaul. There were also several functional shortcomings, for example entries were not refreshed automatically when changes were made elsewhere (e.g. mobile phone). Also we had no offline support of any kind on the web. Our situation in May this year It took 5-7 seconds to load a time tracking page in Toggl, quite often even up to 20 seconds and more. Most of the time was spent by the server to compile the necessary dataset of time entries, but also related data. The whole backend was based on Ruby on Rails, we used Ruby 1.8 at that time. User interface could not be used offline. Javascript code was bloated and contained a lot of unnecessary code (for example we had multiple date parsing/formatting libraries, etc) The loading and parsing of Javascript started to block our UI because of its size. Backend API calls were not optimized for the purpose, we requested too much data which strained both the database and bandwidth. New implementation After careful consideration we decided to re-use the offline-enabled time tracking code that is also used in our mobile apps and in Toggl Desktop, only retaining the visual of the existing time tracking page. So basically we decided to replace the whole backend code of that page. We had run some experiments with the Go programming language (http://golang.org/ http://golang.org/) before, and decided that we should re-implement some parts of our backend with this new platform. So far, it has paid off, as the development process was fast, and deployment surprisingly simple. The resulting code is a big improvement in terms of speed. We’ll continue to replace our backend code with Go. Secondly we implemented a Redis-backed (http://redis.io/ http://redis.io/) WebSocket server in Go to enable realtime synchronization between different Toggl clients – so your time entries, projects etc. would be updated automatically if you use Toggl on multiple devices. Thirdly we added HTML5 manifest and local storage to support offline usage of Toggl. This served also as the speed enabler. Offline was already implemented with our mobile interface m.toggl.com, so we reused a lot of that. In frontend Javascript code, we’re moving to Backbone.js (http://backbonejs.org/ http://backbonejs.org/). As the amount of Javascript code is increasing fast, this library enables to structure it better. For parsing, formatting and manipulating dates in Javascript, we’ve moved to Moment.js (http://momentjs.com/ http://momentjs.com/) It has simplified our code a lot. Following Google Page Speed (https://developers.google.com/speed/pagespeed/ https://developers.google.com/speed/pagespeed/) tips, we’ve started to use a Javascript loader to reduce resource blocking. At the moment, we’re using LABjs (http://labjs.com/ http://labjs.com/). Another update we made was to upgrade to Ruby 1.9. The upgrade gave the system another speed boost. Finally we spent time measuring HTML/CSS/JS load times and optimizing the milliseconds there. Our goal was to get the load time to under 1 second, or even faster. While the tracking page now loads faster, it’s still a work in progress as we’re doing too many API requests when loading the timer. Also, we’re still using Javascript libraries that are quite bloated – for example for the sidebar report charts. We still like Ruby on Rails a lot, and at the moment, will continue using it for serving user interface. Go will be used together with PostgreSQL and Redis for backend data crunching and efficient API calls. Incremental launch These changes encompassed several risks, as there were a lot of potential critical bugs associated. That’s why we decided to roll the update out incrementally. We started in early July, and slowly and cautiously added new users until we had approximately 10% using it. This amount of users gave us enough feedback on system stability and bugs. After 4 weeks it had stabilized enough to start rolling it out more aggressively. By now all users have been converted to the new version. As mentioned before, speed is an important feature in Toggl. Robustness and speed is something you, our users, keep telling us if we ask what are the most important things you need from Toggl. We have gained some valuable lessons with the latest upgrade, and will continue implementing those also in other parts of Toggl.

toggl 14y ago

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

sophiabatka464 14y ago
Barfi 2012 streaming free movie download http://freemoviesite24.blogspot.com/2012/09/barfi-2012-streaming-free-movie-download.html http://freemoviesite24.blogspot.com/2012/09/barfi-2012-strea...
avbor 14y 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 14y 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 14y 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.

timmillwood 14y ago

Why would anyone use Go?

pjmlp 14y 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 14y ago
  Or you could use a caching strategy, like enabling cache in apache.
  - pjmlp 14y ago
    That would work as well, yes.
acuozzo 14y ago
> Why would anyone use Go? Why would anyone senselessly troll HN?
- timmillwood 14y 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.

nagnatron 14y 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 14y 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.
- deleted 14y ago
  [deleted]
- nagnatron 14y 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.
  - hkarthik 14y ago
    This is very cyclical. We're in the honeymoon period with some of these technologies. Two years ago you saw a lot of posts proclaiming that NodeJS and MongoDB were fantastic, world changing technologies. Now you see a lot of posts saying "We're switching from MongoDB to Postgres/Riak because of X, Y, and Z". I suspect we'll start seeing similar posts about Node.js very soon. No telling what will happen with Go, but just enjoy the honeymoon period for what it is and stay tuned to find out what happens later.
rickdale 14y 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 14y 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_ 14y 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 14y 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?