To me it's the fact that it's an alright language to build stuff in, but the tooling is hard to beat.<p>The fact that you can "go <command>" so many things so easily (build, run, test, etc.) beats almost every language out there. It makes starting new projects <i>really</i> easy. Personally, that's one of the main barriers I feel when I'm trying to start anything in other languages.<p>Consider Java (or Kotlin, for that matter). You need either a Maven POM or a Gradle build file. Gradle makes things a little easier with 'gradle init', but you're still stuck with arcane build files either way. If you have to use Maven and need any plugins... Good luck with that.<p>I think the general pattern here is that pretty much every language doesn't stand on its own when it comes to starting and working on a project. You need external build and dependency management tools. Go has it all built-in and it's super easy to use. It's beautiful.<p>Language-wise, I want a language that's as versatile as Kotlin, with the ease of use of Go. Imagine having a bunch of .kt files and just being able to 'kotlin build', 'kotlin run', etc. That'd be gold.
They mention two things in the article - speed and number of lines of code. Are either of them the most important thing in the average business code? Sure devs always like to get things faster just because they can, but in most business settings whether its java, .net, php, etc it really doesn't matter it will be just fine for the speed (considering its probably database calls, etc that are the bottleneck).<p>I would argue its more about code readability and maintainability than speed. Can I take a java developer and have him/her look at some Go code and know what's going on? For the most part I would say yes.
The nicest thing about Go is that the trade-offs are quite clear from the beginning, i.e. you know what you are sacrificing to seize the pros. The cons are usually excessive verbosity.<p>I'll add my favorite pros as well:<p>- the language is very simple and explicit, which makes it easy to understand third party code bases<p>- the spec moves very slowly (or not at all), which ends up protecting the investment that you make into your software in the long term
What's not so great about Golang:<p>-error handling is kinda ugly and verbose<p>-no generics<p>-interfaces are done through duck typing<p>-null pointers<p>-int size is platform dependent<p>-no built-in immutability
Personally I like Go for the same reason I like Clojure. It aims to be a simple (in the most positive sense of the term) and reliable language that avoids fanciness or complexity and has a good concurrency model.<p>Easy to learn and without much arcane hierarchies and easy to read and maintain. The longer I write code the more I'm drawn to simplicity as the most important thing about a language.
I am fairly new to Go, been a Gopher for about a year now, and I really like it a lot.<p>My background is Visual Basic, PHP, C and C++ and then C# and F# for the longest part. Coming from .NET Go feels like a huge breath of fresh air and brought the fun back into programming. What I enjoy the most is the simplicity (not to be mistaken with the language being “simple”) and the vibrant OSS ecosystem. With Go I feel like I’m actually programming again and solving problems. My focus is to deliver value. With C# I feel like 50% of the time is spent understanding everything around it and mastering .NET with the anticipation that the next project will benefit from my expertise, but before the next project has arrived the .NET landscape has changed significantly enough so that I’m yet again spending 50% of my time mastering the language rather than building something cool.
Go is simple and fast to use, but not so elegant under the hood, which is part of the cost.<p>Go is great for readability and changing of code, depending on the dev and time though.
TLDR;<p>- Simplified, familiar syntax for those who already know a C variant<p>- Concurrency model (CSP) which works nicely with the request/response paradigm of server communication<p>- Performance comparable to other statically compiled languages.