Reference: Why Go’s design is a disservice to intelligent programmers
I honestly can’t decide if this article is sarcastic praise for #golang hitting every one of its design goals, because once you look past the ad-hominem crap, it’s there:
- “Similar to Go, the book is easy to read with good examples and clocking in at about 150 pages you can finish it in one sitting.”
- Read: Go’s easy to learn. The documentation is excellent.
- “I’ve always thought that the developers at Google are hand picked from the brightest and best on Earth. Surely they can handle something a little more complicated?”
- He misses the point entirely. Those same devs choose to go away from the frills to get leaner and faster. Code is a means to an end at Google, and they realize that it’s going to be read by other developers many times more than it’s written. Simplicity and clarity surmount all else; Google’s stultifying C++ style guide makes this apparent.
- “There are no shortcuts in Go, it’s verbose code or nothing.”
- Shortcuts get abused. See: C preprocessor macros.
- I read this as “‘I have to check return values and handle errors’ == verbose code.” This is not a valid Software Engineering view. IMO, it should be obvious whether code handles errors properly.
- “The language could be described as C with training wheels.”
-
Thanks! I rather like C. I just wish it had a decent Standard Library, no header files, less “undefined” behavior, inbuilt concurrency, package management, and garbage collection.
-
Oh wait, that’s Go.
-
Obligatory: Java is C++ with training wheels. That worked out rather well.
-
- “Their recommendation was to just copy the entire repository at that time into your project and leave it as-is.”
- This is known as ‘vendoring your dependencies’, and it’s a common practice.
- “There is [sic] no new ideas in the language apart from the concurrency support (which is excellent by the way) and it’s such a shame.”
- Unsupported assumption: Something must contain new ideas to be valid.
- “Concurrency support…is excellent.” Yes, it is. Loads better than the shared-state locking pthreads crap we’ve dealt with for 20 years.
Every fact in this article–aside from Generics–points to Go achieving its design goals. In a very backhanded way, TFA supports why people writing server-side code at scale should consider using Golang.
* * *
The summary demonstrates so many problems in our industry right now:
[Go] has been written for lesser programmers using an old language as a template.
Fellow programmers, can we get over ourselves, please? To categorically refute the above:
- On any given day, we’re all lesser programmers. For my part, I’m certainly not on all cylinders on 3 hours’ sleep in the middle of crunch trying to ship product. It’s no sin to want code that’s easy to reason about when you read it.
- Choosing something easier to read and sustain does not make you a lesser programmer any more than choosing to read Hemmingway in lieu of Shakespeare.
- Ah: ‘using an old language’. This is the heart of it. ‘Go’ isn’t cool, so let’s set it aside.
I find the above exasperating, simply because it’s the same naïveté that’s led to 1000 JavaScript Web MVC Frameworks, LISP fragmentation, etc.
As Software _Engineers–_if such a PE-worthy profession ever emerges–we must surmount simple fad and fashion and entertain what’s useful, evaluating on merit alone.