diff --git a/readme.md b/readme.md
index f98e09d..a124479 100644
--- a/readme.md
+++ b/readme.md
@@ -9,16 +9,16 @@
 
 When In Doubt, Use Channels
 ----------------------------
-Despite Go's channels being significantly slower than the Disruptor, channels should still be considered the best and most desirable choice for the vast majority of all use cases. The Disruptor's target use case us ultra-low latency environments where application response times are measured in nanoseconds and where stable, consistent latency is paramount.
+Despite Go's channels being significantly slower than the Disruptor, channels should still be considered the best and most desirable choice for the vast majority of all use cases. The Disruptor's target use case is ultra-low latency environments where application response times are measured in nanoseconds and where stable, consistent latency is paramount.
 
 Pre-Alpha
 ---------
-This code is pre-Alpha stage and is not supported or recommended for production environments. That being said, it has been run non-stop for days without exposing any race conditions. Also, it does not yet contain any unit tests and is meant to be spike code to serve as a proof of concept that the Disruptor is, in fact possible, on the Go runtime despite some of the limits imposed by the Go memory model. The goal is to have an alpha release by mid June 2014 and a series of beta releases each month thereafter until we are satisfied. Following this a release will be created and supported moving forward.
+This code is pre-Alpha stage and is not supported or recommended for production environments. That being said, it has been run non-stop for days without exposing any race conditions. Also, it does not yet contain any unit tests and is meant to be spike code to serve as a proof of concept that the Disruptor is, in fact possible, on the Go runtime despite some of the limits imposed by the Go memory model. The goal is to have an alpha release by mid June 2014 and a series of beta releases each month thereafter until we are satisfied. Following this, a release will be created and supported moving forward.
 
-We are very interested to receive feedback on this project and how performance can be improved using subtle techniques such as additional cache line padding, utilizing a pointer vs a struct in a given location, replacing less optimal techniques with more optimal ones, especially in the performance critical paths of `Next` in the `Sequencer` and `Process` in the `Reader`
+We are very interested to receive feedback on this project and how performance can be improved using subtle techniques such as additional cache line padding, utilizing a pointer vs a struct in a given location, replacing less optimal techniques with more optimal ones, especially in the performance critical paths of `Reserve`/`Commit` in the various `Writer`s and `Receive`/`Commit` in the `Reader`
 
 Caveats
 -------
-One last caveat worth noting.  In the Java-based Disruptor implementation, a ring buffer is created,  preallocated, and prepopulated with instances of the class which serve as the message type to be transferred between threads.  Because Go lacks generics, we have opted to not interact with ring buffers at all within the library code. This has the benefit of avoiding a required cast during the receipt of a given message from type `interface{}` to a concrete type.  It also means that it is the responsibility of the application developer to create and populate their particular ring buffer during application wireup.
+One last caveat worth noting.  In the Java-based Disruptor implementation, a ring buffer is created,  preallocated, and prepopulated with instances of the class which serve as the message type to be transferred between threads.  Because Go lacks generics, we have opted to not interact with ring buffers at all within the library code. This has the benefit of avoiding an unnecessary type conversion ("cast") during the receipt of a given message from type `interface{}` to a concrete type.  It also means that it is the responsibility of the application developer to create and populate their particular ring buffer during application wireup. Prepopulating the ring buffer at startup should ensure contiguous memory allocation for all items in the various ring buffer slots, whereas on-the-fly creation may introduce gaps in the memory allocation and subsequent CPU cache misses.
 
-The reference to the ring buffer can easily be scoped as a package-level variable. The reason for this is any given application should only be running very few Disruptor instances. The instances are designed to be created at startup and stopped during shutdown. They are not typically meant to be created “on the fly” and passed around. In any case, it is the responsibility of the application developer to manage references to the ring buffer instances such that the producer can push messages in and the consumers can receive messages out.
\ No newline at end of file
+The reference to the ring buffer can easily be scoped as a package-level variable. The reason for this is that any given application should have very few Disruptor instances. The instances are designed to be created at startup and stopped during shutdown. They are not typically meant to be created adhoc and passed around. In any case, it is the responsibility of the application developer to manage references to the ring buffer instances such that the producer can push messages in and the consumers can receive messages out.
\ No newline at end of file