Go: First Impressions as a .Net Developer
For a very long time, Go was the only language I wanted to learn. I have intended to learn it many times, however, I have given up so quickly because of their website. It’s not as fancy as a front-end frameworks/libraries website like Vue Js, Angular as expected (obviously their website is developed by back-end developers :D).
Two months ago I was in a vacation and wanted to give myself another chance with Go. This time I started with two questions. Those are:
- What kind of problems is Go designed to solve?
- What problems can Go solve in my current life?
Luckily, it took me a minute to find this amazing article to answer those.
Moreover, Go compiles directly to machine code. No need to install a frameworks runtime(eg. Dotnet Core Runtime, JVM).
I was so determined that I would never give up learning Go.
This time, I tried to learn it from different sources. Instead of writing code directly, I have gone deep into Go’s basics and best practices and have not written any single line of code in Go for three days. Because I am very familiar with C# (and it’s my safest heaven ❤), I tried to link everything within these languages (types, methods, class definitions and anything you can imagine). Well, it makes sense until a point, however, every language is not similar and we need to get use to it (for instance interface keyword does not have the same meaning between these languages).
The Difference
In C#, naming is really important that we want to know why a property exists from its name but this situation is different in Go. See the example below:
// C#UserEntity userEntity = _userRepository.GetUser();if(user != null)
{
// Do magic
}
In C#, if a property is defined with underscore, that means it is a private property and it is highly injected through the constructor.
// Go//you can name your imports
import userRepository "example.com/rapository"userEntity, ok := userRepository.GetUser()if(ok){
// Do magic
}
In Go, packages are imported like Javascript and we can name them, long variable names are avoided. If you check repositories written in Go, you will notice that the variable name to check whether the operation completed successfully or not is ok.
Public/private method declarations, method’s return types, extension method declarations, class declarations(there is no class in Go, there is struct), error handling and much more are different in Go.
You can develop your .Net application with pointers by using unsafe mode(the section of the code is not managed by CLR). However in Go, libraries you will use most probably will expect pointers but do not be afraid of it :)
The Architecture
In .Net environment, we are all familiar with n-tier architecture. We all try to build shared libraries across applications. If you create a new application, either it is Asp.Net MVC or Asp.Net Web API, they both implement MVC(Model View Controller) pattern. Therefore, .Net builds a path four our application’s architecture during the app’s creation.
In Go, there is no CLI to create a new app for us. Thus, we’re free to do anything(like Javascript) and we should be careful about it! Otherwise, our app might not be maintainable in the first place.
What is missing in Go?
The first thing I noticed is there is no package manager, meaning there is no NuGet or npm or yarn for Go. Packages are directly imported through its’ repository url (for instance https://github.com/akselarzuman/testpackage-go).
Without versioning, if a breaking change happens in the repository, you know what is gonna happen right? :)
So, how does Go handle versioning of the packages?
Before Go 1.11, there was no package manager, In order to solve this, you would have to use third party dependency management tools like godep and goop.
After the release of 1.11 version of Go, go modules came out and solved this problem. It is not as simple as NuGet or npm, and there is a little bit of learning curve, but it worths using it.
Life With Go Applications at Armut
We have learned and build two applications in two weeks at Armut. We lost much of our time porting libraries written in .Net to Go. Later, we created a new app and currently we have 3 apps written in Go. One is an API, one is a scheduler job and other one is a lambda function(since we love lambdas ❤).
Talking about the API, it runs on a Docker container with 30mb of memory limit. It only consumes 10mb of it. Container size is 14mb’s! It would have been much more if it was written in .Net Core.
I have to admit that, it takes less time to build an application and go live in Go. My heart still belongs to C# but I liked you Go!
