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.
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.
"Job position -- Permanent / Freelance - Remote work is NOT possible." I'm slightly confused by the title of this gohacker post.