freeformz · October 6, 2022 23:31 · Jul 26, 2017 · Jul 26, 2017 · Jul 6, 2015 · Apr 17, 2013
diff --git a/WhyILikeGo.md b/WhyILikeGo.md
@@ -1,4 +1,4 @@
-A slightly updated version of this doc is [here](http://icanhazdowntime.org/post/2013-02-09-why-i-like-go/).
+A slightly updated version of this doc is [here](http://icanhazdowntime.org/post/2013-02-09-why-i-like-go/) on my website.
 
 # Why I Like Go
 

diff --git a/WhyILikeGo.md b/WhyILikeGo.md
@@ -1,4 +1,4 @@
-A slightly updated version of this doc is [here](https://medium.com/@freeformz/why-i-like-go-1b10857f6728).
+A slightly updated version of this doc is [here](http://icanhazdowntime.org/post/2013-02-09-why-i-like-go/).
 
 # Why I Like Go
 

diff --git a/WhyILikeGo.md b/WhyILikeGo.md
@@ -1,3 +1,5 @@
+A slightly updated version of this doc is [here](https://medium.com/@freeformz/why-i-like-go-1b10857f6728).
+
 # Why I Like Go
 
 I visited with PagerDuty yesterday for a little Friday beer and pizza. While there I got started talking about Go. I was asked by [Alex](https://twitter.com/alxsolomon), their CEO, why I liked it. Several other people have asked me the same question recently, so I figured it was worth posting.

diff --git a/WhyILikeGo.md b/WhyILikeGo.md
@@ -75,7 +75,7 @@ With all of that said, it's not perfect...
 
 Go's runtime is not super [tuned](http://golang.org/doc/faq#Why_does_Go_perform_badly_on_benchmark_x) yet. By comparison the JVM has had over 18 years of development history behind it. But, for a 1.0.X runtime & language, Go is pretty damn good.
 
-## Gargabe Collector
+## Garbage Collector
 
 Go programs can malloc a lot of ram at times, even when the program itself isn't using much. Most of this shows up as VIRT though, so most linux systems just won't care.
 

diff --git a/WhyILikeGo.md b/WhyILikeGo.md
@@ -77,7 +77,7 @@ Go's runtime is not super [tuned](http://golang.org/doc/faq#Why_does_Go_perform_
 
 ## Gargabe Collector
 
-Go programs can mallac a lot of ram at times, even when the program itself isn't using much. Most of this shows up as VIRT though, so most linux systems just won't care.
+Go programs can malloc a lot of ram at times, even when the program itself isn't using much. Most of this shows up as VIRT though, so most linux systems just won't care.
 
 ## 1 CPU by default
 

diff --git a/WhyILikeGo.md b/WhyILikeGo.md
@@ -61,9 +61,9 @@ Super [straight foward](http://golang.org/pkg/testing/), no magic.
 
 ## Simple C Interface
 
-By using build directives you can integrade with C libraries really [easily](https://gist.github.com/freeformz/4552031).
+By using build directives you can integrate with C libraries really [easily](https://gist.github.com/freeformz/4552031).
 
-## Straight Forward Sytnax / Srandard Formatting
+## Straight Forward Syntax / Standard Formatting
 
 The syntax is pretty simple, C like w/o all the crazy of C. But what's really nice is `go fmt`, which re-writes your code into the Go standard format. No more arguments over coding style!
 

diff --git a/WhyILikeGo.md b/WhyILikeGo.md
@@ -33,7 +33,7 @@ Or lack there of. Since Go compiles everything statically, you don't have to wor
 
 ## Anonymous Functions & Closures
 
-Go supports anonymous functions that can form closures. These functions can then be passed around and retain the environment under which they were created, like [s](http://play.golang.org/p/4rYrqw4l7m). This can be super powerful when [combined](https://github.com/freeformz/filechan) with channels and go rountines.
+Go supports anonymous functions that can form closures. These functions can then be passed around and retain the environment under which they were created, like [so](http://play.golang.org/p/4rYrqw4l7m). This can be super powerful when [combined](https://github.com/freeformz/filechan) with channels and go rountines.
 
 ## Built in profiling
 

diff --git a/WhyILikeGo.md b/WhyILikeGo.md
@@ -12,7 +12,7 @@ The other 1/2 of Go's concurrency story. Channels are a typed conduit used to se
 
 ## Compiled
 
-Go compiles your program into a **static binary**. Yep, you read that correctly: **a static binary**. This makes deployment really simple, just copy over the binary, all you need is libc. No bundler, no virtualenv, etc. All of that is handled at compile time. This simplifies deployment greatly.
+Go compiles your program into a **static binary**. Yep, you read that correctly: **a static binary**. This makes deployment really simple, just copy over the binary. No bundler, no virtualenv, etc. All of that is handled at compile time. This simplifies deployment greatly.
 
 ## Runtime
 

diff --git a/WhyILikeGo.md b/WhyILikeGo.md
@@ -41,7 +41,7 @@ It supports pprof as part of the standard library. And with a [very small bit of
 
 ## Defer
 
-Ever forget to close a file descriptor or free some meory? So have the designers of Go. The reason for this is that you usually have to perform those actions far away from where the resources were opened/allocated. Go solves this problem with the `defer` statement. Each `defer` statement pushes a function/expression onto a stack that get's executed in LIFO order after the enclosing function returns. This makes cleanup really easy, after opened a file, just `defer file.Close()`.
+Ever forget to close a file descriptor or free some memory? So have the designers of Go. The reason for this is that you usually have to perform those actions far away from where the resources were opened/allocated. Go solves this problem with the `defer` statement. Each `defer` statement pushes a function/expression onto a stack that get's executed in LIFO order after the enclosing function returns. This makes cleanup really easy, after opened a file, just `defer file.Close()`.
 
 ## Comprehensive Standard Library
 

diff --git a/WhyILikeGo.md b/WhyILikeGo.md
@@ -22,6 +22,8 @@ Go is a complied language, but still has a runtime. It handles all of the detail
 
 Everything is passed by value, but there are pointers. It's just that the value of a pointer is a memory location, so it acts as pass by reference. This means that, by default, there is no shared state between functions. But, you can pass a pointer if you desire/need it for performance/memory utilization reasons. Go does the right thing by default, but doesn't shackle you. Oh, and there isn't any pointer math, so you won't screw yourself with it.
 
+As pointed out on [HN](http://news.ycombinator.com/item?id=5196498), you can do pointer math with the ["unsafe"](http://golang.org/pkg/unsafe/) package and `unsafe.Pointer`. 
+
 ## Type System
 
 Go has structs and interfaces. Go's structs can have methods *associated* with them. Structs can be anonymously included in other structs to make the inside struct's variables/methods available as part of the enclosting struct. Interfaces are sets of method signatures. Structs implement an interface by implementing the methods described by the interface definition. Functions can receive values by interface, like [so](http://play.golang.org/p/KfKLiAClQE). The compiler checks all of this at compile time.
@@ -63,7 +65,7 @@ By using build directives you can integrade with C libraries really [easily](htt
 
 ## Straight Forward Sytnax / Srandard Formatting
 
-The syntax is pretty simple, C like w/o all the crazy of C. But what's really nice is `go fmt`, which re-writes your code into the Go standard format.
+The syntax is pretty simple, C like w/o all the crazy of C. But what's really nice is `go fmt`, which re-writes your code into the Go standard format. No more arguments over coding style!
 
 # Issues
 

diff --git a/WhyILikeGo.md b/WhyILikeGo.md
@@ -25,7 +25,6 @@ Everything is passed by value, but there are pointers. It's just that the value
 ## Type System
 
 Go has structs and interfaces. Go's structs can have methods *associated* with them. Structs can be anonymously included in other structs to make the inside struct's variables/methods available as part of the enclosting struct. Interfaces are sets of method signatures. Structs implement an interface by implementing the methods described by the interface definition. Functions can receive values by interface, like [so](http://play.golang.org/p/KfKLiAClQE). The compiler checks all of this at compile time.
-
 ## Package System
 
 Or lack there of. Since Go compiles everything statically, you don't have to worry about packages at runtime. But how do you include libraries into your code? Simply by importing them via url, like so: `import "github.com/bmizerany/pq"`. Go's tooling knows how to look that up and clone the repo. Also works with Mercurial, Bazaar & Subversion.
@@ -38,6 +37,10 @@ Go supports anonymous functions that can form closures. These functions can then
 
 It supports pprof as part of the standard library. And with a [very small bit of work](http://golang.org/pkg/net/http/pprof/), you can access profiling info via a http interface.
 
+## Defer
+
+Ever forget to close a file descriptor or free some meory? So have the designers of Go. The reason for this is that you usually have to perform those actions far away from where the resources were opened/allocated. Go solves this problem with the `defer` statement. Each `defer` statement pushes a function/expression onto a stack that get's executed in LIFO order after the enclosing function returns. This makes cleanup really easy, after opened a file, just `defer file.Close()`.
+
 ## Comprehensive Standard Library
 
 Go's [standard library](http://golang.org/pkg/) is pretty comprehensive.

diff --git a/WhyILikeGo.md b/WhyILikeGo.md
@@ -58,6 +58,10 @@ Super [straight foward](http://golang.org/pkg/testing/), no magic.
 
 By using build directives you can integrade with C libraries really [easily](https://gist.github.com/freeformz/4552031).
 
+## Straight Forward Sytnax / Srandard Formatting
+
+The syntax is pretty simple, C like w/o all the crazy of C. But what's really nice is `go fmt`, which re-writes your code into the Go standard format.
+
 # Issues
 
 With all of that said, it's not perfect...

diff --git a/WhyILikeGo.md b/WhyILikeGo.md
@@ -62,9 +62,13 @@ By using build directives you can integrade with C libraries really [easily](htt
 
 With all of that said, it's not perfect...
 
-## Runtime / Gargabe Collector
+## Runtime 
 
-Go's runtime and garbage collector are not super tuned yet. By comparison the JVM has had several garbage collectors and over 18 years of development history behind it. But, for a 1.0.X runtime & language, Go is pretty damn good. With that said, in my experience, Go programs can mallac a lot of ram at times, even when the program itself isn't using much. Most of this shows up as VIRT though, so most linux systems just won't care.
+Go's runtime is not super [tuned](http://golang.org/doc/faq#Why_does_Go_perform_badly_on_benchmark_x) yet. By comparison the JVM has had over 18 years of development history behind it. But, for a 1.0.X runtime & language, Go is pretty damn good.
+
+## Gargabe Collector
+
+Go programs can mallac a lot of ram at times, even when the program itself isn't using much. Most of this shows up as VIRT though, so most linux systems just won't care.
 
 ## 1 CPU by default
 

diff --git a/WhyILikeGo.md b/WhyILikeGo.md
@@ -65,3 +65,7 @@ With all of that said, it's not perfect...
 ## Runtime / Gargabe Collector
 
 Go's runtime and garbage collector are not super tuned yet. By comparison the JVM has had several garbage collectors and over 18 years of development history behind it. But, for a 1.0.X runtime & language, Go is pretty damn good. With that said, in my experience, Go programs can mallac a lot of ram at times, even when the program itself isn't using much. Most of this shows up as VIRT though, so most linux systems just won't care.
+
+## 1 CPU by default
+
+This is going to change over time, but the runtime will, by default, use only [one CPU](http://golang.org/doc/faq#Why_no_multi_CPU).
diff --git a/WhyILikeGo.md b/WhyILikeGo.md
@@ -1,6 +1,6 @@
 # Why I Like Go
 
-I visited with PagerDuty yesterday for a little Friday beer and pizza. While there I got started talking about Go. I was asked by [Alex](https://twitter.com/alxsolomon), their CEO, why I liked it. I figured it was worth posting, so here it goes...
+I visited with PagerDuty yesterday for a little Friday beer and pizza. While there I got started talking about Go. I was asked by [Alex](https://twitter.com/alxsolomon), their CEO, why I liked it. Several other people have asked me the same question recently, so I figured it was worth posting.
 
 ## Goroutines
 

diff --git a/WhyILikeGo.md b/WhyILikeGo.md
@@ -18,13 +18,13 @@ Go compiles your program into a **static binary**. Yep, you read that correctly:
 
 Go is a complied language, but still has a runtime. It handles all of the details of mallocing memory for you, allocating/deallocating space for variables, etc. Memory used by variables lasts as long as the variables are referenced, which is usually the scope of a function. Go has a garbage collector.
 
-## Pointers/Pass By Value
+## Pass By Value
 
 Everything is passed by value, but there are pointers. It's just that the value of a pointer is a memory location, so it acts as pass by reference. This means that, by default, there is no shared state between functions. But, you can pass a pointer if you desire/need it for performance/memory utilization reasons. Go does the right thing by default, but doesn't shackle you. Oh, and there isn't any pointer math, so you won't screw yourself with it.
 
 ## Type System
 
-Go has structs and interfaces. Go's structs can have methods *associated* with them. Structs can be Anonymously included in othe structs to make the inside structs value available as part of the enclosting struct. Interfaces are sets of method signatures. Structs implement an interface by implementing the methods described by the interface. Functions can receive values by interface, like [so](http://play.golang.org/p/KfKLiAClQE). The compiler checks all of this at compile time.
+Go has structs and interfaces. Go's structs can have methods *associated* with them. Structs can be anonymously included in other structs to make the inside struct's variables/methods available as part of the enclosting struct. Interfaces are sets of method signatures. Structs implement an interface by implementing the methods described by the interface definition. Functions can receive values by interface, like [so](http://play.golang.org/p/KfKLiAClQE). The compiler checks all of this at compile time.
 
 ## Package System
 
@@ -54,6 +54,10 @@ Go do a `go --help`. Some of my favorites: `go fmt`, `go doc`, `go fix` `go get`
 
 Super [straight foward](http://golang.org/pkg/testing/), no magic.
 
+## Simple C Interface
+
+By using build directives you can integrade with C libraries really [easily](https://gist.github.com/freeformz/4552031).
+
 # Issues
 
 With all of that said, it's not perfect...

diff --git a/WhyILikeGo.md b/WhyILikeGo.md
@@ -8,23 +8,23 @@ The first 1/2 of Go's concurrency story. Lightweight, concurrent function execut
 
 ## Channels
 
-The other 1/2 of Go's concurrency story. Channels are a typed conduit used to send and receive values. These are use to pass values to and from Goroutines for processing. They are, by default unbuffered, meaning synchronous and blocking. They can also be buffered, allowing values to queue up inside of them for processing. Multiple go routines can read/write to them at the same time w/o having to take locks. Go also has primitives for reading from multiple channels simultaneously via the `select` statement.
+The other 1/2 of Go's concurrency story. Channels are a typed conduit used to send and receive values. These are used to pass values to and from Goroutines for processing. They are, by default unbuffered, meaning synchronous and blocking. They can also be buffered, allowing values to queue up inside of them for processing. Multiple go routines can read/write to them at the same time w/o having to take locks. Go also has primitives for reading from multiple channels simultaneously via the `select` statement. 
 
 ## Compiled
 
 Go compiles your program into a **static binary**. Yep, you read that correctly: **a static binary**. This makes deployment really simple, just copy over the binary, all you need is libc. No bundler, no virtualenv, etc. All of that is handled at compile time. This simplifies deployment greatly.
 
 ## Runtime
 
-Go is a complied language, but still has a runtime. It handles all of the details of mallocing memory for you, allocating/deallocating space for variables, etc. Memory used by variables lasts as long as the variables are referenced, which is usually the scope of a function. Go has a garbage collector. Since Go is pretty new, so it's not super tuned yet. 
+Go is a complied language, but still has a runtime. It handles all of the details of mallocing memory for you, allocating/deallocating space for variables, etc. Memory used by variables lasts as long as the variables are referenced, which is usually the scope of a function. Go has a garbage collector.
 
 ## Pointers/Pass By Value
 
-Everything is pass by value, but there are pointers. It's just that the value of a pointer is a memory location, so it acts as pass by reference. This means that, by default, there is no shared state between functions. But, you can pass a pointer if you desire/need it for performance/memory utilization reasons. Go does the right thing by default, but doesn't shackle you. Oh, and there isn't any pointer math, so you won't screw yourself with it.
+Everything is passed by value, but there are pointers. It's just that the value of a pointer is a memory location, so it acts as pass by reference. This means that, by default, there is no shared state between functions. But, you can pass a pointer if you desire/need it for performance/memory utilization reasons. Go does the right thing by default, but doesn't shackle you. Oh, and there isn't any pointer math, so you won't screw yourself with it.
 
 ## Type System
 
-Go has structs and interfaces. Go's structs can have methods *associated* with them. Interfaces are sets of method signatures. Structs can implement an interface by implementing the methods described by the interface. Functions can receive values by interface, like [so](http://play.golang.org/p/KfKLiAClQE). The compiler checks all of this at compile time.
+Go has structs and interfaces. Go's structs can have methods *associated* with them. Structs can be Anonymously included in othe structs to make the inside structs value available as part of the enclosting struct. Interfaces are sets of method signatures. Structs implement an interface by implementing the methods described by the interface. Functions can receive values by interface, like [so](http://play.golang.org/p/KfKLiAClQE). The compiler checks all of this at compile time.
 
 ## Package System
 
@@ -34,3 +34,30 @@ Or lack there of. Since Go compiles everything statically, you don't have to wor
 
 Go supports anonymous functions that can form closures. These functions can then be passed around and retain the environment under which they were created, like [s](http://play.golang.org/p/4rYrqw4l7m). This can be super powerful when [combined](https://github.com/freeformz/filechan) with channels and go rountines.
 
+## Built in profiling
+
+It supports pprof as part of the standard library. And with a [very small bit of work](http://golang.org/pkg/net/http/pprof/), you can access profiling info via a http interface.
+
+## Comprehensive Standard Library
+
+Go's [standard library](http://golang.org/pkg/) is pretty comprehensive.
+
+## It's Fast
+
+Go compiles down to native code and it does it fast. Usually in just a few seconds.
+
+## Comprehensive Tooling Out Of The Box
+
+Go do a `go --help`. Some of my favorites: `go fmt`, `go doc`, `go fix` `go get` `go tool pprof` & `go test`.
+
+## Straight Forward Testing
+
+Super [straight foward](http://golang.org/pkg/testing/), no magic.
+
+# Issues
+
+With all of that said, it's not perfect...
+
+## Runtime / Gargabe Collector
+
+Go's runtime and garbage collector are not super tuned yet. By comparison the JVM has had several garbage collectors and over 18 years of development history behind it. But, for a 1.0.X runtime & language, Go is pretty damn good. With that said, in my experience, Go programs can mallac a lot of ram at times, even when the program itself isn't using much. Most of this shows up as VIRT though, so most linux systems just won't care.
diff --git a/WhyILikeGo.md b/WhyILikeGo.md
@@ -30,7 +30,7 @@ Go has structs and interfaces. Go's structs can have methods *associated* with t
 
 Or lack there of. Since Go compiles everything statically, you don't have to worry about packages at runtime. But how do you include libraries into your code? Simply by importing them via url, like so: `import "github.com/bmizerany/pq"`. Go's tooling knows how to look that up and clone the repo. Also works with Mercurial, Bazaar & Subversion.
 
-## Closures
+## Anonymous Functions & Closures
 
-Go supports anonymous functions that can form closures. These functions can then be passed around and retain the environment under which they were created, like [s](http://play.golang.org/p/4rYrqw4l7m).
+Go supports anonymous functions that can form closures. These functions can then be passed around and retain the environment under which they were created, like [s](http://play.golang.org/p/4rYrqw4l7m). This can be super powerful when [combined](https://github.com/freeformz/filechan) with channels and go rountines.
 
diff --git a/WhyILikeGo.md b/WhyILikeGo.md
@@ -30,3 +30,7 @@ Go has structs and interfaces. Go's structs can have methods *associated* with t
 
 Or lack there of. Since Go compiles everything statically, you don't have to worry about packages at runtime. But how do you include libraries into your code? Simply by importing them via url, like so: `import "github.com/bmizerany/pq"`. Go's tooling knows how to look that up and clone the repo. Also works with Mercurial, Bazaar & Subversion.
 
+## Closures
+
+Go supports anonymous functions that can form closures. These functions can then be passed around and retain the environment under which they were created, like [s](http://play.golang.org/p/4rYrqw4l7m).
+
diff --git a/WhyILikeGo.md b/WhyILikeGo.md
@@ -1,6 +1,6 @@
 # Why I Like Go
 
-I visited with PagerDuty yesterday for a little Friday beer and pizza. While there I got started talking about Go. I was asked by Alex, their CEO, why I liked it. I figured it was worth posting, so here it goes...
+I visited with PagerDuty yesterday for a little Friday beer and pizza. While there I got started talking about Go. I was asked by [Alex](https://twitter.com/alxsolomon), their CEO, why I liked it. I figured it was worth posting, so here it goes...
 
 ## Goroutines
 
@@ -14,15 +14,19 @@ The other 1/2 of Go's concurrency story. Channels are a typed conduit used to se
 
 Go compiles your program into a **static binary**. Yep, you read that correctly: **a static binary**. This makes deployment really simple, just copy over the binary, all you need is libc. No bundler, no virtualenv, etc. All of that is handled at compile time. This simplifies deployment greatly.
 
-## Pointers/Pass By Value
-
-There are pointers, but no pointer math. Everything is pass by value, even pointers. It's just that the value of a pointer is a memory location. so it acts as pass by reference. This means that, by default, there is no shared state between functions. But, you can pass a pointer if you desire/need it for performance/memory utilization reasons. Go does the right thing by default, but doesn't shackle you.
-
 ## Runtime
 
 Go is a complied language, but still has a runtime. It handles all of the details of mallocing memory for you, allocating/deallocating space for variables, etc. Memory used by variables lasts as long as the variables are referenced, which is usually the scope of a function. Go has a garbage collector. Since Go is pretty new, so it's not super tuned yet. 
 
+## Pointers/Pass By Value
+
+Everything is pass by value, but there are pointers. It's just that the value of a pointer is a memory location, so it acts as pass by reference. This means that, by default, there is no shared state between functions. But, you can pass a pointer if you desire/need it for performance/memory utilization reasons. Go does the right thing by default, but doesn't shackle you. Oh, and there isn't any pointer math, so you won't screw yourself with it.
+
 ## Type System
 
-Go has structs and interfaces. Go's structs can have methods *associated* with them. Interfaces are sets of method signatures. Structs can implement an interface by implementing the methods in the interface. Functions can receive values by interface, like [so](http://play.golang.org/p/KfKLiAClQE).
+Go has structs and interfaces. Go's structs can have methods *associated* with them. Interfaces are sets of method signatures. Structs can implement an interface by implementing the methods described by the interface. Functions can receive values by interface, like [so](http://play.golang.org/p/KfKLiAClQE). The compiler checks all of this at compile time.
+
+## Package System
+
+Or lack there of. Since Go compiles everything statically, you don't have to worry about packages at runtime. But how do you include libraries into your code? Simply by importing them via url, like so: `import "github.com/bmizerany/pq"`. Go's tooling knows how to look that up and clone the repo. Also works with Mercurial, Bazaar & Subversion.
 
diff --git a/WhyILikeGo.md b/WhyILikeGo.md
@@ -4,13 +4,25 @@ I visited with PagerDuty yesterday for a little Friday beer and pizza. While the
 
 ## Goroutines
 
-Lightweight, concurrent function execution. You can spawn tons of these if needed and the Go runtime multiplexes them onto the configured number of CPUs/Threads as needed. They start with a super small stack that can grow (and shrink) via dynamic allocation (and freeing).
+The first 1/2 of Go's concurrency story. Lightweight, concurrent function execution. You can spawn tons of these if needed and the Go runtime multiplexes them onto the configured number of CPUs/Threads as needed. They start with a super small stack that can grow (and shrink) via dynamic allocation (and freeing). They are as simple as `go f(x)`, where `f()` is a function.
+
+## Channels
+
+The other 1/2 of Go's concurrency story. Channels are a typed conduit used to send and receive values. These are use to pass values to and from Goroutines for processing. They are, by default unbuffered, meaning synchronous and blocking. They can also be buffered, allowing values to queue up inside of them for processing. Multiple go routines can read/write to them at the same time w/o having to take locks. Go also has primitives for reading from multiple channels simultaneously via the `select` statement.
 
 ## Compiled
 
-Go compiles your program into a static binary.Yep, you read that correctly: a static binary. This makes deployment really simple, just copy over the binary, all you need is libc. No bundler, no virtualenv, etc. All of that is handled at compile time. This simplifies deployment greatly.
+Go compiles your program into a **static binary**. Yep, you read that correctly: **a static binary**. This makes deployment really simple, just copy over the binary, all you need is libc. No bundler, no virtualenv, etc. All of that is handled at compile time. This simplifies deployment greatly.
 
 ## Pointers/Pass By Value
 
-There are pointers, but no pointer math. Everything is pass by value, even pointers. It's just that the value of a pointer is a memory location. so it acts as pass by reference. This means that, by default, there is no shared state between functions, unless you desire it for performance/memory reasons. Go does the right thing, but doesn't shackle you.
-Memory used by variables lasts as long as the variables are referenced, usually the scope of a function.
+There are pointers, but no pointer math. Everything is pass by value, even pointers. It's just that the value of a pointer is a memory location. so it acts as pass by reference. This means that, by default, there is no shared state between functions. But, you can pass a pointer if you desire/need it for performance/memory utilization reasons. Go does the right thing by default, but doesn't shackle you.
+
+## Runtime
+
+Go is a complied language, but still has a runtime. It handles all of the details of mallocing memory for you, allocating/deallocating space for variables, etc. Memory used by variables lasts as long as the variables are referenced, which is usually the scope of a function. Go has a garbage collector. Since Go is pretty new, so it's not super tuned yet. 
+
+## Type System
+
+Go has structs and interfaces. Go's structs can have methods *associated* with them. Interfaces are sets of method signatures. Structs can implement an interface by implementing the methods in the interface. Functions can receive values by interface, like [so](http://play.golang.org/p/KfKLiAClQE).
+
diff --git a/WhyILikeGo.md b/WhyILikeGo.md
@@ -1,6 +1,6 @@
 # Why I Like Go
 
-I visited with PagerDuty yesterday for a little Friday Beer and pizza. While there I got started talking about Go. I was asked by Alex, their CEO, why I liked it. I figured it was worth posting, so here it goes...
+I visited with PagerDuty yesterday for a little Friday beer and pizza. While there I got started talking about Go. I was asked by Alex, their CEO, why I liked it. I figured it was worth posting, so here it goes...
 
 ## Goroutines
 

diff --git a/WhyILikeGo.md b/WhyILikeGo.md
@@ -1,6 +1,16 @@
+# Why I Like Go
+
 I visited with PagerDuty yesterday for a little Friday Beer and pizza. While there I got started talking about Go. I was asked by Alex, their CEO, why I liked it. I figured it was worth posting, so here it goes...
 
-1. Goroutines: Lightweight, concurrent function execution. You can spawn tons of these if needed and the Go runtime multiplexes them onto the configured number of CPUs/Threads as needed. They start with a super small stack that can grow (and shrink) via dynamic allocation (and freeing).
-2. Compiled: Go compiles your program into a static binary.Yep, you read that correctly: a static binary. This makes deployment really simple, just copy over the binary, all you need is libc. No bundler, no virtualenv, etc. All of that is handled at compile time. This simplifies deployment greatly.
-3. Pointers/Pass By Value: There are pointers, but no pointer math. Everything is pass by value, even pointers. It's just that the value of a pointer is a memory location. so it acts as pass by reference. This means that, by default, there is no shared state between functions, unless you desire it for performance/memory reasons. Go does the right thing, but doesn't shackle you.
+## Goroutines
+
+Lightweight, concurrent function execution. You can spawn tons of these if needed and the Go runtime multiplexes them onto the configured number of CPUs/Threads as needed. They start with a super small stack that can grow (and shrink) via dynamic allocation (and freeing).
+
+## Compiled
+
+Go compiles your program into a static binary.Yep, you read that correctly: a static binary. This makes deployment really simple, just copy over the binary, all you need is libc. No bundler, no virtualenv, etc. All of that is handled at compile time. This simplifies deployment greatly.
+
+## Pointers/Pass By Value
+
+There are pointers, but no pointer math. Everything is pass by value, even pointers. It's just that the value of a pointer is a memory location. so it acts as pass by reference. This means that, by default, there is no shared state between functions, unless you desire it for performance/memory reasons. Go does the right thing, but doesn't shackle you.
 Memory used by variables lasts as long as the variables are referenced, usually the scope of a function.
diff --git a/WhyILikeGo.md b/WhyILikeGo.md
@@ -1,4 +1,4 @@
-I visited with PagerDuty yesterday for a little Friday Beer and pizza. While there I got started talking about Go. I was asked by XXX why I liked it. I figured it was worth posting, so here it goes...
+I visited with PagerDuty yesterday for a little Friday Beer and pizza. While there I got started talking about Go. I was asked by Alex, their CEO, why I liked it. I figured it was worth posting, so here it goes...
 
 1. Goroutines: Lightweight, concurrent function execution. You can spawn tons of these if needed and the Go runtime multiplexes them onto the configured number of CPUs/Threads as needed. They start with a super small stack that can grow (and shrink) via dynamic allocation (and freeing).
 2. Compiled: Go compiles your program into a static binary.Yep, you read that correctly: a static binary. This makes deployment really simple, just copy over the binary, all you need is libc. No bundler, no virtualenv, etc. All of that is handled at compile time. This simplifies deployment greatly.

diff --git a/WhyILikeGo.md b/WhyILikeGo.md
@@ -1,6 +1,6 @@
 I visited with PagerDuty yesterday for a little Friday Beer and pizza. While there I got started talking about Go. I was asked by XXX why I liked it. I figured it was worth posting, so here it goes...
 
-Goroutines: Lightweight, concurrent function execution. You can spawn tons of these if needed and the Go runtime multiplexes them onto the configured number of CPUs/Threads as needed. They start with a super small stack that can grow (and shrink) via dynamic allocation (and freeing).
-Compiled: Go compiles your program into a static binary.Yep, you read that correctly: a static binary. This makes deployment really simple, just copy over the binary, all you need is libc. No bundler, no virtualenv, etc. All of that is handled at compile time. This simplifies deployment greatly.
-Pointers/Pass By Value: There are pointers, but no pointer math. Everything is pass by value, even pointers. It's just that the value of a pointer is a memory location. so it acts as pass by reference. This means that, by default, there is no shared state between functions, unless you desire it for performance/memory reasons. Go does the right thing, but doesn't shackle you.
+1. Goroutines: Lightweight, concurrent function execution. You can spawn tons of these if needed and the Go runtime multiplexes them onto the configured number of CPUs/Threads as needed. They start with a super small stack that can grow (and shrink) via dynamic allocation (and freeing).
+2. Compiled: Go compiles your program into a static binary.Yep, you read that correctly: a static binary. This makes deployment really simple, just copy over the binary, all you need is libc. No bundler, no virtualenv, etc. All of that is handled at compile time. This simplifies deployment greatly.
+3. Pointers/Pass By Value: There are pointers, but no pointer math. Everything is pass by value, even pointers. It's just that the value of a pointer is a memory location. so it acts as pass by reference. This means that, by default, there is no shared state between functions, unless you desire it for performance/memory reasons. Go does the right thing, but doesn't shackle you.
 Memory used by variables lasts as long as the variables are referenced, usually the scope of a function.
diff --git a/WhyILikeGo.md b/WhyILikeGo.md
@@ -0,0 +1,6 @@
+I visited with PagerDuty yesterday for a little Friday Beer and pizza. While there I got started talking about Go. I was asked by XXX why I liked it. I figured it was worth posting, so here it goes...
+
+Goroutines: Lightweight, concurrent function execution. You can spawn tons of these if needed and the Go runtime multiplexes them onto the configured number of CPUs/Threads as needed. They start with a super small stack that can grow (and shrink) via dynamic allocation (and freeing).
+Compiled: Go compiles your program into a static binary.Yep, you read that correctly: a static binary. This makes deployment really simple, just copy over the binary, all you need is libc. No bundler, no virtualenv, etc. All of that is handled at compile time. This simplifies deployment greatly.
+Pointers/Pass By Value: There are pointers, but no pointer math. Everything is pass by value, even pointers. It's just that the value of a pointer is a memory location. so it acts as pass by reference. This means that, by default, there is no shared state between functions, unless you desire it for performance/memory reasons. Go does the right thing, but doesn't shackle you.
+Memory used by variables lasts as long as the variables are referenced, usually the scope of a function.
No results found