<p>I have programmed C++ many years and like it. Contributing to someone else's Go program, I am now learning Go.</p>
<p>Go seems fine. I can see that many like it, but I do not yet grasp its appeal. Can you explain to me why Go is interesting?</p>
<p>Go and C++ seem to differ in garbage collection, stack/heap management, RAII, reference counting, exception handling, concurrency facilities, modularization and (reputedly) compile time, perhaps among others; but the differences -- though indeed different -- have not yet added up to any compelling advantage for Go in my understanding.</p>
<p>I do not criticize Go. I am only trying to understand. Since I am now spending some time coding Go, it would help if I grasped the relative appeal or motive of this language.</p>
<hr/>**评论：**<br/><br/>hayzeus: <pre><p>The upside of Go is garbage collection, an actual concurrency model and language simplicity (I have about 20 years of C++).</p>
<p>The downside of Go might be garbage collection, depending on your application. For example, I wouldn't use it for anything but the softest of real time applications, and its really out for any kind of systems programming. All in all for raw computing power, well-written go will generally be slower than well-written C++.</p>
<p>But for, say, web services? You'd be nuts to write that kind of thing in C++.</p>
<p>Also I came to C++ from C and really missed the elegance of C. Go recaptures some of that elegance. This is really more just aesthetic, though.</p></pre>weberc2: <pre><p>I would also add:</p>
<ul>
<li>Go has reflection out of the box--this is a useful property for things like serialization/deserialization (I understand that C++ may have recently added some form of reflection, so this point may be less valid or invalid altogether)</li>
<li>Go's standard library is much more comprehensive</li>
<li>Go's build system is much more convenient</li>
<li>Go's tooling is much nicer
<ul>
<li>More readable compiler errors</li>
<li>There are no suitable C++ analogs for vim-go, and even getting something as straightforward as autocomplete is painful</li>
</ul></li>
</ul></pre>jussij: <pre><p>I would also add:</p>
<ul>
<li>No more header files</li>
<li>No more worrying about weird linker errors</li>
</ul></pre>metamatic: <pre><ul>
<li>Much faster compile times.</li>
<li>There's actually a standard way to build your application without needing additional tools with their own languages.</li>
<li>Cross-compilation and deployment are much easier.</li>
<li>Language doesn't take >5 years to learn and be proficient in.</li>
<li>Fewer language pitfalls. One of the reasons why it takes so long to be proficient in C++ is that you need to learn all the things to avoid doing. Even once you "know" the language, you've still got <a href="https://play.google.com/store/books/details/Scott_Meyers_Effective_C_Digital_Collection?id=U7lTySXdFk0C&hl=en" rel="nofollow">hundreds of things to learn</a>.</li>
</ul></pre>thepciet: <pre><blockquote>
<p>No more header files</p>
</blockquote>
<p>I miss them for sure, but not worth the compiler implementation leakage into the programmer's world.</p>
<p>Specifically there's something neat about a well described "thing in a computer" contained in a text file that fits on a screen. I'm not comfortable here in Go yet as readable code uses different patterns than in header languages.</p></pre>natefinch: <pre><p>This is what godoc is for... it gives you what you'd get in the header file.</p></pre>exasperation: <pre><blockquote>
<p>This is really more just aesthetic, though.</p>
</blockquote>
<p>I think it's than just aesthetics. The amount you need to learn to read arbitrary Go code is nowhere near as large as you need to learn to read arbitrary C++ programs. </p>
<p>The C++ standard is so large and supports so many styles of programming that at the extreme ends of styles, the "dialects" aren't really mutually intelligible. </p>
<p>It is also a moving, ever-changing target. I knew C++98 quite well, but C++11 is like a whole other language!</p>
<p>These are tremendous potential strengths, of course. <em>If</em> you have experienced and skilled C++ programmers, an organized engineering team, a software architect and management willing to impose a standard coding convention on the team. </p>
<p>For inexperienced programmers, for loose teams, for long-term maintenance by those, it's easy to get sucked into a complexity trap where different architectures are glued together inappropriately or turns into spaghetti.</p></pre>SandalsMan: <pre><p>I gave up on C++ after seeing things like this:
<code>
template <typename T>
inline T const& Max (T const& a, T const& b)
{
return a < b ? b:a;
}
</code></p>
<p>I somewhat understand what this is doing but there is just so much to know here.</p></pre>kl0nos: <pre><p>Rust is even worse.</p></pre>s-expression: <pre><p>Rust is much better:</p>
<pre><code>fn max<T>(x: T, y: T) -> T {
if x >= y {
x
} else {
y
}
}
</code></pre></pre>kl0nos: <pre><p>You are joking right? look at this:</p>
<pre><code> fn parse_request<'a>(bytes: &'a [u8]) -> IResult<&'a [u8], TrackerRequest<'a>> {
switch!(bytes, tuple!(be_u64, be_u32, be_u32),
(CONNECT_ID_PROTOCOL_ID, ::CONNECT_ACTION_ID, tid) => value!(
TrackerRequest::new(CONNECT_ID_PROTOCOL_ID, tid, RequestType::Connect)
) |
(cid, ::ANNOUNCE_IPV4_ACTION_ID, tid) => map!(call!(AnnounceRequest::from_bytes_v4), |ann_req| {
TrackerRequest::new(cid, tid, RequestType::Announce(ann_req))
}) |
(cid, ::SCRAPE_ACTION_ID, tid) => map!(call!(ScrapeRequest::from_bytes), |scr_req| {
TrackerRequest::new(cid, tid, RequestType::Scrape(scr_req))
}) |
(cid, ::ANNOUNCE_IPV6_ACTION_ID, tid) => map!(call!(AnnounceRequest::from_bytes_v6), |ann_req| {
TrackerRequest::new(cid, tid, RequestType::Announce(ann_req))
})
)
</code></pre>
<p>}</p></pre>s-expression: <pre><p>I'm not arguing that Rust is a clean language. I'm just saying that generics in Rust are a lot cleaner than generics in C++.</p></pre>FUZxxl: <pre><p>Except now I have to add a shitload of useless braces.</p></pre>s-expression: <pre><p>Yeah the lack of ternary in Rust makes this comparison a bit lame.</p>
<p>Though not having to sprinkle <code>const</code> everywhere is nice.</p></pre>mauroPic2: <pre><p>I think than this is a misconception...many languages are readables after a while...for instance, lisp languages are difficult to read at first instance but after a time you can find this more simple to use and read than any other language</p>
<p>sorry but deflate a language because it doesnt look nice at first is a newbie mistake</p></pre>jussij: <pre><blockquote>
<p>many languages are readable after a while</p>
</blockquote>
<p>Over the years I've coded in dozens of languages, including C++, but I've seen template code like that and it always leaves me confused :(</p>
<p>Why is it so confusing?</p>
<p>Consider the line of template code presented:</p>
<pre><code>template <typename T> inline T const& Max(T const& a, T const& b) { return a < b ? b:a; }
</code></pre>
<p>What the hell is this preamble trying to say:</p>
<pre><code>template <typename T>
</code></pre>
<p>Correct me if I am wrong but is that line of code only trying to describe is this action:</p>
<pre><code>const& T Max(T const& a, T const& b) { return a < b ? b:a; }
</code></pre>
<p>If not, what is the difference in those to lines of code?</p>
<p><strong>EDIT:</strong> As a comparison C# would use a syntax <em>similar</em> to the following which I think is a lot easier to read and understand:</p>
<pre><code>const& T Max<T>(T const& a, T const& b) { return a < b ? b:a; }
</code></pre>
<p>I spent decades coding C++ but these days I spend much more time coding C# and I find C# code is so much easier to read :(</p></pre>metamatic: <pre><p>That's exactly why the Go team are so wary of adding generics to Go. You might end up with horrifically complicated syntax like C++ and Java.</p>
<p>Also, you might end up with accidentally turing-complete compilations, like C++ <a href="https://arxiv.org/abs/1605.05274" rel="nofollow">and Java</a>, meaning your compile times are <a href="http://cpptruths.blogspot.com/2005/11/c-templates-are-turing-complete.html" rel="nofollow">essentially unbounded</a>.</p></pre>: <pre><p>[deleted]</p></pre>TheMerovius: <pre><blockquote>
<p>C++ templates and Java generics are not the same thing.</p>
</blockquote>
<p>That wasn't claimed by anyone. The claim was that a) both use "horrifically complicated syntax" and b) both are Turing complete. Both are true, to the best of my knowledge.</p></pre>boomshroom: <pre><p>That's why most gophers don't use go generate for generics, instead what they do is <em>not use generics</em>, just like what has been done for decades in C.</p></pre>s-expression: <pre><blockquote>
<p>they do is not use generics, just like what has been done for decades in C.</p>
</blockquote>
<p>This is not true. People use ad-hoc generics in C <em>all the time</em>. They just eschew type safety and make a big ball of crap using <code>void *</code> and <code>union</code></p>
<p>Just like Go programmers do with throwing <code>interface{}</code> everywhere</p></pre>KingCepheus: <pre><p>Throwing <code>interface{}</code> everywhere is not idiomatic Go.</p></pre>s-expression: <pre><p>It might not be considered idiomatic, but it sure is <em>everywhere</em>. Even the standard library uses <code>interface{}</code> as a poor-man's generic in many places.</p></pre>natefinch: <pre><p>Most gophers avoid interface{} like the plague. There are a few packages in the stdlib that use interface{} heavily - some are things like json, which need to be able to encode any value... thus interface{} is actually more or less correct. And some are things like the container packages that probably most people on the Go team wish hadn't ever been added to the stdlib. Certainly I've never see anyone actually use those ugly container libraries.</p>
<p>So, I wouldn't say it's all over. In fact, interface{} is very rarely used, and always scrutinized heavily when it is proposed, in my experience.</p></pre>KingCepheus: <pre><p><code>net.Context</code> and <code>sync.Pool</code>, and the <code>json</code> package are the only places I remember using <code>interface{}</code>. I don't consider that "everywhere."</p></pre>hayzeus: <pre><p>Yeah -- I worded that poorly. Obviously elegance is important. But for me the difference is mainly aesthetic (because I've had a lot of C++ in my past). </p></pre>IndianAlien: <pre><blockquote>
<p>spaghetti</p>
</blockquote>
<p>Seems like the majority of C++ codebases.</p></pre>Partageons: <pre><blockquote>
<p>well-written go will generally be slower than well-written C++.</p>
</blockquote>
<p><a href="http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=gpp" rel="nofollow">Benchmark confirms.</a></p></pre>kl0nos: <pre><p>Anyone know why Go b-tree implementation is so slow in this benchmarks?</p></pre>FUZxxl: <pre><p>Because it's a benchmark for the garbage collector which C++ doesn't have. The C++ example uses a custom allocator for the tree's nodes (cf. <code>NodePool</code>), further speeding up the program. I wouldn't say that the performance of the C++ implementation is typical for C++, obviously, a lot of thought went into it, way more than what goes into a typical C++ program.</p></pre>hayzeus: <pre><p>Also worth noting that regexes in go are very slow -- and this will be reflected in the benchmarks that use regexes (dna, etc)</p></pre>tmornini: <pre><p>And will also be fixed eventually.</p></pre>Partageons: <pre><p>Go is already <a href="http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=java" rel="nofollow">on par with Java</a> and it's only going to get better.</p></pre>tmornini: <pre><p>Except for the regex tests...</p></pre>Partageons: <pre><p>The Go FAQ provides excuses for <code>regex-dna</code> and <code>pidigits</code> benchmarks:</p>
<blockquote>
<p>The slowest depend on libraries for which versions of comparable performance are not available in Go. For instance, pidigits.go depends on a multi-precision math package, and the C versions, unlike Go's, use GMP (which is written in optimized assembler). Benchmarks that depend on regular expressions (regex-dna.go, for instance) are essentially comparing Go's native regexp package to mature, highly optimized regular expression libraries like PCRE.</p>
</blockquote>
<p><a href="http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=binarytrees" rel="nofollow"><code>binary-trees</code></a>, on the other hand...shame on Go. We're beaten by the likes of Erlang, Haskell, and Clojure.</p></pre>tmornini: <pre><p>Go is my future.</p>
<p>The gap between Go and the others will narrow, though it's currently plenty close for my uses.</p>
<p>And my point is simply that Go's regex libraries will improve -- and narrow the gap.</p></pre>igouy: <pre><blockquote>
<p>The Go FAQ provides excuses…</p>
</blockquote>
<p>Maybe that's out-of-date information.</p>
<blockquote>
<p>… pidigits.go depends on a multi-precision math package, and the C versions, unlike Go's, use GMP… </p>
</blockquote>
<p>One of those pidigits Go programs <a href="http://benchmarksgame.alioth.debian.org/u64q/program.php?test=pidigits&lang=go&id=1" rel="nofollow"><strong>does</strong> use GMP</a>.</p>
<blockquote>
<p>… comparing Go's native regexp package to mature, highly optimized regular expression libraries like PCRE.</p>
</blockquote>
<p>One of those regexdna Go programs <a href="http://benchmarksgame.alioth.debian.org/u64q/program.php?test=regexdna&lang=go&id=2" rel="nofollow"><strong>does</strong> use PCRE</a> (and has since 2012).</p>
<blockquote>
<p>the likes of Erlang, Haskell, and Clojure</p>
</blockquote>
<p>Maybe note the memory-use for those.</p></pre>FUZxxl: <pre><p>Go regexes are quite fast, the problem is that the benchmarks aren't using regular expressions, so they have to use the PCRE bindings in order to get the not-so-regular expressions required by the specification.</p></pre>hayzeus: <pre><p>This hasn't been my experience at all -- but then I'm still using Go 1.5. Hopefully 1.6, 1.7 (I'll probably upgrade when 1.7 is out of beta) have improved. </p></pre>FUZxxl: <pre><p>What package have you been using?</p></pre>hayzeus: <pre><p>regexp.</p></pre>metamatic: <pre><p>Because it hasn't had 25 years of optimization work.</p></pre>egonelbre: <pre><p>I guess the most interesting part about Go is that it's <a href="https://www.youtube.com/watch?v=4Dr8FXs9aJM" rel="nofollow">not that interesting</a> :D.</p>
<p>However more seriously, after several years of considering, the best feature of Go is how packages work. This might look like a small thing how you import and declare packages, but it has a large impact how you write code and how good code looks. Few important notions are: 1. you rarely use a single thing from a package (namespace), hence it makes more sense to import a package (namespace), 2. if you import a package (namespace) you don't need to include the package-name in the declarations, 3. this encourages packages related to core values (e.g. for web application "user", "page", "admin", "billing"), 4. core values are more stable than a particular implementation, 5. this means the purpose of the program is more visible from the code rather than hidden in accidental complexity. Basically the way packages work guide you to build better software and you get it more right from the first time. The way Go packages work have impacted my code writing more than any other language (and this includes Delphi, C, C++, D, Java, C#, Pascal, JavaScript, Prolog, Haskell, ASP, Lisp, Clojure, APL, Smalltalk ... and probably some that I forgot).</p>
<p>The second best feature is that it <a href="https://golang.org/ref/spec" rel="nofollow">fits in your head</a> -- i.e. the complexity of the language has never gotten in my way. This means that the language mostly disappears when you write code and you are left only with the problem on hand (obviously, not for all problems).</p>
<p>Of course there are nice tooling, great packages, language feels syntactically light... basically what other have said.</p>
<p>These features aren't exclusive, but you need to work to get them in other languages. For the first one, you would need to start to structure code in a way that may not be necessarily idiomatic in that language. In the second you need to pick some particular subset of a language.</p></pre>Logothson: <pre><p>You mention packages. I have never understood why C++ lacks proper support for packages. The conventional explanation is that "Inclusion guards work," but is this really an explanation? Maybe they do work, but they are just awkward -- awkward in a way other C++ features are not. Inclusion guards don't feel right -- and not only to me, but to lots of C++ programmers.</p>
<p>A C++ header is a purely <em>textual</em> device, used for a largely <em>logical</em> purpose. It seems to me that C++ ought to do a little better than that.</p>
<p>Nevertheless, I admit, inclusion guards do seem to work, so Go's improved packaging alone would not have sufficed to entice me to convert.</p>
<p>Syntactical lightness is important. I have programmed C++ long enough that I can actually read it, but one empathizes with the programmer who has spent a year or two coding C++ and still usually cannot read code others have written.</p>
<p>Thank you for your informative reply.</p></pre>egonelbre: <pre><p>C++ doesn't have modules because C didn't have modules. But it has been proposed several times (e.g. <a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4465.pdf" rel="nofollow">one of the latest</a>), so maybe one day. <code>#include</code> was used to work around the limitation of not having proper modules/packages, and it just stuck around and there are <a href="https://www.bell-labs.com/usr/dmr/www/chist.html" rel="nofollow">historical</a> reasons why <code>#include</code> was introduced.</p>
<p>Do note, it's not just "the grouping of things" in packages, it's also how they work together with other features and how the code evolves due to them. The feature-set guides to better code. It's really hard to explain... </p>
<p>I'll try to give a similar analog from C++, although negative. I suspect you have come across template nightmares and I'm not talking about the error messages. I mean once you introduce a template, it seems to infect other code near it with templates -- i.e. the human instinct is to keep template parameters around. Essentially you start with a small template and finally end up with a lot of type parameters everywhere reducing readability (e.g. instead of <code>Vector<Item></code> you could use <code>Items</code> or instead of making an <code>Set<Item></code> with tons of methods, you could make just a simple <code>ActiveItems</code> with few methods). This is a case where the feature-set guides you to keep abstraction around, which ends up reducing readability. <em>I'm not sure whether everyone has that problem, but I've seen that happen several times. (Just in case, I'm not arguing against templates.)</em></p>
<p>Go feature set has an infectious positive effect, somehow the instinct to remove repetition in names, not allowed to have circular imports, having implicit interfaces, multiple return parameters, no overloading, overriding/inheritance and no generics ends up causing to write clearer code (in the average case).</p></pre>nicerobot: <pre><p>My number one reason: its simplicity. I underestimated how big a deal it is. Then, after a few months writing nothing but Go, it hit me. I realized I wasn't having to think much about the language when coding. Unless you've experienced it, I think you might not fully grasp the significance of design simplicity.</p>
<p>I love languages and language design and I can be productive in C, Java, Scala, JavaScript, and Python and have read specs and toyed with dozens of other languages over the years, including C++. I don't particularly care about language wars. When it gets down to it, use whatever you like and are comfortable using or which have the best libraries/frameworks you need. Scala is fascinatingly academic and is still my go-to for running on the JVM. Java is a fine workhorse. Haskell can be fun and useful to force a paradigm. Lisp/Scheme provide a similarly powerful simplicity to Go but unfortunately few actually use them. I've mostly given up on JavaScript's idiosyncrasies because of Go. And I now always consider Go before I type any Python.</p>
<p>Don't think of Go as a feature-wise competitor to C++, nor anything else. I think of Go as freeing my mind from thinking about how to write a program to solve a problem. Instead, I spend more time thinking about how to solve the problem. That was my epiphany of simplicity.</p></pre>FUZxxl: <pre><blockquote>
<p>Don't think of Go as a feature-wise competitor to C++, nor anything else. I think of Go as freeing my mind from thinking about how to write a program to solve a problem. Instead, I spend more time thinking about how to solve the problem. That was my epiphany of simplicity.</p>
</blockquote>
<p>That's a very good point. I feel the same way when writing programs in C.</p></pre>nicerobot: <pre><p>:+1: I didn't mention it in my comment but I completely agree. C is a model of simplicity and I think the Go team did a fantastic job designing an "improved C". Not saying Go can nor should replace C, just that it's an improvement in many respects and without becoming a beast.</p></pre>IndianAlien: <pre><blockquote>
<p>And I now always consider Go before I type any Python.</p>
</blockquote>
<p>Pun intended? </p></pre>natefinch: <pre><p>A bug in your C++ program has the potential to allow callers to execute arbitrary code on your machine. Such a bug is generally impossible in Go.</p>
<p>In the small, I can tell you what any line of go code does, the amount of memory it's going to allocate, the general complexity of it, etc. This is impossible in C++. A simple line like <code>a = b</code> could go download a docker image from the internet.</p>
<blockquote>
<p>Go and C++ seem to differ in ... (reputedly) compile time</p>
</blockquote>
<p>What?! Go compile mongodb, I'll wait. Actually, I won't. It's a project approximately on the scale of Juju (they both have ~750,000 lines of code plus or minus depending on how you count). Mongodb, written in C++, takes 45 minutes for me to compile on my machine. Juju takes about 8 seconds. That's THREE orders of magnitude.</p></pre>FUZxxl: <pre><blockquote>
<p>Such a bug is generally impossible in Go.</p>
</blockquote>
<p>No. This can happen if you use the <code>unsafe</code> package or if there is a compiler bug or if you use cgo.</p></pre>natefinch: <pre><p>That's pretty much what I meant by generally. </p>
<p>unsafe is (surprise!) unsafe. cgo is C and thus unsafe. Compiler bugs... meh, I suppose - I'm not too worried about that.</p>
<p>What I was actually thinking of was race conditions that let you do bad things with partially written memory. This is one of the few known potential problems in Go (aside from things easily avoided, like unsafe and cgo).</p></pre>The_Jare: <pre><p>Easy to learn in its entirety, few or no gotchas, tooling, built-in concurrency, comprehensive yet easy to use standard library. </p></pre>Sir_Harry_of_Kane: <pre><p>Just like to point out that anyone with 10+ years of C++ is largely outside the target demo of go. </p>
<p>One of go's biggest advantages is how easy it is to learn. </p></pre>Redundancy_: <pre><p>goroutines as a standard unit of concurrency.</p>
<p>I love being able to write something that doesn't resemble a message handling main loop and to be easy take advantage of free cycles while calls are blocked.</p></pre>dgryski: <pre><p>talks.golang.org/2012/splash.article should answer a number of your questions.</p></pre>newimprovedoriginal: <pre><p>In the scenario where both Go, and C++ are unfamiliar to a developer, is Go easier to install, write a basic web server, compile, and run?</p>
<p>Aside from the GO_PATH GO_ROOT confusion of earlier versions, I found it very easy to get something up and running and could see the path forward. </p>
<p>With some other languages & stacks I've gotten lost in setup, and wasn't able to see a clear path forward.</p>
<p>Don't underestimate the power of simple & clean documentation.</p></pre>storm14k: <pre><p>That's been one of the biggest draws to me. There were many times especially with Java that I got so lost in setup and library entanglements that I lost interest in what I was working on. I like being able to open a plain text file and hammer out something in the direction of my solution. I fell in love with Python for this and then Go. In fact I didn't actually like Go early on until I learned Python and understood the beauty of both.</p></pre>Fwippy: <pre><p>In case this isn't a rhetorical question, yes.</p>
<p>Edit: Whoops, answered before I saw your edit.</p></pre>kaeshiwaza: <pre><p>Simplicity</p></pre>thepciet: <pre><p>After writing Bash, C, Java, Objective-C, some styles of assembly, some proprietary logic programming languages/interfaces, and seeing how network and database applications ideally solve many problems, and then deciding to make a game, I wrote an alpha game application in C++ by linking into the Ogre3D free and open source game engine.</p>
<p>I wrote a bunch of CMake after getting through just building and linking Ogre, and then a local C++ chess-like application with the engine.</p>
<p>Watching Rob Pike talk about build times and gofmt on youtube was enough for me. I'm currently working with Go for login/db/website/game logic (which can look very C-like) and calling into povray, which is a C++ command line application.</p></pre>int32_t: <pre><p>Some random thoughts:</p>
<ol>
<li><p>Go is very productive, close to the productivity of dynamic scripting languages. C++'s focused strength is certainly not in this regard. Also, I think compiler speed is one of the contributing factor of the productivity gap.</p></li>
<li><p>Compared with most scripting languages, Go is capable of taming the code complexity of large system gracefully. In other words, it's designed to scale over the size of the system, and the size of people working on it.</p></li>
<li><p>The <em>whole</em> system of a Go program is typically very penetrable. You can trace the code down to the bottom of the stdlib or even the compiler builtins in seconds with ease (thanks to the excellent Guru and vim-go). In my experiences of C++, I doubt how many C++ programmers have ever had a look to the implementation of STL or iostream, which is hard to do ergonomically.
Although some people occasionally call the opaqueness <em>encapsulation</em> and see it a good practice (which I don agree). </p></li>
<li><p>As stated above, the difficulty of static analysis of C++ has something to do with its freedom and complexity, which would prevent such useful analysis tools like Guru from happening. The closet thing in C++ world I can think of still needs building indexes before hand, which can be very time consuming for large code base, and is not so accurate if the code does some tricky things.</p></li>
<li><p>The overall coding styles are much more unified and consistent in Go ecosystem, as there is no <em>that</em> much choices. In C++, every library, framework and even application could be like having their own DSL as the best possible abstraction.</p></li>
<li><p>Following the above, integration of many third-party libraries in C++ is no as easy as Go. Their build systems are very likely to be different (CMake, Ninja, Makefile, autoconf ... to name a few). Much effort has to be spent in those housekeeping works.</p></li>
</ol></pre>s-expression: <pre><h1></h1>
<h1>Go</h1>
<p>Go is a language optimized for productivity amongst larger teams.</p>
<p>This has several interesting implications:</p>
<p>1) The language itself is very simple, from syntax and grammar to features and conventions. This means you can become effective with Go in a short amount of time.</p>
<p>2) The opinionated decisions made by the language designers resulted in a language in which it's very difficult to write non-idiomatic code. This means that you can easily read and maintain software written by others.</p>
<p>3) It has one of the most complete and useful standard libraries of any language, which is very impressive considering its young age. This means you aren't hunting down third-party libs to perform essential tasks.</p>
<p>4) In the cases where you <em>are</em> using third-party libs, it's very painless (extension of point 2)</p>
<p>On top of that, it has excellent tooling and a very good deployment story.</p>
<h1></h1>
<h1>C++</h1>
<p>C++ is a language optimized for nothing in particular. It's the culmination of 33 years of seemingly random additions to the C language, though it never removed any of C's shortcomings.</p>
<p>The language is intended for people who "know what they are doing" and are comfortable fighting with compilers to produce the perfect code for the problem at hand.</p>
<p>C++ is rarely the most appropriate or pragmatic language for a problem. However in areas where it is appropriate, it's basically the only sane option available. See: AAA games.</p>
<p>C++'s tooling is atrocious, but it's gotten a little better since the introduction of LLVM/Clang. This is mostly due to the insane complexity of C++'s syntax and grammar which makes writing reliable code comprehension tools very difficult. One must ask himself, if the task is so difficult for computers then what makes you think it would be simple for developers?</p>
<p>I don't particularly care for C++, though I've worked with it daily for the past 8 years. I don't believe that to be coincidental.</p>
<p>To the pragmatic developer, the problem domains of Go and C++ do not overlap. It's like comparing Go and JavaScript.</p></pre>TheMerovius: <pre><blockquote>
<p>but the differences -- though indeed different -- have not yet added up to any compelling advantage for Go in my understanding.</p>
</blockquote>
<p>Humz. Really? You just named everything that makes programming in C++ completely suck and said that go doesn't have it (oh, also: go doesn't have a lot of things, as opposed to C++, which is such a moloch of a language, that I'd legitimately claim that no one actually knows it).</p>
<p>I don't know. If you can't see the appeal in all those things, than maybe you are well-served with C++?</p></pre>
