Going Go Programming Recent Posts


Language Mechanics On Stacks And Pointers

Prelude This is the first post in a series that will provide an understanding of the mechanics, design philosophies and guidelines needed for writing consistent and readable code in Go. To get there you need to learn how stacks and pointers work, escape analysis and finally value/pointer semantics. This post focuses on stacks and pointers. Introduction I’m not going to sugar coat it, pointers are difficult to comprehend. When used incorrectly, pointers can produce nasty bugs and even performance issues.

Design Philosophy On Logging

Prelude This post is part of a series designed to make you think about your own design philosophy on different topics. If you haven’t read the following post yet, please do so first: https://www.goinggo.net/2017/01/develop-your-design-philosophy.html Introduction Systems cannot be developed assuming that human beings will be able to write millions of lines of code without making mistakes, and debugging alone is not an efficient way to develop reliable systems. - Al Aho (inventor of AWK)

Package Oriented Design

Updated on February 28th, 2017 Prelude This post is part of a series of posts designed to make you think about your own design philosophy on different topics. If you haven’t read these posts yet, please do so first: https://www.goinggo.net/2017/01/develop-your-design-philosophy.html https://www.goinggo.net/2017/02/design-philosophy-on-packaging.html Introduction Package Oriented Design allows a developer to identify where a package belongs inside a Go project and the design guidelines the package must respect. It defines what a Go project is and how a Go project is structured.

Design Philosophy On Packaging

Prelude This post is part of a series of posts designed to make you think about your own design philosophy on different topics. If you haven’t read this post yet, please do so first: https://www.goinggo.net/2017/01/develop-your-design-philosophy.html Introduction In an interview given to Brian Kernighan by Mihai Budiu in the year 2000, Brian was asked the following question: “Can you tell us about the worse features of C, from your point of view”?

Design Philosophy On Integrity

Updated on February 10th, 2017 Prelude This post is part of a series of posts designed to make you think about your own design philosophy on different topics. If you haven’t read this post yet, please do so first: https://www.goinggo.net/2017/01/develop-your-design-philosophy.html Introduction I want to share with you my design philosophy around the word Integrity and what it means to me from a Go perspective. Integrity is much more than just a buzzword, it is a driving principle in everything I do, both in code and in life.

Develop Your Design Philosophy

Prelude This post is part of a series of posts designed to make you think about your own design philosophy on different topics. I will not be laying out direct examples to prove my own thoughts and ideas. It takes me two or three days in the classroom to do that and it’s why I think my classes are so special. My goal is to get you and others to write the next set of blog posts to prove or disprove these ideas.

Video: Design Philosophy in Go

This is a talk that I gave at the Vancouver Meetup on November 29th, 2016. The talk covers topics around developing your own design philosophy with a focus on decoupling from change. These are things I cover extensively in the Ultimate Go Classes. Here is the material that is covered in the talk. Review the Grouping and Decoupling topics.

Application Focused API Design

“I think it’s ok to do heinous stuff to test an API if it makes it more usable by others.” - Nate Finch Prelude If you are new to Go, it might help to read these posts first before continuing on with this post. https://www.goinggo.net/2014/05/methods-interfaces-and-embedded-types.html https://www.goinggo.net/2015/09/composition-with-go.html https://www.goinggo.net/2016/10/reducing-type-hierarchies.html https://www.goinggo.net/2016/10/avoid-interface-pollution.html Introduction Packages exists to help provide support for specific problems that are commonly found in the different applications we are building. A package API should be intuitive and simple to use so application developers can focus on their concerns and hopefully develop their applications faster.

Avoid Interface Pollution

Introduction Interfaces should only be used when their added value is clear. I see too many packages that declare interfaces unnecessarily, sometimes just for the sake of using interfaces. The use of interfaces when they are not necessary is called interface pollution. This is a practice I would like to see questioned and identified more in code reviews. Code Example Let’s look at a code example that contains questionable design choices that raise flags for interface pollution.

Reducing Type Hierarchies

Introduction I see a lot of developers coming to Go from object oriented programing languages such as C# and Java. Because these developers have been trained to use type hierarchies, it makes sense for them to use this same pattern in Go. However, there are aspects of Go that don’t allow type hierarchies to provide the same level of functionality they do in other object oriented programming languages. Specifically, the concepts of base types and subtyping don’t exist in Go so type reuse requires a different way of thinking.




Ultimate Go Schedule


Location Start Date End Date Class Enrollment
Miami, FL Saturday, May 20th, 2017 at 9:00 AM Sunday, May 21st, 2017 at 5:00 PM Ultimate Enroll Now
Utrecht, Netherlands Thursday, June 1st, 2017 at 9:00 AM Saturday, June 3rd, 2017 at 5:00 PM Ultimate Enroll Now
New York, NY Saturday, June 10th, 2017 at 9:00 AM Sunday, June 11th, 2017 at 6:00 PM Data Enroll Now