

Less is exponentially more (2012) - MrBuddyCasino
http://commandcenter.blogspot.de/2012/06/less-is-exponentially-more.html
I was asked a few weeks ago, &quot;What was the biggest surprise you encountered rolling out Go?&quot; I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.
======
Wilya
I find it amusing that there isn't a single word about runtime performance in
the whole essay.

In the end, when I code in C++, it's because I believe my code will run faster
and generally use less resources, and I'm ready to accept the sacrifices it
takes (in terms of my own time) to get there. Does it make me someone for whom
software is about "doing it in a certain way" ? Probably. If that certain way
is "performance" for problems where it matters, I'm even proud of it.

C++ programmers don't come to Go because it turns out Go doesn't shine on
problems where C++ was the answer. Simple as that, and _there 's nothing wrong
with that_, as long as Go found its niche and solves some problems relevant to
him. I'm not sure I see why Rob Pike needs to be so dismissive.

~~~
easytiger
What gets me about MOST of the stuff I read on criticising c++ is the complete
disregard for runtime performance. I write software that has to consume
billions of messages a day per instance. I've done it in several languages for
different purposes. At the end of the day if you implement the same algorithm
in c++ it will be faster. I don't care what you think you can do in node.js,
but you are wrong. When you have limited resources there is no option save for
c and c++. It isn't a big deal, that is currently how we get things done.

People fucking around with distributed web applications are so immune from the
specific cost of adding a line of code because rarely is what they are writing
executed repeatedly in a tight loop and thus they lose the ability to quickly
measure performance impact

~~~
tlb
One programmer costs ~ 300 cores. (Bay Area salary with benefits vs. AWS EC2
pricing)

If your code consumes more than 300 cores, you should care about performance.
If your code consumes less, you should care about productivity.

Adding cores is easy while adding programmers is hard. Cores scale linearly
while programmers don't. So I set the guideline at 1000 cores. Do not make
performance-productivity tradeoffs below that.

~~~
anon1385
What on earth makes you think that all problems can be scaled out to as many
cores as you like? This is exactly the web developer mindset that people are
referring to elsewhere in this thread.

~~~
PaulHoule
Well you're trading one kind of B.S. for another kind of B.S.

There's a lot of B.S. that comes with C++, and there's an entirely different
kind of B.S. involved with writing things in Java + Hadoop.

Personally I stay out of the C/C++ ecosystem as much as I can because threads
are never really going to work in the GNU world because you can't trust the
standard libraries never mind all the other libraries.

The LMAX Disruptor shows that if you write code carefully in Java it can
scream. They estimate that they could maybe get 10% better throughput in C++
at great cost, but the average C++ programmer would probably screw up the
threading and make something buggy, and a C++ programmer that's 2 SD better
than the mean would still struggle with cache line and other detailed CPU
issues.

The difference between the LMAX Disruptor and the "genius grade" C++ I've seen
is that the code for the Disruptor is simple and beautiful, whereas you might
spend a week and a half just figuring out how to build a "genius grade" C++
program, taking half an hour each pop.

~~~
figglesonrails
Really, you're trading execution speed for productivity, not "BS for BS" when
you use these so-called "web languages". In some cases, there are other
concerns such as memory usage or software environment (e.g. trying installing
a Java program on a system than doesn't allow JIT compilations).

Some problems can scale out, but only if latency between nodes is low enough
and bandwidth is high enough. For example, an MMO server would not function as
well if there was a 50 msec ping between nodes. You may or may not have
control over that depending on what cloud service you use.

These are real concerns and should not be trivialized as "BS for BS" or "throw
more virtualized CPU cores at it". Every problem is different; it should be
studied and the best solution for the problem applied.

~~~
PaulHoule
I'm talking about parallel programming, in general, as a competitor to high-
speed serial programming.

In that case it is a matter of one kind of BS (wondering why you don't get the
same answer with the GPU that you do with the CPU, waiting 1.5 hours for your
C++ program to build, etc.) vs another kind of BS (figuring out problems in
parallel systems.)

Not all problems scale out like that, but you can pick the problems you work
on.

------
krosaen
"C++ programmers don't come to Go because they have fought hard to gain
exquisite control of their programming domain, and don't want to surrender any
of it. To them, software isn't just about getting the job done, it's about
doing it a certain way.

The issue, then, is that Go's success would contradict their world view."

This, "they can't handle how awesome it is" is kind of a fun rationale and
strikes me as plausible, but it would be more interesting to me to hear from
some of the stellar c++ programmers at google as to why they aren't interested
in switching.

C++ was the first language I really invested in mastering during and after
college - it was like, "all I need to do is read these 5 books about how to
avoid the pitfalls and use all the powerful tools, and it's amazing!" What
really changed my mind was trying other languages (first python) and seeing
how immediately productive I could be without so much as skimming through the
"dive into python" website. So specifically, I'd be interested in hearing
something from an expert C++ programmer who has really given go a try and
decided it's not their cup of tea.

~~~
smosher
I don't think it takes a C++ expert to point out that the more plausible
explanation is simply that Rob Pike is a narcissist.

This is the same guy who said you don't need to know what _I_ know (re:
endianness) because _you_ will never write a compiler. Consummate narcissism.

~~~
alecbenzer
Someone I know at google said he was once talking to Rob Pike about go and
asking questions about some of the design decisions. After answering a few
questions, Pike looked at him and said "Do you know who I am?". (supposedly)

~~~
WalterBright
I once questioned the design decisions for a particular project of the guy who
made them, and his response was "who the ____do you think you are? "

------
tinco
If C++ programmers were attracted to making their language more elegant and
safe yet more powerful at the same time they would have switched to any of the
statically compiled, typesafe, managed languages years ago.

If Rob Pike was doing things in C++ that Go could also solve, that means he
could've done them in C# or in Haskell too, which means he shouldn't have been
doing them in C++ in the first place. (Strousup explains why in his recent GN
keynote if you doubt that)

Of course solving that problem by inventing a new interesting language without
any of the (psychologic) baggage those other languages is awesome. It seems to
be rather succeful, but it's naieve to think that it would attract C++
programmers, there's just nothing in there for them. The C++ programmers who
are looking for change have more to hope for in for example Rust.

~~~
detrino
Its also completely subjective to call other languages more powerful or
elegant. For example, I think Haskell's lambda is less elegant than C++'s.

~~~
dbaupp
Haskell's lambdas are extremely elegant (\args... -> code, and treated no
differently to any other function), but C++ has a pile of other considerations
that Haskell doesn't have to worry about, due to Haskell's uniform
representation and garbage collection.

~~~
detrino
I think that functions and closures are fundamentally different types. Haskell
does implicit type erasure whereas C++ does not. Most of the time in C++ when
you use lambda you don't need uniformity and you are better off using
templates to pass them around. For the rare circumstances you do need this,
you just stick it in a std::function. Haskell also has mechanisms that could
handle this: type classes/parametric polymorphism/existential types and I
would find this a much cleaner approach, but it would wreak havoc with other
design decisions in the language such as currying. My main point of this is
that Haskell proponents often think of C++ programmers to be unenlightened or
wilfully ignorant, when its actually very possible they have thought things
out and simply reached different conclusions.

------
epi8
"C++ programmers don't come to Go because they have fought hard to gain
exquisite control of their programming domain, and don't want to surrender any
of it. ... The issue, then, is that Go's success would contradict their world
view."

No it won't! I'm excited about Go. What I've read about it makes it look like
a language I would love to work in, some day. However, I don't think the
problems I'm solving now are the problems Go is good at solving. The programs
I'm writing run on one machine with restricted memory, and they need to be
highly, highly performant. The execution time is measured in tens of
milliseconds, and during that time we do a lot mathematics and processing.
SIMD is our close, beloved friend. In that context, I don't think Go is an
appropriate language, due to its garbage collector, its lack of precise
control over where objects go in memory, and the overhead of method calls. But
if I ever write code similar to that written by Google, C++ would be a
terrible choice.

I was all on board with what he was saying until that last little jab. I'm not
migrating to Go because I have problems that Go doesn't set out to solve, but
I'm not threatened by Go, because it's just another tool. Having more high-
quality, carefully-designed tools is never a bad thing, and I can't imagine
ever being threatened by a new tool's success.

Honestly, this smacks of more divisive bullshit. Pythonistas vs Rubyists, VIM
vs Emacs, and now, Go vs C++. Blurgh.

~~~
MrBuddyCasino
So if your point is a technical one, whats the main issue for you - that you
can't emit hand-tuned SIMD code (I have no idea if thats possible) or that you
can't do realtime because of garbage collection? I acknowledge that the go
compiler has some catching up to do to become as fast as c++.

~~~
stelonix
I can't speak for him, but the issues that make Go not interesting at all to
me (and I believe, to a lot of other C++ coders) are automatic GC, lack of
generics and lack of template metaprogramming.

The thing with Go is that it is (was?) marketed as a system's programming
language. Go might work as a replacement for Java, but Java _is not_ for
system programming.

Whoever decided to say Go was capable of it either has no idea what systems
programming means or was being deceitful. Go can not replace C++; these
languages don't solve the same problems.

~~~
paddyoloughlin
As best I can determine, what you've just said is exactly how the article
characterises the criticism of Go from C++ programmers.

The article's argument, however, is that C++ programmers are wrong to presume
that those things are required for systems programming.

Interesting.

~~~
stelonix
Although we can wonder about how system's programming would work when you use
managed languages, the reality is that as of today (2013), system's
programming means low-level memory management, an almost transparent
translation from code to its lower-level counterpart (which, in 2013's
system's programming jargon, means the target architecture's machine code) and
most importantly _having as much control as possible_ over what your code
actually does. Having garbage collection as a language feature takes away
control, and system programmers won't be able to do their job with it.

It's fine to think of GC as "fast enough" in 2013, but that's when you're
working on things were speed/space isn't scarce. Go _might_ work out for
Google, since their "systems" comprise of tens of thousands of computers,
where reliability and maintainability are more important than latency. For the
rest of us C++ coders, we'll probably won't be able to replace C++ with Go for
the tasks where we need to do _systems programming_ , simply because we on
things that _require_ us to be control freaks.

Quite frankly, this post by Rob Pike saddened me, because it seemed like he
was desperately trying to counter the Go criticism with a not very well
thought out rant.

------
lnanek2
Well, he admits he was never very at ease with C++, so I guess he can be
forgiven for not understanding very few C++ programmers are going to jump into
a garbage collected language. If they were, they would have moved long ago.
Most of the times you need C++ nowadays are because a GC language simply won't
do.

Kind of silly he drew up his language based on one Google need and thinks
everyone using C++ should just jump aboard, though. He acts like he studied
why people were writing in C++ and took their use cases into account instead
of just his own. Kind of a stereotypical engineer who writes an app for
themselves that utterly fails in the consumer market because it is written by
coders for coders with weird controls.

~~~
rwmj
People use C++ in all sorts of places where having true garbage collection
would be better. For example, it's likely used to write the browser you are
reading this message on, and possibly the entire OS.

Since far better languages than Go have existed for many years, and those have
failed so far to attract many C++ programmers, I just think this is never
going to happen until C++ programmers themselves die out.

~~~
luikore
Using GC in C++ is rather simple, just use a GC-powered allocator and you
don't need to call `delete` anymore. But GC just doesn't matter so much. Many
forget-to-delete or delete-too-early problems can be solved by memory
analyzers. There are actually very few bugs that adding a GC can solve.

~~~
rwmj
This is why I said "true" garbage collection. Conservative GC ain't real GC.
GC isn't about eliminating bugs -- use valgrind for that -- it's about
increasing programmer productivity, along with all the other features missing
from C++ but present in modern strict strong-typed functional languages.

~~~
luikore
Conservative GC is real GC, it's just the tracing set happens to be the stack.
And I don't see why you can't use non-conservative GC for C++ allocators. It
only requires some work for read/write barriers.

GC is all about using `malloc/new` without thinking `free/delete`. With modern
C and C++ there are a lot of mechanisms for that (passing values, auto_ptr and
shared_ptr for example). In many cases a C++ programmer doesn't need to think
about `free/delete` either, and in some cases the non-determinism of GC
decreases the productivity too.

------
canthonytucci
For those who don't know who Rob Pike is, he's pretty awesome, helped create
UTF-8 among other things, and now works on Go.

[http://en.wikipedia.org/wiki/Rob_Pike](http://en.wikipedia.org/wiki/Rob_Pike)

He has given some really great Go talks which are available on youtube, about
an hour each:

Origins of Go Concurrency Style -
[http://www.youtube.com/watch?v=3DtUzH3zoFo](http://www.youtube.com/watch?v=3DtUzH3zoFo)

Lexical Scanning in Go -
[http://www.youtube.com/watch?v=HxaD_trXwRE](http://www.youtube.com/watch?v=HxaD_trXwRE)

Go Concurrency Patterns (One of my favorites) -
[http://www.youtube.com/watch?v=f6kdp27TYZs](http://www.youtube.com/watch?v=f6kdp27TYZs)

~~~
mcguire
He also may have invented Not Invented Here Syndrome. -
[http://en.wikipedia.org/wiki/Not_invented_here](http://en.wikipedia.org/wiki/Not_invented_here)

(NIHS was certainly invented at Bell Labs' CSRG, I'm just not sure of the
exact timeline.)

------
nfoz
Actually I've looked at Go and it seems like a really shoddy step forward (as
opposed to say D), but thanks for being so condescending about it.

~~~
tmbrggmn
It always amazes me when people try to somehow empirically prove that one
programming language is better than another. Sure, it's an interesting
question to consider as a thought-exercise, but is there really anything
valuable to be gained from expanding on this any further than that?

I've always though that, other than objective measurements of binary code
performance, whether or not you think a programming language is good is almost
entirely determined by its syntax and feature set. I feel no need to go around
the internet all day proclaiming my programming language of choice to be the
best and/or others to be inferior.

This reminds me of that link I saw on here a while ago titled "Why Go? Use
Racket!". Personally, my answer would be: because I find 9000 brackets in a
simple program to be poorly readable. However, I respect anyone who disagrees
and thinks the opposite. If it allows them to make great software and have fun
doing it: by all means go for it!

You apparently thought the write-up was somehow overly condescending to C++
programmers (I assume), while I personally thought it was the complete
opposite.

~~~
CmonDev
The tone of article implied that it is somehow expected that C++/Java
developers would come to Go. Well, no - there are choices.

~~~
59nadir
That tone is implied because that's what they thought when they designed the
language. He specifically says that exact thing... They were trying to make
development of the kind of projects C++ was used for easier and as such it was
a reasonable assumption that they would draw users of C++ to Go. He also says
it didn't really end up that way and explains why.

------
nimrody
We are all waiting for Mozilla's rust to mature. Rust seems more in-line with
C++'s "you only pay for features you use" and more general purpose.

I wouldn't use go for numerical simulations but it certainly shines for
writing network servers.

------
simias
There is one feature of go that prevents me for considering it when I want to
write "low level" code: garbage collection.

It's probably very silly but in my mind that puts it next to Java, above C and
C++ in the "grand scale of programming languages".

Oh, and also I don't like garbage collection, so there's that. I'm sure some
day someone will explain to me what's the point of it because I still don't
get it.

~~~
CmonDev
I think you should be given a choice whether to use GC. Now that's a killer
feature.

~~~
ori_b
That's nearly impossible to do well. The second you decide you want to use a
library that relies on GC, you need to turn on GC for your whole app.

There's no way to make that a local decision that I know of.

~~~
CmonDev
I don't know much about Rust, but they do promise "optional task-local GC,
safe pointer types with region analysis".

~~~
ori_b
So, while I'm far from an expert on Rust, that seems to me like they have
separate heaps for separate tasks, and heap values are not shared. So,
effectively, the tasks are roughly as isolated -- memorywise, at least -- as
different OS level processes.

This means that you can have different tasks that have GC turned on or off at
the task level, because a GC'ed object will never "leak" across a process
boundary. However, if you decide you want to parse JSON with your fancy new
GC-using JSON library, you either need to put that into a separate task, or
you need to enable GC in the task that calls into that library.

That means that if you want GC-free code, you're going to have to be very
careful about which libraries you can call into directly.

~~~
kibwen
That's a good point, and I bet that once Rust's ecosystem picks up it'll be a
major differentiator to be able to claim that a given library uses no GC
whatsoever (while also avoiding unsafe code, naturally).

FWIW, Rust's stdlib tries to eliminate the use of GC whereever feasible.
Cyclic data structures and persistent data structures are probably the only
places where GC will end up being necessary.

------
Mikeb85
C++ programmers don't go to Go because Go occupies the space otherwise taken
by Java.

The only real, modern alternative to C++ is Rust, but it's not at 1.0 yet,
meanwhile C++ is still getting new features, all the while preserving
compatibility.

~~~
pjmlp
Ada, D

~~~
TheLegace
Vala and Python code compiled to generated C code (gobject) seems like
interesting option.

Plus all these generated systems are standard and thus you can have different
languages linking each other.

------
penguindev
What really gets me about go is that it's lame, manual error handling sucks,
causing it to be smack dab in a middle area between my current languages of
c++ and python. If you don't believe me, note that golang.org's home page
example lacks error handling (huge fail).

In c++, I like the predictable destructor model of memory cleanup, and am
willing to pay the manual error checking price (too scared to write exception
safe code in c++). But I like to put as much complex logic in python code, due
to its nice exception handling and GC.

If GO had a more flexible exception model, which by the way does not require
forward jumping try/catch constructs, making it easier for people to write
'crash only' error handling without boiler plate, I might consider it. But for
me, it's currently typecast as a firmly middle of the road feature set.

~~~
acdha
That optional error handling still boggles me, particularly since
[http://golang.org/doc/faq#exceptions](http://golang.org/doc/faq#exceptions)
makes it clear that they undervalued the the other major family of problems
affecting C programs: programmers not checking return codes in often-
exploitable ways.

I can understand not going the full Java/C++-level overhead (although Python
is a great example of how that doesn't need to be so tedious in practice) but
it still amazes me that simply importing something you don't use is a fatal
compiler error but the classic "res, _ = something()" responsibility shirk you
see all over the Go world doesn't even get a warning.

Maybe Go 2.0 could make the compiler simply do the equivalent of inserting an
`if err != nil { panic("Unhandled error at FILE:LINE") }` block after any
statement which can return an error and doesn't already have a check. That'd
satisfy the low-overhead, predictable flow-control crowd while making the
language much safer for large systems in practice.

(n.b.: lest that seem like too harsh a condemnation, I actually rather like Go
as a highly appealing alternative to C: the fact that they got so many things
right — gofmt alone deserves a medal — makes the minimal error handling feel
like a surprising oversight.)

~~~
ansible
With a parser for Go in the standard library, it would be easy enough to write
a source scanner that looked for unhandled error returns.

~~~
acdha
This is true but that's a non-trivial task even before you get to the question
of running it on all third-party code and getting the upstream to patch it.
This would solve the problem only in the same way that static analysis tools
mean C code no longer has buffer overflows or type conversion errors.

------
mietek
Once again, Rob Pike speaks about generics and types in terms of C++ and Java,
without acknowledging any other languages with static type systems, some of
which are more expressive, less verbose, or both.

Surely Rob Pike is not ignorant of ML (1973), Ada (1980), Eiffel (1986),
Oberon (1986), Haskell (1990), OCaml (1996), C# (2000), and F# (2005)?

See also the comments on
[http://research.swtch.com/generic](http://research.swtch.com/generic)

~~~
mcguire
I just _have_ to quote Pike's comments:

"Early in the rollout of Go I was told by someone that he could not imagine
working in a language without generic types. As I have reported elsewhere, I
found that an odd remark.

"To be fair he was probably saying in his own way that he really liked what
the STL does for him in C++. For the purpose of argument, though, let's take
his claim at face value.

"What it says is that he finds writing containers like lists of ints and maps
of strings an unbearable burden. I find that an odd claim. I spend very little
of my programming time struggling with those issues, even in languages without
generic types.

"But more important, what it says is that types are the way to lift that
burden. Types. Not polymorphic functions or language primitives or helpers of
other kinds, but types."

1\. STL != generic types.

2\. Lists of ints and maps of strings are hardly an unbearable burden;
everyone and their dogs have been doing those in C for decades. But "string"
is a poor universal data type. "int" is even worse. On the other hand, if
"lists of ints and maps of strings" is your benchmark, you'll likely never
understand that.

3\. If you _can_ confuse polymorphic functions, language primitives, or
"helpers of other kinds" with types, you're probably doing something wrong.
(Polymorphic functions, disjoint from types? I think I get what he's saying,
but I need to ponder it some more.)

~~~
jfb
Pike comes out of a tradition, and his work is in some way the apotheosis of
that tradition. The issue is that people confuse the dogma they were raised in
with truth, and say stupid things like " ... To be fair he was probably saying
in his own way that he really liked what the STL does for him in C++."

------
jacques_chester
Most programmers aren't in the latest-language bubble. Hell, my main earning
language right now is PL/SQL, which limped out of the shadow of Ada, minus all
the interesting bits, clutching hideous licence fees.

The reason Ruby and Python programmers have embraced Go is because they tend
to be in the latest-language bubble.

The actual properties of the language are probably nearly totally
inconsequential, except as bright lights that attract a certain sort of mind
to it.

~~~
CmonDev
They probably work in start-ups or are free-lancers on small projects. Or they
work at Google.

------
nly
Less is more, but my ideal 'less' probably isn't your ideal 'less'. That's why
we need more... so we can all have less.

C++ covers many domains and programming styles really well. Just because it
doesn't cover some as well as some other language, it doesn't mean C++ as a
whole is a lost cause. This is true no matter how many domain experts and
language advocates attack it. It's C++s huge scope that opens it up to attacks
from every corner in the first place.

Frankly I'm getting tired of reading articles from people who think they can
proclaim "what C++ is about" any more than I can proclaim "what Go is about"
or "what Python is about". Even Bjarne himself admits he doesn't know all the
ways in which people use C++, and that's how he likes it.

------
debacle
I think a lot of programmers don't come to Go for the same reason that I don't
see myself ever using the language - it's far enough from a C-like language in
syntax and ideology that it's not easy to move from the C family to it, and it
has some "features" that I do not consider features. Those features make it
taste like an academic language, what isn't what I'm looking for in a
programming language.

Rust seems very different in that regard, and I look forward to being able to
use it in production when the time is right.

------
dbcfd
I'm a serious C++ programmer, and I'm also in the Rust boat, rather than the
Go boat. I've tried Go. More than once. And each time, I feel really
restricted. I feel like I have to solve problems a certain way, rather than
the way that fits the problem. With C++, I have multiple approaches to solve a
problem, and can choose the one that offers the best trade off of performance
and maintainability.

For now, if I'm really wanting concurrency, and don't feel like C++ is doing
what I need, I'll grab Java/Scala with Akka. They allow me to create a
solution tailored to a problem, rather than tailoring a problem to a solution.

------
luikore
A language which had aimed for system programing but not fast compared with
C++, now aims for web programing but still harder to use than script
languages, static typing but no generic types, forces boilerplate in several
aspects (exception, assertion) but no meta programing ability to help fix it,
weird design decisions dictated by personal experience, has Google helped
marketing but still not widely accepted.

------
nikic
Imho the main thing C++ offers are cheap abstractions. In C++ you can easily
build abstractions that do not have any runtime overhead at all. You can write
beautiful and general code and still not sacrifice a single cycle for it. Go
doesn't offer that, not in the least. As such I think that Go and C++ simple
have a very small intersection when it comes to use-cases.

------
bloodorange
"Less is More" works when you have fewer components but you can assemble them
together in various combinations to do everything you could otherwise do with
more components.

However, when you have fewer components which can't be combined to achieve
certain things that you could do earlier, it is hard to see how you can then
say "Less is More".

Coming from game development RAII is a blessing. Not having control of memory
deallocation is will not sell. This is definitely not a case of "Less is
More", it's a case of "Less is Less".

~~~
dbcfd
No RAII is one of the things that really bugs me about go. I can't just
construct an object and have it be ready, I have to remember to call some
other method. Rust's memory model is also better, since it's akin to shared
pointers (which you know the lifetime of) rather than garbage collection.

~~~
bloodorange
What I meant was that the way RAII works in C++ is a blessing and it can't
work the same way in Golang since it doesn't give us control of when the
object is destroyed. So, we are actually in agreement here.

------
pfortuny
So it seems that C++ programmers are a bunch of silly self-centered people who
cannot think as good engineers because somehow they have all been brainwashed
(probably by Stroustrup). That is how I read it.

Ah, by the way, did anyone mention garbage collection?

------
sigzero
"It seems almost paradoxical that other C++ programmers don't seem to care."

It probably doesn't scratch their itch.

~~~
masklinn
And it doesn't help that where it does scratch their itch it leaves a massive
bleeding wound the size of a plate.

------
jlarocco
I've tried Go for some small stuff and read through "Programming in Go". I
want to like it, but it just doesn't work for me. It's at an awkward position
half way between C++ and Python. Knowing both C++ and Python, I don't see a
convincing reason to use Go.

IMO, part of the reason C++ programmers aren't interested in Go is that C++
is, arguably, the most difficult language to learn. If you're really good with
C++ you'll figure out most other languages fairly easy, and probably already
know a few languages before going to C++. So I would expect most C++
programmers already have a "go to" scripting/interpreted, high level language
that they know and like. And in that case Go just doesn't offer anything they
don't already have.

~~~
justinhj
I don't think learning C++ would help you at all when trying lisp-like,
functional or logic programming languages. With its single oop model it
doesn't even help you with languages that have different or multiple object
models.

You also have a static type system so dynamic types are another thing to learn
about, as are lexical scope and closures.

After all the effort of learning C++ you've only really learned C++.

~~~
jlarocco
I wasn't really talking about the transferability of C++ knowledge to other
languages. The amount of effort to learn C++ is greater than the amount of
effort to learn most other languages. Whether that knowledge transfers to
other languages is another matter altogether.

The amount of time to become a C++ expert is far greater than to become a
Python expert or a Go expert. After spending a few years learning C++ spending
a year learning Go doesn't seem like a big deal, so why not learn it?

~~~
justinhj
I just don't agree with your statement "If you're really good with C++ you'll
figure out most other languages fairly easily".

As I was trying to illustrate there are a wide range of language features
available in other languages that C++ does not have anything remotely like.

It takes a long time to learn C++ not because the concepts are particularly
hard, but because the implementation of the language is rather messy and the
code you produce can easily do crazy things not apparent on the surface.

------
programminggeek
I'm not a C++ guy, but I will say the most interesting thing about Go to me is
that it's a smallish, clean, staticly-typed language that gives a great day-
to-day development experience. It also comes with a lot of nice tools for
formatting code, documentation, dependency management, etc.

Switching from Ruby or PHP is pretty easy because you get the same (or better)
developer experience with excellent performance and nice built-in libs. For
writing web services, Go is pretty much ready to roll out of the box.

I think writing Go is fun. I'm not sure that it matters why other programmers
do or don't like Go. I think it's great.

------
akkartik
Previous discussion:
[http://news.ycombinator.com/item?id=4158865](http://news.ycombinator.com/item?id=4158865)

~~~
MrBuddyCasino
Interesting how different the discussion went - minimalism as a design
aesthetic back then vs. c++ programmer outrage this time, all because of a
different title and abstract.

------
aurelius
TL;DR - Rob finally realized Go is a flop, and nobody wants to use it for
serious programming work. So, he whines about it, and blames C++.

------
api
For me it's not about the language. It's about pragmatics.

With C++ I can write code that builds natively using standard tool chains and
libraries on Linux, Mac, Windows, iOS, Android, and dozens of other less
common platforms.

With C++ I can write something once and then _ship it_ on all those things
without worrying (much) about the availability of tooling. If I write it using
portable programming techniques (mostly acquired through hard experience) I
will not have to do very much porting, and the #ifdef mechanism provides an
acceptable way to accomplish alternate code paths on different platforms
without compromising cleanliness of the build or performance.

C++ has its uglies, but it's not too bad if one knows it well and avoids
various also-learned-through-experience antipatterns.

Go is in fact better than C++, but it's not better _enough_ to justify the
hassle or the impact in my ability to ship across umpteen platforms.

This is why everyone still does systems programming in C/C++. Write (a bit
painfully) once, ship everywhere.

Other languages like Go, Ruby, Python, Rust, server-side JavaScript, various
functional dialects, D, whatever, always achieve success in two areas:
_specific_ ecosystems/platforms (e.g. ObjC on Apple, Haskell in the world of
high-speed algorithmic trading), and server-side coding. With server-side
coding who cares if you can ship, cause you don't. But all the world is not a
server, and sometimes you want to hit multiple user bases. For that, only C
will do.

I actually think a Go (or any other language) compiler that builds to cross-
platform C code with a _configure_ script _and_ a Windows build script would
be a worthy development. I know many people hate language-to-language
compilers, but this would enable one to write in nifty new language X, build
intermediate code, then build that intermediate code with the native tooling
of every other damn thing.

The other alternative would be for Google -- if it really wants to push Go --
to put a lot of effort behind porting it to offer good high-quality native
tooling for everything and everyone's toaster oven. But Google thinks all the
world's a server or a browser (and it is for Google for the most part) so that
doesn't seem to be a priority for them.

~~~
pjmlp
One way they could push it, would be to give first class support for Android
development, but I doubt it will ever happen.

------
qznc
Rob Pike did not aim to replace "C++", but "C++ as he used it at Google".
Looks like he succeeded at that. For those problems garbage collection is a
good idea (did the C++ guys try Boehm?) and compilation time is critical. From
the article: "We weren't trying to design a better C++, or even a better C. It
was to be a better language overall for the kind of software we cared about."

I agree with most of what Pike says until the end, where he derides C++
programmers:

"C++ programmers don't come to Go because they have fought hard to gain
exquisite control of their programming domain, and don't want to surrender any
of it. To them, software isn't just about getting the job done, it's about
doing it a certain way. The issue, then, is that Go's success would contradict
their world view."

This is just wrong. They do not come, because Go simply does not fit the
requirements. Go is more opinionated and targets a smaller niche than C++.
Nothing wrong with that. If Go and C++ both fit your requirements, Go is
probably the better choice.

The only language I know, which explicitly targets C++ is D, but it is not
there yet completely. Though, depending on your needs it might enough and it
is an improvement over C++.

~~~
kevinnk
> The only language I know, which explicitly targets C++ is D, but it is not
> there yet completely. Though, depending on your needs it might enough and it
> is an improvement over C++.

And Rust. Although it has its own issues as well.

~~~
qznc
When typing the comment, I actually had written a sentence about Rust and
later deleted it. The concurrency model of Rust is restricted compared to C++
and D: "lightweight tasks with message passing, no shared memory". However,
Rust has potential. Maybe. Interesting times. :)

------
Keyframe
Sometimes I feel like I'm the only guy that likes and works in C. Then I see
TIOBE index and alike and see C on top always. Are we, C programmers, not
vocal or are those metrics skewed in favor of 'legacy' and existing code?

~~~
figglesonrails
I like C quite a bit, but if I said, "I like C more than C++ or JavaScript or
Haskell", I'd be locked away forever. In a padded room. With nothing but a
BASIC interpreter.

i.e. nobody, but nobody says their favorite language is C anymore, they've all
found languages that have trade-offs, and most people don't need the trade-
offs C can provide. Parsing XML? Un-fun. Regular expressions? Un-fun. GUIs?
Un-fun. Hierarchical subclasses of actors? Un-fun.

------
rachelbythebay
In a corporate environment (particularly _that_ corporate environment), the
option of enforcing "we don't have to use the whole buffalo" exists. That is,
you can say "these parts of C++ are off-limits for this code base", and be
reasonably sure it will stick. See also: exceptions.

You could do that. Or you could go write a new language and further scatter
the masses.

------
bjoernbu
I'm currently a C++ programmer that does not intend to change to go because I
want to have exquisit control.

However, this is not because of my views or something like that but because
I'm only a C++ programmer at the moment, because I need that kind of control
for my current work. If I want to publish a paper or argue on specifics of
algorithms and data structues, e.g., like cache efficiency, it is highly
convenient to know as much as possible about what your code does in detail and
to have the opportunity to force a particular behavior.

The next time I'll be asked to get a complex problem solved somewhat
efficiently (I did write a lot of java code before starting to dive into C++ 3
years ago), I might look into go. But as long as the specifics of my solution
are "the job", I can still focus on getting the job done but choose C++ over
Go.

New C++ features are always nice, because I don't have to use them all and can
cherry-pick whatever is more convenient to achieve what I want

------
skriticos2
Somehow I miss the biggest advantage of C++ here: you can still maintain a 20
year old code-base without a complete rewrite.

------
hsmyers
I don't see this as an 'anti' C or C++ article. I see it as an effort to
explain (initially to himself) why the phenomena exists. Not sure I agree with
all of it but being a C/C++ programmer on micro-computers from the very
beginning, much of what is said resonates. I've pretty much be multi-lingual
from my start with IBM360 BAL (the programmers version of 'been down so long
everything looks like up :) ) That said when I was able to use C (actually a C
subset called BDS C [yes BDS does stand for Brain Dead Software]) I
immediately set aside PL1, Fortran, Pascal etc. Because I had found a HLA
(High Level Assembler) and was as happy as a pig in mud (how happy is that?).
That was in the beginning days of the S100 bus and therefore long ago. Since
then I accumulated many languages, somethimes for the hell of it (it looked
interested), sometimes because the client wished it and sometimes because it
was clearly the right choice. The one pattern I've maintained over all of this
time is to learn and test the language by writing a parser in it. Not a random
one, but a particular problem I was deeply familiar with. The parsing of chess
games. It usually winds up a middling tiny sized work of about a 1000 lines
and when done I've a reasonable idea of the workings of the language and more
importantly how hard it is to write parsers in. Why parsers? Because to
paraphrase the wisdom of turtles, 'It's parsers all of the way down...'

This winds up being a windy version of 'I suppose I'll have to try go to see
what's what'

------
eonil
Less is more. No data mutation. No ordered execution. Go Haskell.

------
kps
I have similar minimalist sympathies, taking as an ideal Antoine de St
Exupery's remark on aeronautical engineering, “Perfection is achieved, not
when there is nothing more to add, but when there is nothing left to take
away.”

The problem with Pike's work, as I see it, is that what it calls 'simple' I
see as unnecessary burdens layered on top. A text editor that makes you take
your hands off the keyboard? No thanks. I want to edit text, not pictures of
text.

------
geertj
Hopping on my soap box here.. I'd think that the word "exponentially" is used
incorrectly in the title. The trend to use cool math terms in everyday
language is a something that has been going on over the last few years. It can
be very expressive, but it's annoying when it's done in the wrong way.

Something cannot be "exponentially more" than something else. Something can be
a factor more than something else (if you have a measure). In this case, if
you want to use a cool math term, then you could say something is an order of
magnitude more than something else.

The correct way to use the adverb exponentially would be to apply it to a
development or a progression. For example, "Moore's law predicts that we'll
have exponentially more CPU power in the future", or "This problem gets
exponentially harder if the input size increases linearly". It applies to
something that changes with an ever increasing rate, not to any specific
values in time.

------
FigBug
I still use C++ since there still doesn't seem to be a better option for
creating cross platform GUI apps than C++ with Qt. Desktop Apps are no longer
'cool' and other than Qt there doesn't seem to be much happening in the
Desktop space. For scripting I use lua since it's a lot easier to embed than
Python.

~~~
epsylon
Isn't Python with PyQt any good?

(That would be my first choice if writing a web app is infeasible, but it's
been a while since I've followed the project.)

~~~
FigBug
I use it somewhat. The core program is C++ / Qt. The data is all serialized
using Qt data structures. Then I have python helper programs that read the Qt
data structures and generate reports. It's not the most elegant solution but
it was the easiest way.

------
raverbashing
C++ (and Java in a sense) are kind of a "local optimum" in terms of languages.
Go breaks from that, an it's good. It's not necessarily faster (or slower),
it's a different way of seeing things.

So C++ programmers think they need "all the speed" of C++ (ignoring all the
cases where it's being slower because of the added complexity that C++
programs end up having) and convincing themselves that's the "only true way"

In some aspects that's true, you really shouldn't go for something outside of
C/C++ in the embedded world usually (even though embedded systems are getting
faster, but there are several specialist systems slower than your smartphone)

But for most apps today? Thanks, but I would try alternatives first.

------
detrino
"C++ programmers don't come to Go because they have fought hard to gain
exquisite control of their programming domain, and don't want to surrender any
of it. To them, software isn't just about getting the job done, it's about
doing it a certain way."

Nobody can speak for all C++ programmers, but I think the biggest drawback of
a transition from C++ to Go is a lack of abstraction power. Not having
Generics/Exceptions/RAII is just painful.

------
CmonDev
"I believe that's a preposterous way to think about programming. What matters
isn't the ancestor relations between things but what they can do for you."

Similarly I can say: "What matters isn't the composition of things but what
they can do for you."

Also C++ and Java guys might be coming to Scala instead. Which is not owned by
Google.

What is the killer feature of Go that makes it significantly different than
C#/Scala or some other popular modern language?

------
RogerL
Performance is important in another way (I'm referencing the C++ vs go
performance discussions here, more than the OP). The more performant you are,
the fewer watts you burn. This means phone batteries last longer, and google
data centers require fewer power substations. It's a nontrivial concern at any
scale. I find blithe 'throw more cores at it' statements rather questionable
ecologically.

------
bliti
You cannot expect people to replace a language developed and polished over
decades with one that barely hit version 1.0. Go is fun to write, has some
good ideas, and is a little more readable (in idiomatic form) than C++. But it
is new. Once Go has the necessary libraries, and has been thorough tested,
then more people will look into it.

------
craigyk
What bugs me most about Go is that it is already filled with internal
inconsistencies, and since it practically demands idiomatic usage, these
aren't easily avoided. In C++ one can at least avoid using "bad" parts and
patterns.

------
saosebastiao
Sometimes you need complexity or extreme performance, and sometimes you need
it to stay out of your way. Go sacrifices the latter value for the former
value. D and Rust have far more potential to woo C++ programmers.

------
transfire
"We didn't figure it all out right away. For instance, it took us over a year
to figure out arrays and slices."

And that might be how long it takes me to fully understand the difference.

------
mseepgood
Didn't we discuss this already last year?
[https://news.ycombinator.com/item?id=4159703](https://news.ycombinator.com/item?id=4159703)

------
jamesmiller5
There is cgo which allows one to call into C controlled code. That to me is
best of both worlds, working in Go when I need to and memory control when
needed as well.

------
EugeneOZ
I'm very dissapointed in Go philosophy... Edpecially about RAII...

------
solomatov
I personally don't like go, because it doesn't have language features, which
must be included in any new programming language, I mean generics and
exceptions.

------
static_typed
Simple answer - if we wanted something slower than C++, then we already have
Java. If we wanted some more dynamic we have Python. If we wanted something
more Brogrammer style, we have Ruby, so what fit is Go good for?

~~~
pjmlp
To earn upvotes at HN :)

------
asdasf
>Go is, I believe, more expressive than C or C++

Really? Why does it always seem like everything he says about go is designed
to make people question his grasp on reality? There is no way to reasonably
argue that go is more expressive than C++. You might very well feel that the
huge increase in complexity that comes with C++ is not worth the comparatively
smaller increase in expressiveness, but pretending go is more expressive is
simply absurd.

