Nice read. I like Go a lot too.<p>As to the minimalism in Go, I wish it came with a few more default data containers.<p>Sorting a map by using a slice gets old after awhile. Why can't I pick a sorted tree based map (like std::map or std:set in C++) or an un-ordered hash based map like std::unordered_set, etc.? Why do the containers have to be so minimal too?<p>This just leads to people rolling their own and many times, that leads to poor performance and other issues which ultimately reflect poorly on the lanaguage. I've seen more string implementations in C than I can count. Most of them were bad. I hope Go doesn't end-up being like that.
After working with it for a year, these are the things I don't like about Go:<p>1) No constructors. When I create a struct, without a constructor, I can't be 100% if certain fields are populated or not. With a constructor, I could force this. With a large number of people working on a code base, you can't assume anything, unfortunately, but without a constructor to force exact data in a struct, it makes it more tedious to be sure.<p>2) Error handling is ugly and tedious. Not being able to get the type of an error makes it a lot more inconvenient. At least in our codebase, errors are almost string parsing, it's ridiculous.<p>3) Nil map vs empty map is a very strange thing to keep in the code. Why even allow this distinction?<p>4) Named return parameters are really stupid. This is another thing that doesn't fit the philosophy of what I understand Go to be. It forces a bunch of verbose opinionated rules on us, but then allows named return parameters which causes confusion.<p>5) It's very hard to tell the difference between package names vs structs. Luckily Gogland allows you to change the color for package names so this helps me out tremendously, but there should be a better way to differentiate without relying on your IDE.<p>Overall it's okay but nowhere near perfect and has some really weird deficiencies. The company I work for uses Go with dependency injection which I hate and I think is very ugly but a paycheck is a paycheck.
So far I fail to understand the excitement with Go.<p>Error handling in go feels like going back to 1960s programming.<p>Garbage collection is already implemented with high performance in Java and other platforms, what's new? You can use GC with different strategies in C++ as well, if you like, the libs are there. There are many libs to get dynamically managed memory in C. But the author wants to program for embedded devices and my choice there would be to avoid dynamically managed memory for the most part.<p>Coroutines and tons of different concurrency and multiprogramming and parallelism paradigms and strategies are already available for most mainstream languages.<p>Syntax in Go looks like a poorly done copy of Algol-68 (1968, and -surprisingly- a more powerful language.) Why?<p>At least if they would have went with s-expression syntax, they would have enabled metaprogramming and this would have solved some of the problems with missing features.<p>As for use in embeddable devices, the author discards D and other languages for lack of portability to other platforms; but AFAIK embedded devices programming goes to very low level details and thus I can't think how a code that is tied to the specific hardware would be portable, no matter what the language is.<p>I thought Google had smarter language designers. At least Mozilla did a decent effort with Rust. Perhaps Google do have smarter engineers and they actually use Julia, Lisp, and Smalltalk for Google's internal projects...
"Go is a better* C" It seems like Go is propelled into popularity by people discovering the joy of C/POSIX programming for the first time.<p>Some of us remember, however, why we left C behind (it does not work beyond a certain degree of complexity). Why would I want to do Web programming in C? We spent years creating better tools for this.
I love Go, but there needs to be some work around dealing with the problems the community is solving via code generation.<p>I feel like a lot of the things I find tedious about Go should be much easier to generate somehow so I can get on with what I was trying to do. sqlboiler is an interesting version of something that Go by-it-self can't provide without code generation if you require not using reflection.<p>Otherwise, I like the language a lot. I mainly love it's simplicity to deploy, good cli, and low memory foot print. I also like that it's very easy to read, that the community is focused on "reading code", and that there are many good libraries out there now in addition to the standard library.<p>Started looking at Scala recently, and I'll probably play around with it, but it just seems Go is so much nicer to use for the kinds of projects I'm trying to develop.
I agree that dependency management and GOPATH are two annoyances that need to go away. GOPATH in particular is a constant pain when you work across multiple machines like I do, and feels like a mandated anachronism/catechism (your workspace must be like we want it to, and we don’t care about your own methods).<p>On the other hand, lack of proper vendoring, version pinning and getting random versions of libraries off GitHub makes a lot of people anxious about long-term reproducibility.<p>Like a peer of mine once said, “maven is forever. They don’t call things ‘artifacts’ for nothing, I can even do archeology in my dependencies”.
> On the cost of some repetition here and there, it makes programs look very explicit, which helps readers to understand the code better, instead of wondering: can the exception be thrown here or not?<p>I don't get this. In practice, most functions end up having an error result by convention, so the answer to "can the exception be thrown here" is always "maybe", which is the same as the answer would be to any function call in a language with exceptions...
It's so strange seeing people who write these sorts of articles constantly praise Go's error handling. In what world is doing the whole if err != nil thing every 30-50 lines not ridiculous?<p>I get that goroutines are great, but that really seems to be all Go has going for it. The GC sucks, error handling feels like something from a bad language designed in the 70s, missing generics, math library is awful, Rob Pike being super opinionated, etc.
I often fell the same way about flag, recently I started using [go-args](<a href="https://godoc.org/github.com/alexflint/go-arg#example-package--MultipleMixed" rel="nofollow">https://godoc.org/github.com/alexflint/go-arg#example-packag...</a>) and so far I've found that it works a bit smoother.
Personally, I don't like Go. I wish my projects needed Rust's speed, or its safety, or its engineering powers.<p>But I don't. For simple parsing or number crunching, Go is just right.[1]<p>I find the fast prototyping, the wonderful IDE environment (VSCode, vim), and the community to be _so good_ that I don't need anything else.<p>There was a time I thought of learning Python[2] or Rust, but found both lacking.<p>[1]. Sure, I wish I was smart enough to get a job working on Quantum, working as a kernel dev, or in fintech where every nanosecond counts. But I'm not. The Rust community is great, there's a lot of help out there, and it seems like an amazing and cool language.<p>[2]. I tried it out a bit. My main issue is that it doesn't (didn't) have nearly as good of an IDE community (PyCharm is practically the only good IDE for Python, and in the bit of time I spent with it, I found it much less powerful than their Java IDE) revolving around it.
This is one of the more measured cases for golang I have read.<p>When it comes to my default set of tools, I gravitate towards dynamic, expressive languages that provide greater leverage rather than ones with fast startup times, c-like speed, native binaries, etc.<p>That said, when you need those things, I agree with this guy--golang has been a far better experience for me than any other language of its ilk. I'm not claiming it has magic powers like rust or a sentient type system like haskell, but I spent hours learning go fundamentals, and days figuring out how to get real work done with it. I can't say that for many other languages with go's compile and runtime capabilities.
Go is OK, but it was a bit mean of the authors to hijack an existing name for a programming language.<p>This was the pre-existing language:
<a href="https://en.wikipedia.org/wiki/Go!_(programming_language)" rel="nofollow">https://en.wikipedia.org/wiki/Go!_(programming_language)</a><p>Google reacted to the criticism saying there are many products named Go. Well... that's a 2-way street. If there are many products called Go then why picking that name in particular?
As a C-C#-C++-Java-ES2015+ guy, I found it hard to read and write in Go. :( Same problem goes for Python. (Not Ruby and CoffeeScript tho, I don't know why)<p>I don't think I'm alone. I need some hugs.
As I read this it made me wonder why I was still using Javascript to write my server code. Thing I always hated about it was the lack of types, and practitioners bleating to "write unit tests" instead. So much less efficient and effective. Even Typescript doesn't seem like much of a fix.<p>Go sounds like Swift, strongly type compiled languages. Go has better concurrency features and likely compiles faster (I mean anything has to compile faster than Swift).<p>Swift still seems to have better, faster garbage collection, better language features such as generics, and optionals make error handling and writing safe code much easier.<p>But Swift doesn't have the community and infrastructure around server development that Go does. I think I'm giving Go a go next project.
> Go is a better C<p>Setting the scale for language comparison to C (or Python) is setting the bar pretty low. There are so much better languages out there.
> no way to know whether the flag was given by the user or the default value was assumed implicitly<p>I'm struggling to find a need for this. Flags define behavior, who cares if the behavior is explicit or implied from inaction?
Personally, I've written a lot of stuff in Go, it might not be a perfect language but it's certainly the most fun one. I can sit down, write 1k LOC and have implemented something that I can look at in 10 years and still know what I'm doing.<p>It has it's downsides but I love it despite those, errors could be better but it's mostly fine and I'd love some generics so I could optimize my storage structures (though by using a backing array and referencing indices helps a lot)