Skip to main content

Deals You Can't Miss

1 Year Subscription

Go - Strengths, Weaknesses and Threats

This post is web-developer's point of view on the strengths, weaknesses and threats of employing Go as a programming language having used (and continuing to use) programming languages like Java, C-Sharp, Ruby, Python, Javascript etc.

The Strengths

  • Fairly straightforward and simpler to learn and be productive. 
  • Less features implies less things to worry about -- no OOP and thus no classes, objects, inheritance, polymorphism and associated complexities.
  • Errors as return values instead of thrown exceptions. Now this is a different way to see an error/exception.
  • The world is circling back to Statically typed languages and Go is statically typed. 
  • Programming concurrency is simplified with Goroutines.
  • Arguably consumes lesser resources (Memory, CPU, etc.) than other programming languages. 
  • Has the goodness of JVM/Dotnet world's Garbage Collection freeing the programmer of worrying about freeing the critical resources.
  • Employs Pointers only in specific use-cases (like Pass-By-Reference to mutate state or get reference to a specific object) where you can't have other way to solving your problem.


The Weaknesses

  • If you are from the world of OO-programming, you will find OOP amiss. You have workarounds with methods attached to Struct constructs, as an alternative.
  • The fact that Go was written as viable alternative to C programming language can be felt with the absence of abstractions that is available in high-level language. Take `slice` data-structure in Go, which is a wrapper on `array` data-structure for the sake of flexibility in size. The slice data structure, however would NOT provide you with any convenience method to say remove an element from it.
  • Go lacks fluent interfaces that languages like Java, Python etc have and so you do frequent context switching between the business problem you are solving and the programming language nitty-gritties. For instance instead of iterating a collection using high level constructs such as `for each`, you resort to your older ways of introducing local variables in for loop construct. And I don't think, you can have fluent interfaces without Go first introducing Generics :(
  • Not much of mature tooling support in terms of IDE or libraries as things stand today.
    • Take for instance I have an exported method in a file that I try to have unit tests for in another file. The VS-Code editor wouldn't recognize this method name all of a sudden (say when you refactor/rename your method) and would give go lint error like `UndeclaredName` in spite of it being there. But if you try running your tests, it will work fine. This kind of false negatives defeats the purpose of linting and not sure why this supposedly basic thing is broken for a good while now. You can refer issue in github. Guess what worked for me? Close and re-open the VS-Code IDE.
  • You will experience the pain of missing Generics as in Java or the power of dynamic-languages when trying to design a solution. This leaves you with writing a little verbose code and unwarranted duplication of code-logic.
  • Go doesn't support method overloading and the convenience default parameter values. As per Go FAQs, this is a decision taken consciously to simplify things.


The Threats

  • Go emphasizes on shorter naming convention than meaningful names even if it were to be longer. It's been a hard efforts for the world to come to terms to having meaningful names as naming convention fighting the bad habits of shorter names. Go language is taking programmers to older bad habits with pride :(
  • Modules and Packages are a little confusing and takes a while to wrap your head around it; I had to make mistakes and pause for a while to get it right (hopefully). 
    • The package name need not be the same as the enclosing directory, for instance.
    • That your import statements points to directories where the packages are contained and not the package themselves is weird to me. 
    • If you declare a package `game` under `games` directory in a file `f1.go`, then you cannot declare a package other than `game` in another file `f2.go` under the same enclosing directory. Try creating a package like `othergame` in the file `f2.go` in `games` directory and you'll see compile-time error showing `package othergames; expected game compiler(MismatchedPkgName)`.
      If you were to look the go docs for `MismatchedPkgName`, it will read as `MismatchedPkgName occurs when a file's package name doesn't match the package name already established by other files.` only confusing you in this occasion.
      Brain friendly way for this to stick in your mind is thinking about it as you wouldn't want to distribute your packages in different directories for the sake of modularity.
    • So in Go, think of `Module` as an independent project on its own. Your current project is a module, for instance. A module can have many packages, each under its own directory as a convention.

My Popular Posts

Ten Commandments of Egoless Programming

We are nothing but the values we carry. All through my life thus far, I tried to influence people around me with the virtues I value. Thanks to some good reading habits I had inculcated, and the fortune of being in good community of peers and mentors alike, I managed to have read some real good books. This post is about the 10 commands of egoless programming in Weinberg's book. I shall explain the commandments based on my experience here. So very many decades ago, Gerald M. Weinberg authored  The Psychology of Computer Programming . In it, he listed The Ten Commandments of  Egoless Programming , which remains relevant even today for us as not just programmers but as team-members. Weinberg is regarded as a pioneer in taking a people-centric approach to computing, and his work endures as a good guide to intelligence, skill, teamwork, and problem-solving power of a developer. When they appear to inspire and instruct, we find that they can apply to just about every business area, and e

Should I buy refurbished laptop from Amazon?

This post is based on my experience with amazon.in and guess it to be true on all other platforms as well. At least you can check out and verify for these pointers before you make that decision to buy renewed/refurbished laptop on Amazon with your hard earned money. I see this question propping up in several forums and on many different occasions. In the recent past, I had my 5 year old dell laptop that gave up because its motherboard failed. One of the options that I had in my mind was to re-use the HDD and the 16GB DDR4 RAM of that old laptop in the one that I purchase next as secondary.  I had come to a conclusion that it is not worth buying a refurbished/renewed laptop at all. Why? For the following reasons, most of which I see as BIG #RedFlags: You got to remember that Amazon provides a platform for 3rd party sellers to sell their products as well. So in your search for refurbished laptops you wouldn’t want to choose some random 3rd party seller who Amazon doesn’t endorse. You cou

Multi-tenant Architectures

  Multi-tenancy Application Deployment Architecture could be modeled in 4 broad ways: Separate Apps & Separate Databases Shared Apps & Shared Databases Separate Apps & Shared Databases Shared Apps & Separate Databases There is no right or wrong here. It's about choice and consequence that you should consider taking into your business context and constraints. In this post I intend to jot down a some key points to keep in mind for each of these multi-tenant architecture. These are more of quick notes for my quick reference, a cheat-sheet of sorts when I have to make choices. And I guess this can come handy to you too in your wise decision making. Separate Apps & Separate Databases Easiest to implement from development and deployment stand-point. Just automate the deployment infrastructure for every tenant for quick set-up. Most expensive of all the models from infrastructure cost stand-point. Relatively longer deployment t