I don't see any "strength" in the classical object oriented programming model as found in C++ or Java. Actually, in modern programming composition is considered superior to inheritance.<p>The interface concept of Go makes programming with composition much more flexible and powerful than with the class model. The author skips this Go specific and original interface typing. This provides a multiple inheritance equivalent without all the complications on C++ and that most OO oriented languages forbid because of that complication.<p>Go is a very original language in this aspect as well as with concurrency. Understanding and mastering these properties goes beyond simple syntax analysis.<p>To me the most remarkable property of Go is its simplicity. As I explained to a friend who is a strong advocate of D, the difference with other programming language is the same as dealing with a spoken language of 1000 words instead of 10,000 words. It's true that the language with 10,000 words is more expressive and richer. But the effort required to learn, read and write a language of 1000 words is much lower than a with a language of 10000 words. I'm beyond 50 years old, and too me this makes a huge difference. The best way to express it is that <i>with Go programming is fun again</i>. I hope that Go will preserve this simplicity. At the beginning Java was simple too. They later killed it to the point I don't want to deal with Java code anymore.
I found the study very shallow and superficial. For example, who cares how many people have starred a project on github? And why should I care how many lines "hello world" is in a language [1]?<p>I would rather see a discussion about performance, platform support, maintainability, governance and do on.<p>---<p>[1] someone please create a new programming language where the empty file means "print hello world". Since you can't do any better than that it would once and for all put an end to this stupid benchmark.
The more I use swift, the more I've grown to appreciate the concept of Optionals and how the compiler enforces it's usage. I have found that my swift code is more robust and explicit than my ObjC or Android java code is, as well as the team members around me.
Swift: better OO, syntax, IDE;
Go: built-in concurrency;<p>Swift is a great joy for iOS development, where compatibility with Objective C makes things smooth, and operation queues are good enough for concurrency. Xcode is a big productivity booster. Good to break Swift's own backward compatibility with new releases to keep innovation, while providing a quick fix tool. Hope it will become a great server language too.
> Because concurrency is supported through an Apple API
rather than being explicit in the language’s design, using it is currently very
much coupled to iOS or macOS development.<p>I am not sure this is accurate, because libdispatch has been ported to Linux:<p><a href="https://github.com/apple/swift-corelibs-libdispatch" rel="nofollow">https://github.com/apple/swift-corelibs-libdispatch</a><p>They are "...early in the development of this project..." but server-side frameworks use it.
Semi-related, side-by-side comparison of how common things are done in swift and go:<p><a href="http://rosetta.alhur.es/compare/swift/go/#" rel="nofollow">http://rosetta.alhur.es/compare/swift/go/#</a>
Go feels like a beefed up version of C.<p>Swift feels like a high level language with static typing.<p>Interestingly, Swift doesn't feel much like Obj-C.
I favored Swift over Go in a small project (developed in my freetime) because it has template / metaprogramming support, and it calls destructors inmediately on unreferenced objects.<p>Some things that can be improved:<p>* It needs more support / packages for Linux (and Windows maybe?). I was using Manjaro Linux, and around November 2016 (dont remember exactly), the existing packages in the AUR didnt work anymore.<p>* No built-in weak collections.<p>* No source subfolders for the same project when using the buit-in package manager (I dont know about Go in this matter).
I use Swift every day and appreciate it a lot, while I have only cursory experience in Go, mostly because it didn't have any real debugger support in the past. But any comparison is rather shallow because at the moment they don't really address the same target usage, and Swift is only minimally supported on the server side where Go is generally used. Give it a couple years and the comparison might be more meaningful.<p>Once Jetbrains Gogland is up and running I will be playing more with Go.
The analysis looked good to me, but I was only able to read it after I downloaded it. I hate to be "that guy", but the Github pdf viewer brought Chrome to its knees.