Fix a few more typos, change date.

Plan to publish tomorrow.

Author: dmitshur

_posts/blog/2015-09-27-surprises-in-gopherjs-performance.mdown renamed to _posts/blog/2015-09-28-surprises-in-gopherjs-performance.mdown

@@ -1,7 +1,7 @@
 ---
 layout: post
 title:  "Surprises in GopherJS Performance"
-date:   2015-09-27
+date:   2015-09-28
 author: Dmitri Shuralyov
 ---
 
@@ -100,14 +100,14 @@ So I looked at how [Go implements it](http://gotools.org/math#Pow).
 Pretty straightforward Go code.
 Now I knew GopherJS uses some JavaScript native APIs to implement parts of the standard library, so I checked how [it implemented `math.Pow`](https://github.com/gopherjs/gopherjs/blob/master/compiler/natives/math/math.go#L157).
 Aha! It's not the same code after all.
-GopherJS implements it by using [JavaScript's `Math` object](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math), so it translates to:
+GopherJS implements it by using [JavaScript's `Math` object](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math), so it translates to the following JavaScript code:
 
 ```JavaScript
 Math.pow(x, y)
 ```
 
 That's when it hit me.
-In this code, which was taken from a snippet that optimized for brevity and demonstration purposes rather than performance, `math.Pow` was being used with th first argument of -1, and the second argument are values 0, 1, 2, 3, etc., in sequence.
+In this code, which was taken from a snippet that optimized for brevity and demonstration purposes rather than performance, `math.Pow` was being used with the first argument of -1, and the second argument are values 0, 1, 2, 3, etc., in sequence.
 The output of that is an alternating sequence of 1, -1, 1, -1, 1, -1, etc.
 But using `math.Pow` for that is extremely inefficient, since it's meant to work with arbitrary inputs that are much harder to calculate.
 This can be trivially rewritten with an if statement.
@@ -190,7 +190,7 @@ total time taken is: 6.549s
 
 As expected, the GopherJS time did not change because it was a no-op, but the native Go performance has now caught up to the GopherJS version!
 
-Just to be sure, I wanted to see if 6.5 seconds was as fast as these 1 billion iterations could happen, even if you were to implement this in a low level language like C:
+Just to be sure, I wanted to see if 6.5 seconds was as fast as these 1 billion iterations could happen, even if you were to implement this in a low-level language like C:
 
 ```C
 #include <stdio.h>