loading...
Cover image for GoLang, The Next Language to Learn for Developers

GoLang, The Next Language to Learn for Developers

dizveloper profile image Edvin Updated on ・11 min read

The Origin Story

Rumor has it that GoLang's ideation occurred during the lull in which developers were waiting for their program to compile. These devs were getting tired of waiting, and not working. Three programmers at Google, rose to the occasion as they have so many times before. In 2009 Go was announced, and version 1.0 was released in 2012. Three engineers at Google (Robert Griesemer, Ken Thompson, and Rob Pike) created a systems level language to replace all of the other ones since there hadn't been a new one in that arena in a while and none of the existing languages were considering multi-threading as a core tenet.

Robert Griesemer, Rob Pike, and Ken Thompson

These three worked on some pretty big deal projects in the past. That includes the C programming language, Unix, UTF-8, JVM, and a couple others. Go is the first language in a while where modern-day engineers are given the ability to not have either efficient compilation, efficient execution, or ease of programming. All three were not all available in the same mainstream programming language. Go is an attempt to bring all of these capabilities into one language.

What Does Go do at Google?

Well, Go is specifically a systems-level programming language for large, distributed systems and highly-scalable network servers. It is meant to replace C++ and Java in terms of Google's needs. Go was meant to alleviate some of the slowness and clumsiness of development of very large software systems. To be a little more specific, Go helps solve …

  • slow compilation and slow execution
  • programmers that collaborate using different subsets of languages
  • readability and documentation
  • language consistency
  • versioning issues
  • multi-language builds
  • dependencies being hard to maintain

Don't Take My Word for it

StackOverflow 2018 survey

Go has climbed the ranks on StackOverflow to the fifth most 'loved' language. The developer survey shows that currently 65.6% of developers that are using Go, will continue to work in Go rather than any other language if given the choice.

Ranking languages by Github users

Go is also one of the fastest growing languages on Github, Go is CRUSHING it. In 2016, Go had around 188k opened pull requests, which was up 93% from the previous year. In 2017, it jumped to 285k to become the 9th most popular language on Github.

HackerRank 2018 developer skills survey

Go has become the 'next language to learn' for a lot of developers. HackerRank surveyed exactly that, and Go is taking a significant lead. This assessment was from February of this year.

Obviously, carrying Google's name has applied a serious multiplier on Go's success and adoption. You're interested now, right? Well assuming you weren't before you decided to click on an article about GoLang…

How is a System Level Language That Popular?

Simplicity is probably one of the greater reasons why Go has been adopted so easily. When you look at all of the other languages and their evolution, they are constantly introducing new features which sounds like a good thing, and it is, don't get me wrong. The outstanding issue is that said languages are becoming more and more similar in functionality, look, and feel. Go is what it is, and doesn't try to be much else. It covers its own bases very well but doesn't stretch itself too thin. This was completely intentional. The contract* that the three developers decided on was that all three of them must agree on a feature and that it was the right feature to be included in Go. This was meant to assure that Go had the simplicity and readability that Rob, Robert, and Ken all decided was absolutely critical. The current idea with Go is that there won't be significant changes in Go's functionality or aesthetic in the long term. The only suggested feature that the developers are even considering adding is generics. The languages FAQs document mentions that generics may be added at some point, but they just don't feel the urgency. There may be a Go 2 eventually, but probably not for a few years.

Why so GOpinionated?

The Go team had come to the conclusion that with adding more features and more functionality, there comes greater complexity and more difficulty in ramping up new developers on projects, and in learning the language in the first place to begin writing production-ready code. Go is meant for any developer to be able to begin writing production-ready code almost on day one.

Let's think about javascript as an example that most developers can relate to (since it's the most popular programming language internationally). You can write one function in an incredible number of ways, but in Go there is pretty much only one way to write said function. There are not as many mental hops that you have to make to put yourself into the mind of the dev that wrote the javascript function, or into your own mind a couple of months ago to fully understand the code in front of you. Now I can agree that javascript is probably much more fun to write in, but Go gives you maintainability, simplicity, and overall greater speed of producing.

Concurrency is NOT Parallelism

It is important to explain that concurrency is not inherently parallelism. Concurrency is a much more structured approach for dealing with many processes, rather than doing a bunch of things (or many instances of the same thing) at the same time. So being concurrent doesn't mean that two processes will never run at the same time. That will occur, but it is more about the communication of said processes. Knowing when to do something, and how to do it as well. So with Go, they are meant to talk. Though you can create parallelism, that isn't really the whole picture.

To help better explain that idea, imagine (in the spirit of the World Cup finishing up recently) a soccer team during the game. Each player on that field is a single process (GoRoutine in this situation). They are all running and communicating with the ball (data) being their trigger or point of communication. The goalie is not always moving, but acts accordingly when the ball is somewhere within their half of the field, and DEFINITELY when it is near the box. Every player (GoRoutine) has a job to do that is independent, but coordinated with the others. If we were talking purely about parallelism, each player would be playing a game all by themselves with no interest in what any of the other players were doing.

Go's solutions for concurrency:

GoRoutines (execution)
A GoRoutine in the Go programming language is a lightweight thread that is managed by Go runtime. If you just put 'go' before a function, it means that it will execute concurrently with the rest of the code.

Channels (communication)
Channels are pipes that connect concurrent GoRoutines. You are able to send values and signals over Channels from GoRoutine to GoRoutine. This allows for synchronizing execution.

Select (coordination)
The Select statement in Go lets you wait and watch multiple operations on a channel. Combining GoRoutines and channels will show off the true power of concurrency in Go.

What's unique about Go?

  • Go has implemented latency free garbage collection and fast compile times. The language completely (and I mean completely) abstracts away garbage collection and manual memory management. Both of which are a massive time suck when implementing manually in the likes of C and C++
  • There aren't really classes in Go. Rather your structs and interfaces are all typed. The following is a very simple example of both.
  • Go is statically typed, and because of this, most (if not all) errors are caught in compile time, rather than runtime. Go is type-safe, meaning that you can't mess around with types in a way that would crash the program. Go is also memory-safe, meaning that you won't have to deal with memory vulnerabilities like buffer overflows and dangling pointers.
  • In many other programming languages, you would have to choose to either throw/return an exception/error, but because you can return tuples in Go, you can both throw an error and return a value when necessary. This is important because Go doesn't have exceptions. Go relies on 'if'ing for errors. It is up to you to handle it how you'd prefer. This may sound like a limitation, but it can be quite freeing and powerful in the right situations.
  • Functions can be passed into other functions, returned, and declared as variables. Functions can also be created within other functions, also called closures.
  • Go has a defer keyword that allows for deferring functionality. What that means exactly is that you set some action or execution to be deferred until the surrounding function returns. Deferred calls are evaluated immediately wherever they are, but will not execute until said surrounding function is completed. Also, deferred function calls are executed in last in first out order.

There are more unique things about GoLang, but that was just a quick once over for cool stuff.

MY PROGRAMMING LANGUAGE IS BETTER THAN YOURS

C and C++

As mentioned earlier, Go has some advantages in comparison to C and C++, such as the aforementioned type and memory safety, and (in my opinion, and probably anybody's that has worked with any of them) has a MUCH easier and quicker ramp-up period. Also, once you understand Go, Reading Go and understanding what the code is doing comes much more easily. That seems like an obvious assessment… but there are a plethora of people that know Javascript, but they don't KNOW Javascript. What I consider the greatest advantage over C is how Go (as I mentioned earlier) completely takes care of garbage collection and memory management. There is a package (unsafe) that contains operations that allow you to circumvent Go's type safety and allows you to handle memory/pointers whichever way you'd like. I must also mention that this may make your binary non-portable and is not protected by the Go 1.0 compatibility guidelines.

Rust

Rust and Go were compared because they were both systems level languages that came out around the same time and aim to solve issues that the other doesn't. Rust was meant to be completely interoperable with C and D. Go wasn't.

Go can be interoperable with these. There are two Go compiler implementations, gc, and gccgo. Gc uses a different calling convention and linker and because of this, can only be linked with C programs following the same convention. Gccgo is a GCC frontend that can be linked with GCC-compiled C or C++ programs. Gccgo is slower to compile than the default gc, but supports more powerful optimizations so many programs compiled with it will run faster. This takes great care and even more patience.

The cgo program provides the mechanism for a foreign function interface to allow safe calling of C libraries from Go code. SWIG extends this capability to C++ libraries.

Simply stated, Go is meant to be a standalone maintainable and efficient language, and Rust pretty much just gives C devs a new way to code that is easier and faster than C (but what isn't).

Java

Java and Go will obviously be compared, but they have a crazy amount of differences. Java is much more expansive, has frameworks out the wazzoo, and has had a chokehold on the industry for years. Since there are plenty of reasons why to use Java, I will instead mention the reasons Go is better. Please keep in mind that Go isn't meant to completely replace, but to improve in the areas that it is meant to improve.

  • Because of hierarchy and polymorphism, Java projects become pretty hard to maintain. Interfaces, which are supported by both Go and Java, can do pretty much the same thing, but Go's interface is more flexible.

  • JVM is (obviously) a virtual machine by name, where Go compiled binaries run natively/directly on the processor.

  • Java doesn't implement anything similar to goroutines in the standard library. There are libraries that solve that issue, but even still, they are relatively hard to maintain, but Go comes with phenomenal concurrency out of the box.

  • Go has an arguably faster development cycle once the development team has learned the language.

Python and Ruby?

An unexpected comparison is that Go has been considered as a replacement or supplemental language to the likes of Python and Ruby.

It has replaced Ruby when high scale performance is necessary. Go is also able to interact with almost all databases as a server-side language, whereas Ruby has limited compatibility to only be able to use the most popular databases.

I've read about many Python programmers deciding to switch to Go in enough cases that there is a plethora of talks on youtube, blog postings, and side by side code comparisons of Python and Go. People have been using Go to write scripts even though it isn't a scripting language.

Which language is considered one of the greatest competitors to Go? Well, it is actually Node.js because Node solves "high concurrency of HTTP requests, and high volume reads and writes to databases". GoLang just does quite a bit better.


I would suggest checking out Hackernoon's article, that shows a real-world example of why you would use GoLang in place of Node.js with and AWS Lambda function built in the two respective languages, and then load testing them.


I've talked plenty about why and how Go is great, but it has some downsides. These downsides should for the most part be irrelevant if you are using Go for what it is intended for, because it just wasn't meant to do many of these things on purpose. Go does what it does REALLY well. It's fast, pretty easy to learn, and highly scalable. BUT it does have significant limitations when it comes to things that it obviously can't do, but I must say that's mostly developer opinion. Use the right tool for the right job.

Cons:

There isn't much attention given to version maintenance of packages that you 'go get' and it is suggested that if you think that a future version will cause issues that you store the needed versioned package, locally or included it in your repo. (there are solutions for that. See dep)

  • No Generics, no .map, .reduce, .filter

  • No exceptions or assertions, as mentioned earlier (but I feel that this could go either way)

  • No Ternary operations. Use the good ole 'if else' statements.

  • Absolutely no tolerance for unused variables or imports (but is that really a bad thing?)

  • Your virus protection might think your compiled binaries are infected because it doesn't understand the structure of a Go Binary 😅

  • No pointer arithmetic (but thats for safety, and simplifies implementation of the garbage collector)

  • And honestly, dealing with GOPATH is kinda messy and annoying. You are forced to do all of your go projects within your GOPATH, but IDE's like VSCode and GoLand allow you to set the GoPath for your project without affecting your system's actual GOPATH.

In Closing..

Its popularity is growing at an increasing rate, and if you're getting into the serverless and cloud game, I'd consider it crucial to learn GoLang. With the speed advantages of compilation and execution, your efficiency and cost of execution is positively impacted to say the least. It has become a critical component of cloud infrastructure and probably not going anywhere for quite some time.

This article was originally posted on Medium @Slalom-Technology

Posted on by:

dizveloper profile

Edvin

@dizveloper

#GirlDad | 🇧🇦 Refugee | Coder

Discussion

markdown guide
 

The more I learn/use/etc about go, the more I despise it.

Don’t get me wrong, it’s nice to be able to churn out a few static binaries here and there so I don’t have to install/manage a runtime environment on an arbitrary machine.

However, here’s a list of things I always miss when using go:

  • List comprehensions (mentioned above)
  • A halfway decent dependency manager (npm is what I attribute a lot of JavaScript’s popularity to, despite npm being a nightmare a lot of times.)
  • assertj
  • union/sum types
  • not having nil that is all types at once
  • monads/applicative functions
  • true tuple return values
  • not having to worry about pointers (seriously, why allow pointers when I can’t do math with them?)
  • being able to write fun instead of func
  • a static type system that can figure everything out (seriously, use a language that goes full Hindley-Millner, you will experience the joy of programming like you’re using a dynamic language but with super strict typing)
 

You might want to take a look at crystal-lang.org – to totally oversimplify it, it's a bit like "the best stuff taken from Ruby and Go". It might not fit all your points, but might be interesting enough.

 

Go actually does a lot of the stuff that you mention here. Maybe not to your specific liking, but it definitely does. Your issues with the language are definitely valid. Mainly because all of programming is opinionated. Don't use Go if you don't like it. It probably doesn't do everything you need it to do. In cases where Go is useful, it is usually the superior option. Totally understand your concerns.

 

"Don't use Go if you don't like it." HAH! Good one. Some of us don't get to pick our toolchain front to back. (To my teammate's credit, I'd probably just choose Haskell front-to-back, which would be unreadable to anyone but mathematicians.)

Hahaha. Fair point, fair point. We don’t always have that luxury. 😅

which would be unreadable to anyone but mathematicians

Can we please stop the "Haskell is unreadable" trope? Familiarity does not necessarily equal ease. I think that many people have barely seen Haskell code outside of tutorials, which for better or worse tends to show off.

Hey, I hear you, but for people who have only done work with children of Algol, Haskell is not easy.

I found lisp easier to learn (parenthesis and all) than Haskell. But once I learned enough functional programming and functional math, it was pretty easy to make the leap over.

Now I’m not going back... the static typing is too good.

 

being able to write fun instead of func

Imagine writing fn instead of fun 😉

 

Robert Griesemer has never worked on or for Unix. He came from Google's V8 project as far as I know. Rob Pike is a great guy though. A pity that Unix 9/10 (which was the origin of the Plan 9 operating system) is largely overlooked in today's media. I mean, he wrote Sam and Acme for it! :)

Regarding Go, I find it sad that it blurs the Gopher protocol by using "GopherSomething" for everything they do... The language itself is weird. It has nice concurrency features and its compiled binaries are adequately small (although I still prefer C for such optimizations), but double return types and implicit semicolons are incredibly limiting if you come from C...

I find my way around Go. I just never decide to use it instead of a different language. Go does not solve any previously unsolved problem, I'm afraid.

 

My mistake, I should’ve clarified. I wasn’t saying that all of them worked on each of those projects I mentioned. Just that between them, they had those credentials.

Go definitely doesn’t offer the optimization that languages like C, do. They sacrifice optimization for ease and readability. At least, that is how I see it. It’s a nice middle ground for those wanting to have more power but are too intimidated by C. Go doesn’t claim to solve new issues, rather better solutions for current friction points. Such as concurrency.

I’m glad you like C so much though. I am infatuated with systems level programming, but that doesn’t mean I love C. Go is great for me.

 

C has its own quirks, but it does not intimidate me anymore, so I'm fine with either. 😉

 

Regarding Go, I find it sad that it blurs the Gopher protocol by using "GopherSomething" for everything they do

It's been a long time since I actually saw a Gopher server in the wild :) Did you mention in your "graveyard thread" that you implemented a gopher client? If yes, what lead you to that point? I'm genuinely curious and not asking in a "why waste time on this?" sort of way, since I never consider time spent on things you like wasted.

 

There still are many Gopher servers left. :) Hmm, I have a thing for efficient, non-bloated protocols, I guess.

Oh my, this little exchange led me to go down memory lane with a little tour of Gopherspace (with Lynx as my client) :)

 

This is a great article! Thanks for sharing.

Go has replaced Python for most server side services at my work, and I've been enjoying using it, although it can be a bit jarring coming from a Ruby background, and there's definitely less convenient sugary yummy syntax I loved with Ruby.

The best quote I've heard describing Go's error handling (or maybe Go in general):

"Go is like a new friend who's a bit too honest, like she'll tell you if you have too much makeup on. But over time, you'll learn to appreciate the straightforward candor since it's always explicit." 😂

 

Hahahaha, I’ll remember that one! It has definitely become popular in that arena.

Thanks for reading! I hope you continue to enjoy. 😊

Go also has the reputation of being like “mmmmm, no. We don’t do that here”. 😂

 

Golang is great... but relatively!

I've tried to see in what context go can fit in the enterprise, and I realized Google invented this whole thing to avoid the ugly c / c++ maintenance (cuz Google needs the performance badly).

Wiki:

The designers cited their shared dislike of C++ as a primary motivation for designing a new language.

So yeah... before choosing this language (not just cuz of the hype), one should be sure whether it fits in a similar context for him.

 

Agreed. Totally about relativity, but I do think that it still great to at least learn Go at a basic level. I'm no longer really programming in C or C++, but learning those gave me a greater understanding of underlying algorithms and methodologies of more modern programming languages. I think Go can serve as that systems level language without being as difficult as C++ to understand. But, yes, at the enterprise level I totally agree that you shouldn't force a square peg into a circle hole.

 

There's a lot to like about go. In particular the simplicity, performance, and composition.

What killed it for me was (DISCLAIMER: I haven't looked at it in 2 years):

  • Nil
  • GC
  • No generics -> casting everywhere
  • No operator overloading- except for the built-in types...

That last point made user-defined types feel like second-class citizens. I don't even like operator overloading, but a language needs to adhere to its own dogma.

And yeah, nil. After using F# for a year before looking at golang I'm totally spoiled. I'm already proficient at C++ and C#, there's just no more room for any more null in my life. =)

 

All very good points. I totally agree. I can’t say that I’ve ever actually used F#, and though I’ve spent 2 ~ 3 years using C++, it could take me a decade to even consider saying I was “proficient”. Go is powerful, currently pretty popular, and honestly it’s just kinda fun right now. Thanks for reading!

 

It's definitely pleasant to use. It had the best IDE experience of any language I've ever used and has excellent documentation.

I've been thinking about giving it another look. Looks like they've made big improvements to the GC in the last few years and now there's proto.actor- we were looking for something like akka or MS orleans.

Anyway, enjoyed your in-depth write-up to keep in refreshed on my radar.

 

Thanks much for the article and the honest, comprehensive assessment.

Understand, I address only the 'hype' surrounding GoLang, not its intended purpose, nor the admirable skill of its creators.

I'd richly prefer to banter this over a few beers. But I'll start here - "It has become a critical component of cloud infrastructure and probably not going anywhere for quite some time." Is there any wonder? It's a Google whim.

When I first heard Go explained to me, my sinking gut reaction was about the same as when I first heard 'Cloud' and 'Internet' in the same sentence. Am I the only one out here that gets uncomfortable about his program, years in the effort, with database, running on someone else's machines, inaccessible, under a 'vendor lockin' subscription? - hint - Google Application Engine, ad nauseum.

After years in C#, my Microsoft passion came to a grinding halt. There was a dubious dabble in Java and Tomcat. I didn't walk away. I ran. Mostly, there were 4 years in Ruby/Rails. A great time. But one night when my gem didn't compile (again) and version conflicts raised their ugly heads (again), I threw a temper tantrum that should have been on video. I scrapped the whole program and rewrote it in PHP/C++. No CGI. Never looked back. Never been happier. I started with C++, and God, why did I ever abandon it?!

Ignorance and fear come to mind. For example, why in the h-ll do you need an interpreted language, cross-platform, when you, yourself choose the server os? Because this is the befuddled mind of soooo many Internet beginners, like me, and for years...no thanks to academicians. And no thanks to all those companies pushing frameworks, and other bridges to sell.

If only I had a dollar for every time I've read, "Go is a system level language." Really? So, it's the perfect choice for a driver? We could hypothetically write a robust operating system with it from top to bottom? Hmm... Go's meagre 'runtime' is rolled up into its binary. C/C++ doesn't even need an operating system.

I wouldn't be here, except, ...once upon a time, there were the entreatments of a certain lead Python programmer to his polite (procrastinating) director, said programmer wanting to use Go in a re-write of the company's failed flagship site, a Python mess. What's the connection?

Fellas, please, this mystery over Go's popularity isn't computer science. The elephant in the room is a far less technical story.

Not but a decade has passed when many programming book covers touted the word 'Art'. Remember? Now, the trend finds any language requiring diligence a pariah.

The developer blogs are replete with slights and outright snide remarks made by Python enthusiasts toward C/C++. I also witness the same ilk duped like religious fanatics by Cloud gimmicks that promise the moon (and charge the sun).

Thus, I don't buy the innocent claim of 'surprise and shock' decried by Go's engineering team over the snub from the C/C++ community. Likewise, there's no surprise that the Python community has embraced Go. (Ruby's excuse, if it's the truth, is different.) Google, for some years, has championed Python. And within this zealous ecosystem, Google is a demi-god. Now, GoLang was written by...well, enough said.

And Go's the White Knight, now, come to rescue us from all those shameless compiler smoke breaks and trips to the coffee machine. Yes, I wait, if I've played with my base class, especially the header. But my dedicated page classes are about 2 seconds, hardly the time to reach for my lighter.

Ah...forgot. Go has no headers. Awesome. No patient, no sickness. Besides, who needs all that fancy inheritance tomfoolery (despite even Rails builds its renown MVC architecture with it)?

Pardon the brutality, but there are few articles I've come across on Go that don't distil to this - "Go is better because it's easier." It's a rank, Python echo chamber.

I don't care if 99.9% of the crap written for Internet is passed off as quality. We've all seen it. And nobody will ever convince me that because "an orangutan can do it" the program is superior.

Again, fellas, please. Lazy programming ethics and idiot-proof languages do NOT summarily equate to better solutions. "Get s**t out the door" may be good enough for mom-and-pop sites and unwary clients. But that kite doesn't fly for projects that are Biblical Exodus in scale. So, I build an outhouse on sand. It tips. I jack it up and throw a block under a sagging corner. Good 'til next Halloween. But you don't build Trump's tower on a beach! And this simple concept, practically applied, draws blank stares from every Python programmer I've ever met, that is, until I've had a chance to 'talk' with them.

I'd say that the Go team's greatest impetus is the smug pleasure they get, knowing what commotion they've caused out here for the rest of us. Again, not surprising. C/C++ programmers can write Linux or Facebook or the virus that shuts down your favourite bank ATM.

 

That's one hell of a reply my guy. Seriously well put, and thought through. I've pleaded my case and how I feel about Go, its ups and downs. I may come to change my mind many times while developing in Go.

Also I'd absolutely suggest (if you haven't already) to turn this into your own post. Throw in some digestible counter arguments and examples. I'd love to read it!

 

Appreciate it! I'd say yours is the best impartial blog I've come across. And there is Murray,

murrayc.com/permalink/2017/06/26/a...

...at which I've glanced.

My jab, above, is clearly biased. And the pro-Go 'hype' is really the comment sections, mostly. Expected.

But Go, admittedly, IS a vector properly pointed. It's compiled, not to some bytecode goop for the Ponderosa vm, but a real binary! Some of this hype is deserved.

Thus, I've every intention of investigating Go. I've stamped my approval on the trial and use of it for one of our mobile back-ends. God help us, we are now a Gopher company.

Go may hold the minor mystery I seek, even if used just as a glue language. That is, I'm somewhat embarrassed by my heavy use of PHP's exec(myprogcpp params). I would 'mask' that if I could, and without CGI. And I don't want to re-engineer PHP through extensions, which as I understand, requires something third party, anyway (Zend API).

So, exec() is the skeleton in my closet. But it works so well! Some of my in-house database programs skirt the need of embedded script (almost entirely) by tucking html in C++ strings. Absolutely no external .html or .php views. Love it. But for team projects, my front-end guys would kill me!

TreeFrog C++, with its bloated MVC may hold some answers. I may play with it, again, this weekend. (BTW, out of everything hyped in Internet development, Model/View/Controller is king!) If I can come up with something more elegant than exec(prog params); foreach($output...); THEN I'll consider writing that post. Cheers! ))

 

I like Go (and hate it), but unfortunately, for me the forced project structure is a no deal for me. Don't want to be told where to put my code or have to make a symlink for all my repos.

Just like you mentioned with the GOPATH.

I really dislike when languages enforce styles. Sure, it's nice, but what if you don't like it? Languages like Go and Python are nice, but being forced to conform to a certain code style is really annoying sometimes.

If I want to write shitty code--let me write shitty code!!

 

Hahahaha, power to you my friend! Totally get that (to some extent). One of my reasons for that being a good thing is that there truly is only one way to do something. Though it may not always be fun, it's practical.

 

I like Go (and hate it), but unfortunately, for me the forced project structure is a no deal for me. Don't want to be told where to put my code or have to make a symlink for all my repos.

This is finally (mostly) solved with Go 1.11: dev.to/rhymes/go-gets-modules-12ei

I really dislike when languages enforce styles. Sure, it's nice, but what if you don't like it? Languages like Go and Python are nice, but being forced to conform to a certain code style is really annoying sometimes.

As with many things with Go, you need to embrace it. Think about how much time people spend setting up linters and writing code style specifications and compare it to the zero time you spend on it if you use Go :-)

 

Great post! I’ve been learning Go over the past year and my team at work recently adopted it (moving away from PHP/symfony for the majority of our backend work).

 

Nice! I'd love to hear how that pans out. Talking about the transition would make a great article. Not only the positives of switching but also the heartaches and friction points. Thanks for reading!

 

Yeah, I've never really been one to write posts but I keep seeing it suggested as a way to grow as a developer.

I have a draft here that I will probably post in the next day or so. I'll definitely continue to look for opportunities to post.

Neither have I, until recently. I'll be the first to admit that I am not an expert, but sometimes the student is a better teacher. I absolutely advocate for blogging and technical topics, because it has made me better every time. Even if I've already been programming in the language, I learn so many little things that get incredibly under-utilized because you just forgot that they existed.

 

I'm a Go user and really love it, it's kinda a newish C aimed at web, along with an easier syntax and easy concurrency.

However, there are some points that you made that are somewhat overselling the language:

  • Go is not a systems programming language:

    Due to the need of a runtime, you can't really do baremetal with it, and its binaries are kinda huge when compared to other languages since you are packing the whole runtime inside of it. One could say that Go is actually more akin to Java than C, which brings us to the next point.

  • Go doesn't really compare to Rust at all

    Rust is a truly compiled language (backed by LLVM) aimed at systems programming which has no garbage collector and has a much smaller and less intrusive runtime. In fact, you can even do baremetal without needing to use the std lib at all - check out no_std, they're doing a really job for embedded systems. Rust is actually meant to replace C and C++ by being as fast while providing a safer memory model.

    Due to the somewhat bloated runtime which abstracts a lot of things for you, Go looks a lot more like java, and they even usually trade blows when it comes to speed, meaning that Go is way slower than C. The only thing Go and C have in common is the similar syntax and the history of its founders.

Other than that, I really liked your article and wish more people get to use this amazing language. Lots of companies I know are switching from their PHP/Python/Ruby systems due to performance and costs.

 

Many would argue that it is a systems-level programming language. The thing that I've realized in the discussion over programming languages is that everyone is wrong and right while saying the exact opposite things. I agree with you on the point of Rust not being anything like Go, ironically Google is using Go to replace both C++ and Java. It kinda shows that Go is mid-way between the two in some sense. I think Go's greatest claim to fame is its speed of execution in comparison to true competitors like Node. The article was meant to bring together all of the viewpoints when compared to several languages that have come up when trying to figure out what Go's use is.

 

Nice article, but I'm not conviced :D

A month ago I talked with a Go developer, who uses it to build a real-time game server.

He told me the tooling is better than in every other language he encountered before, but 90% of his time is spent on writing code generators because of missing generics.

 

I feel like most of my defenses of people not liking Go will sound pretty much the same every time I have to defend it, haha. The fact is, there is plenty that Go can't do.. but it can't do it on purpose. Reach for the right tool, and when Go is easier to use in a situation, you DEFINITELY should. If it isn't, then don't be stubborn. Pick up the hammer when you need the hammer. I mention many of my issues with Go in the article, as well.

Also! I did mention that the devs on the Go project are considering implementing generics.

 

I just started playing with go a week ago and I'm liking it so far, it feels so light and the Donovan & Kernighan book helps a lot.

However, even as a beginner go feels like lacking in a lot of ways that I'm not going to go into.
It always amuse me the discussions about "we made go while waiting for a C++ project to compile" and how they target C and C++ when designing go. In real life, nobody from C and C++ is interested with go at all, people come to go from python, java, javascript... and that's a shame.

I'm very new go go, will try to keep on but again, outside of web stuff I don't think that go is the language that will power the 21st century!

 

Yeah, it was kind of a weird revelation when the industry saw who was actually interested in Go. Which is totally fine, honestly. Give it more than a week, and you may think more of it!

 

Go has implemented latency free garbage collection and fast compile times.

Completely latency free GC is probably not possible. That said the Go team did an impressive job bringing it down to a very low value (< 1ms) which you can read up on here.

Functions can be passed into other functions, returned, and declared as variables.

Higher order functions are really not unique to Go. The Wikipedia article I linked lists 21 languages that directly support it and I'd wager there a lots more.

Don't get me wrong, I think Go is nice enough for a particular subset of problems, but never since its first release have I felt that it actually deserves all the hype it's getting. I'd bet money on the statement that if Go hadn't come from Google most people would have ignored it. A good bit of the language feels like it was written to keep the implementation of Go itself simple, at the expense of people who actually code in it day to day. Just recently I had to do perform a little song and dance routine to iterate over a map in a pre-defined order, because a sorted map is not part of the standard library and lack of generics just means one unnecessary extra step

 

What I dislike most about go isn't the language, it's golang as an event in the world.
It distracts perfectly good developers from Rust, and for no good reason.

 

I don’t really agree with that. Research seems to show that no one really considers Go and Rust as competitors. They just came out around the same time. And I don’t think any language can ever be a distraction. It’s just another potential tool in your arsenal. Just know when to use it.

 

The snowball/network effect is extremely powerful, especially in tech, especially in new languages. Both of these are positioned to become the golden hammer for many nails, and I really dislike which way the scales tipped. Take for example important infrastructure like docker, k8s, and istio and especially performance critical traefik, etcd, dgraph, and influxdb.

 

Why isn't the second biggest con (garbage collector) listed?

 

The cons in the bottom don’t really mention garbage collecting being a bad thing, but in some cases automatic garbage collection isn’t good. For example, in video games you don’t want automatic and constant garbage collection.

 

Sorry, typo. I meant isn't listed.
One prominent project that fell victim to go garbage collection is deno, since they were embedding the v8 js vm, and had contention between go's and v8's garbage collection passes. They have since switched to Rust.

 

Thanks for the post and sorry in advance for being a pedant: "core tenet" not "core tenant"

 

Actually I appreciate it! Thanks