Interesting read. I'm porting a python library to golang currently as well. I'm noticing some pretty awesome performance gains but it might be interesting to note that those gains we not from concurrency ... instead by limiting what regular expressions are allowed to do in go. The package I'm porting used a few lookahead assertions (http://www.regular-expressions.info/lookaround.html). This was a shortcut in the tokenization process and resulted in rather slow processing. Manually writing a replacement for the lookahead regular expressions vastly improved the processing speed and also the readability of the code.
What's funny is in the beginning I saw it as a huge negative and left the experience thinking it was a brilliant restriction. In the particular case of lookaheads, less is more.
That's interesting. The main advantage I've seen in go versus dynamic languages for web apps is in the memory usage - I've seen an order of magnitude difference in some cases.
Interesting read. I'm porting a python library to golang currently as well. I'm noticing some pretty awesome performance gains but it might be interesting to note that those gains we not from concurrency ... instead by limiting what regular expressions are allowed to do in go. The package I'm porting used a few lookahead assertions (http://www.regular-expressions.info/lookaround.html). This was a shortcut in the tokenization process and resulted in rather slow processing. Manually writing a replacement for the lookahead regular expressions vastly improved the processing speed and also the readability of the code.
What's funny is in the beginning I saw it as a huge negative and left the experience thinking it was a brilliant restriction. In the particular case of lookaheads, less is more.
That's interesting. The main advantage I've seen in go versus dynamic languages for web apps is in the memory usage - I've seen an order of magnitude difference in some cases.