Mindset Shift from Object Oriented Language (C#) to Golang

Why GO?

I started with a new project which needs Golang as primary skillset. Hence, I started with Go. I worked on C# for about 6-7 years starting from creating Windows forms to webservices, MVC APIs, scheduled tasks. Not just regular course, I also worked on heavy parallelism requirements and have debugged quite a few memory issues as well. So by now, I had (may be still have ;)) a very firm hold on majority of .NET vertical. I mostly used Visual Studio for all my development needs in the past.

Journey to Go?

I started learning Go with some YouTube videos and then a detailed course on Udemy. I started using Visual Studio Code as IDE with basic configurations and few Go extensions. Extensions made the VSCode editor to a much richer IDE.

Visual Studio Shout Out

Alright, Let’s Get Started!

| First things first |

Initials questions?

1. Since Golang has concept of interfaces, can it be an OO Language? - No, it is not a pure object oriented language. Although Go has types and methods and also allows an object-oriented style of programming, there is no type hierarchy.

2. Classic read from Google (Shall I learn Go): “Go is definitely worth learning if you have an interest in languages that make parallelism and concurrency part of the language. It takes some elements from dynamic languages like Python and couples them with static typing at compile time.”

If you are also a beginner in Go and still building up confidence for writing code, then follow along. After completing a basic Udemy course, I started a sample project on my own using VS Code.

My Project Details

• Started with: School Mgmt Console Application
• Used concept of interfaces, structs, Repository

When this console application was working fine, I started converting it to a webservice by referring to this YouTube tutorial [Y] and refined it further by referencing this article [1].

Feeling Lazy?

Check out my code here. This code is till [Y] tutorial. If you want to fine tune it more, please follow [1].

Gotachas on Go

1. Your code always has to be in $GOPATH/src folder*.
2. Point number one restricts from keeping code anywhere you want.
3. The package management in Go is not central (like Nuget with .NET). If you change your $GOPATH, packages gets re-downloaded (which is per $GOPATH). Just like packages.config in .NET, this one also has a provision to include a go.mod file which can list all project dependencies project-wise with its versions (this configuration is optional).
4. Import statements go too long if folder hierarchy is higher. Example:
   C#

   import (student "Practise/goStudentService/StudentModel" 
           "errors" 
           "fmt"
   )

5. String interpolation: Go lacks the modern style string interpolation. It has C style string formatting functions. Here is a good read.
6. Maps in Go are not exactly as OOP dictionaries. Even key checking implementation is unique.
   C#

   if val, ok := dict["foo"]; ok {
       //do something here
   }

   Original stackoverflow link: https://stackoverflow.com/questions/2050391/how-to-check-if-a-map-contains-a-key-in-go

7. Interface linking is bit odd. You’ll feel this only when you have implemented something like [1].
8. Pointers and mutability: It communicates using mutable objects/variables and states. It has C like pointer concept.
9. What about garbage collection? - The go runtime library implements garbage collection, concurrency and stack management.

No matter how unique golang is, when it comes to concurrency, it outperforms all languages available in the market.

Going with go! This official FAQ page will clear a lot of other doubts.

As of now, I am not sure about its runtime profiling guidelines and debugging memory footprint cases, but I am sure that would also be an interesting $GOPATH.

I hope this post will help developers migrating to Golang from pure object oriented backgrounds.

History

• 7^th April, 2020: Initial version