First of all, this article is primarily aimed at sharing my personal research and experience following my expectations on the Go programming language.
Prior to picking up Go, i came from a C#/.Net background, also had some experience with PHP And JS.
In an era where marketing and branding is everything, Bigger cooperations like Google and Facebook have abundant resources to sell anything and package it as they like.
And this was one of the factors that brought me to Go, Go was packaged as a systems language they sold it to us, as a language that can be compared to C/C++ in terms of performance, heck the language itself was made to feel a lot like C.
So, as you might have imagined, it was easy to believe when companies like Uber were writing the better half of their solution with it.
After using Go for sometime and building tons of solutions with, here is the summary of my research.
1. Performance - Performance in Go is engrained in the building blocks of the language, being able to compile AOT, meant it can have faster startup time, Go also utilises the Stack for allocation, pointers when necessary, meant better control of memory, also things like CGO made it way easy to interop with native code and still have amazing performance.
Yet with all these, Go still has the overhead of its runtime and GC, this limits performance compared to C/C++/Rust, so the statement that says Go is a systems language began to become questionable, when the GC has to run concurrently with the process and utilise CPU, it becomes difficult to compare it to native langauges at that level, so much so that recently Discord had to look away and move to Rust.
Alright, so at this point we can now say yes, maybe Go is not really a systems langauge, but how about its fellow GC'd and RUNTIME languages ?
Coming from a C# background, i was made to believe Go would blow away JVM, .Net language, infact anything in its ranks, after surprisingly looking at many benchmarks of the runtimes, doing some myself, almost each time i found out that .Net Core, JVM would outperform Go, and often times ill have to spend hours trying to optimise the heck out of my solutions to either catch up or even come close to their numbers...
I began to research .Net Core/JVM again looking into what is giving them the edge, after reading articles, looking at issues in their repos on Github, and sometimes looking at code that powers these runtimes, i began to appreciate the fact that these platforms have had a head way into the runtime business, over the years they have seen multiple iterations of very powerful engineering, also experimented with many solutions, battle tested and have seen what works and what doesnt.
So, saying that Go will outperform JVM,.Net Core is very myopic to the amount of work that has and is still going into these platforms over the years.
Also JIT compiled platforms, have the edge of runtime information to perform crazy optimisations against AOT that Go operates with. JVM and .Net Core also give you the flexibility to choose the mode you want to run with, giving you more power on that end.
For reference look at this and this Webframeworks Benchmarks
2. Go has everything - Go's standard Lib definitely offers alot, from http protocols, down to transport packages etc, so it is common case where many gophers majorly rely on the standard Lib and build out solutions. But sometimes for larger systems, having all these is just not enough, you would want higher level of abstractions where you just focus on your business logic at hand, and leave out infrastructure parts out to a framework to handle. This is definitely one thing i missed coming into Go having to give up powerful frameworks like Asp.Net Core, laravel etc
In the end, i quickly came to the conclusion, that while Go is amazing at what it does, providing minimal syntax, to allow you reach larger audiences, especially in open source and having a rich standard library, yet it is no silver bullet that provides all the features to make you throw away other platforms.
New developers should not come to Go expecting a solution to all their problems, instead pay attention to actually learning core runtime principles and utilise whatever tool they have, till the tool clearly doesnt have enough to support their job (and this rare ... 90% of the common solutions we build, you would find out that Java,Go,C#,JS etc can handle)
Top comments (0)