Less is Exponentially More (2012)

https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html

by korethr • 8 years ago

145 75 8 years ago

commandcenter.blogspot.com

dahart2• 8 years ago

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.

For the first time, I think I'm motivated to learn Go. My big beef with C++ is there's no simple mode. Every single decision ever made in the syntax and libraries is geared for only the most complicated, high performance needed situations.

My problem is that 90% of my C++ code doesn't need performance at all, and could be Python for all I care.

To be fair, some of the modern changes are bringing some simplicity back. But, it still feels like wading through mud to write what should be easy things like file i/o, compared to Python or JavaScript. Using hashes and mixing hashes with other containers is so verbose and nit-picky in C++ compared to today's scripting languages that I just long to mix languages most of the time I'm writing general C++.

mynegation• 8 years ago

There is easy mode. It is called C. I am not trying to be flippant. A lot of people started in C++, writing essentially C code and then going to classes, inheritance, templates, wider usage of standard library and boost, little by little.

dahart2• 8 years ago

I’d agree with that, and I’ve done lots of object oriented C. But fwiw, that’s not quite what I meant. You can’t get away from pointers in C, and easy mode should be as pointerless / loopless / functional as possible, like what STL is doing now but simpler and even less verbose. Arduino style C is super fun though...

bitwize• 8 years ago

But you're not supposed to program that way in C++ at all. Ask a veteran C++ programmer, and they'll tell you that buck n00bs should start out using the STL, smart pointers, and generic algorithms, make sparing use of inheritance, and never touch bare pointers.

eadmund2• 8 years ago

C's not really easy mode, either. When I look at all the Unix utilities written in C, I want to weep, because it made things like buffer flows & other security flaws such attractive nuisances. C is easier than C++, certainly, but it's still a pretty rotten language to actually write code in.

And I write that as someone whose second language was C, and who loved C with a passion, for many many years. I didn't realise how much I was fighting the language, and I didn't realise how much in any C program the trees of incredibly verbose C-isms obscured the forest of what I was actually trying to do.

gowld2• 8 years ago

If you don't need performance, just use Java where everything works fine and is easy to understand.

kamaal2• 8 years ago

>Every single decision ever made in the syntax and libraries is geared for only the most complicated, high performance needed situations.

This.

The very first C++ code base I worked on was a monolith pile which had some thing like 50 features. There fore when you assemble something like that into a monolith your abstraction hunger kicks in and you run into all these crazy inheritance or template based work.

These days people don't seem to write stuff as such huge monoliths. And Microservices architecture has become quite a thing now.

Absence of many features in Go feel more like a positive than a negative. You get to eliminate a lot of complexity by default.

RcouF1uZ4gsC2• 8 years ago

A counterpoint is that more can be simpler when it allows better abstraction.

For example, calculus is more complicated that arithmetic and algebra. However, calculus can unify and show relations between different algebraic representations. For example, when I learned physics in middle school, I thought that remembering

delta position = velocity * time

but struggled with

delta position = initial velocity * time + 1/2 (acceleration * time^2)

When, I learned about derivatives and integrals, the formulas all made sense.

In my opinion Go suffers from the ability to abstract which is most represented in its lack of generics. Instead, of being able to represent operations in a generic way, you are forced to cut and paste, and cannot express the relationship accurately, much as how I considered the relationship between acceleration and position to be opaque before I understood calculus.

barrkel• 8 years ago

That formula makes sense when you draw a velocity vs time graph and realise the area under the curve is the distance travelled. With linear acceleration, the area is a rectangle with a triangle on top, and everything starts becoming clear, even without calculus.

kbwt2• 8 years ago

You can also visualize the meaning of d/dx x^n = n x^(n-1) geometrically: There are n faces being extruded which contribute a volume of x^(n-1) dx each.

vinkelhake2• 8 years ago

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.

Yeah, because it cannot possibly be that many C++ programmers saw Go as step down.

Pike thought that C++ programmers would flock to Go in large numbers. That didn't happen, which means that Pike didn't really understand what motivated these C++ programmers. I don't think this summary gets that much closer to the truth.

AceJohnny2• 8 years ago

Yeah, because it cannot possibly be that many C++ programmers saw Go as step down.

You just paraphrased his point.

vinkelhake2• 8 years ago

I realize that it might sound like that. But I would paraphrase his point like this:

"C++ programmers spent a ton of time learning C++ so they're not going to switch to a language that isn't C++"

Which is basically saying that none of the design decisions that went in to Go matter to C++ programmers because at the end of the day, Go isn't C++. Which in turn is pretty damn uncharitable towards C++ programmers. A lot of technical criticism was offered, but it's easier to ignore that and focus on something you cannot change.

WesternStar• 8 years ago

So what are the best examples of large programs written in go?

chewxy2• 8 years ago

kubernetes, docker

btym• 8 years ago

etcd, kubernetes, docker, rkt, grafana, cockroachdb, elastic beats

agumonkey• 8 years ago

not sure if it's large but some pentesting framework went from ruby to go. devs seem to like the language enough to rewrite it all, also, performance benefits have inherent value for non small handling of lots of network events.

jbarham• 8 years ago

NSQ: http://nsq.io/

executesorder66• 8 years ago

To add to the other comments: syncthing is another project that I use all the time, and it is written in Go.

peterevans3• 8 years ago

Huge caveat: This article was written in 2012. So do yourself and fellow reader a favor and not argue over content that is now six years-old.

Obviously, Go has not replaced C++ usage. And, these days, I would see Rust as the more likely step from C++.

(Although, I still feel that it remains to be seen whether Rust will make a huge dent there; is memory-safety the killer-app feature that makes people want to use Rust? Do enough people feel that they Need To Use Rust to make it stick? I'm interested to see how that plays out.)

What Go has done, I think, is replaced interpreted language use (PHP, Python, Ruby) in backend code. Which makes sense, to me--those are already GC languages, so you're pretty familiar with the lay of that land. Generics may not make a huge deal for you because there were no generics to use in those other languages. And Go is quite a bit faster than any of the aforementioned interpreted languages.

stochastic_monk• 8 years ago

I think Rust will stick. Until its metaprogramming abilities can match or outpace C++ and be as fast, it won’t replace C++. I do expect it to replace a lot of Java use cases, and perhaps some Go.

sanderjd3• 8 years ago

Generics may not make a huge deal for you because there were no generics to use in those other languages.

While this is technically true, in practice it is a good deal easier to create generic data types in those languages because you don't have to switch back and forth between type-world and no-type-world.

peterevans3• 8 years ago

Sort of--you get dynamic types, so you can stuff whatever you want into your collections. You can do that in Go, too--just use interface{}. Sadly, that has not quieted the Generics Brigade.

If you used arrays in PHP, or Ruby, or Python, you can get those--with static typing!--in Go, either with slices for sequential arrays, or maps for associative arrays. I think that satisfies the vast majority of collection use-cases that arise in practical applications of those three languages.

(Note: I think generics would be a Good Thing for Go, and I think they'll probably happen at some point. They keep doing user surveys, and the user surveys keep bringing up the lack of generics as one of if not the number-one issue that users would like to see addressed.)

nordsieck• 8 years ago

What Go has done, I think, is replaced interpreted language use (PHP, Python, Ruby) in backend code. Which makes sense, to me--those are already GC languages, so you're pretty familiar with the lay of that land.

One of the less talked about reasons Go is successful at replacing these languages is the devops story - essentially no runtime dependencies.

candiodari3• 8 years ago

This can be easily done in C and C++, by static linking. In java, by building custom jars. This is in fact common practice in large companies, for exactly the reason you mention.

segmondy2• 8 years ago

Go has replaced C/C++ in some circles.

Go look at most recent go projects. Kubernetes will never have been done in PHP/Python/Ruby. It would have been a Java or C++ project. Same with cockroachDB, Docker, Etcd, Fleet, Lime, InfluxDB, Prometheus, etc.

marcosdumay• 8 years ago

is memory-safety the killer-app feature that makes people want to use Rust?

There are algebraic types with pattern matching, sane generics, actually good type inference, strong types that will help you declare behavior only once (as in normal vs. modular arithmetic), and a huge push for not having undefined behavior (that is mostly but not completely successful).

Any of those (and yes memory safety) would be enough of a killer feature on my view. There are still some things I dislike in Rust, but compared with C it's a complete no-brainer.

shalabhc• 8 years ago

"Programming in the large" is mentioned a few times in the article but we're still thinking programming one OS process at a time, fiddling with low level data structures - is this really 'in the large'?

chewxy2• 8 years ago

programming in the large in the sense of many people being involved in a large program

dang• 8 years ago

Linearly more discussions at https://news.ycombinator.com/item?id=4158865 (2012) and https://news.ycombinator.com/item?id=6417319 (2013).

emtel3• 8 years ago

Rob Pike's confusion about why C++ programmers didn't want to move to go is partially explained by his focus on a particular problem domain at the time Go was being developed. Google in those days was primarily concerned with writing highly concurrent request processing software, and at that time the vast majority of that software was written in C++. Writing highly concurrent C++ in the days before the language had things like lambdas, std::function, std::future, etc was definitely gross. In practice, a lot of the concurrent C++ code from that time period took on the callback-hell flavor of node.js code, but without the concise nature of JS. It was gross.

Go is obviously a superior language to C++ for writing concurrent programs in every way except possibly when you need to achieve maximum possible throughput (as in google's search clusters) or minimum possible latency (are HFT shops switching to go? I honestly don't know). However, outside of a few companies that have huge capacity problems, people weren't writing concurrent request serving programs in C++. They were using Python, Java, etc., and later, Node.js. So its no surprise that people flocked to Go from those languages and not C++, because there wasn't a huge population of C++ programmers in this problem domain looking for a better language in the first place.

The other C++ programmers were down the hall, working on Chrome and Android (which has a ton of C/C++, despite Java being the primary app development language). The reason they didn't, can't, and won't switch is that managed languages like Go are not well suited to highly resource constrained environments like phones, or browsers that are supposed to run on win XP machines. (To say nothing of games).

The advantage of C++ is not, as Pike pompously suggests, that C++ programmers have too much fun playing around with templates and other navel-gazing pursuits. The advantage is that it is a high-level language that lets you do what you need to do with very, very close to the minimum possible resource usage. And there are programming environments where that really matters, and those environments are never going away.

segmondy2• 8 years ago

I don't think I will say that's the advantage of C++, but rather the perceive advantage of C++. Anytime I've met a great C++ programmer, they start off by ratting of a list of C++ features they don't use.

Retra3• 8 years ago

At my work, we don't use the standard library and we don't use references. And it's the only C++ code base I've ever liked working on.

millstone2• 8 years ago

I agree your points regarding C++, but it's not true that Pike was focused on the request-processing niche.

Go was specifically designed to be suitable for programs like web browsers, compilers, IDEs, maybe even OSes. We know because Pike said so - see the "Systems Language" page at https://web.stanford.edu/class/ee380/Abstracts/100428-pike-s... (warning, PDF).

emtel3• 8 years ago

I know Pike _said_ that, but I think the differing level of success of the language in these different niches speaks louder.

In particular, I think the idea that anyone serious is going to build a large desktop application like a web browser in a language that doesn't expose OS-level threads to the programmer is pretty laughable. Similarly for the idea of building an OS (or at least an OS kernel) in a garbage collected language.

edit: I realize I didn't really respond to your point. My point is that regardless of what Pike said, request processing permeated the atmosphere at Google, and deeply influenced the design of Go, whether Pike realized it or not at the time.

geokon2• 8 years ago

Being a C++ dev, I think you're on-point about the reason people still choose C++ but my suspicion is that it part truth, part group-think and it won't really hold out.

I could be totally wrong, but have you had to optimize a tight loop in C/C++? It sucks and a lot of stuff is missing : simd, likely/unlikely branches, the compiler has a lot of trouble knowing when lines of code are independent and can be done in parallel (b/c const =/= immutable), in-lining can't be forced when you know it gives better performance (if you use GCC extensions you can alleviate a lot of this..but that's tying you to a compiler). Yeah C++ is generally faster than Go, but there is a lot of performance typically left on the table. The language kinda start to work against you when you start to dig down. So you slap some shit together and the compiler will do a decent job, but most C++ devs aren't even looking at the compiler output

But the elephant in the room is that more and more of our available flops are on the GPU and C++ isn't helping you there at all. Not only that, but the GPU is giving you way more operations per Watt (and that's what a lot of those people care about). And finally, when you throw stuff onto the GPU you are also leaving the CPU available to do other things. So there are a lot of "wins" there. As you illustrate, the areas of C++'s relevance is shrinking, and shrinking into the area that is very GPU friendly.

So the way I see it, C++ folks will start to write more OpenCL kernels for the performance critical pieces and the rest won't matter (Go or Clojure or whatever). The GLSL is kinda lame and too C99ish... so maybe someone will write a better lang that compiles to SPIR-V, and it's not exactly write-once-run-everywhere, but it could be much better than writing optimized C++ and it can run everywhere. It's more of the cross-platform-assembly C/C++ wants to be

yuushi4• 8 years ago

SIMD

Intrinsics are directly callable from C++.

likely/unlikely branches

Most compilers have extensions that will allow you to do this (__builtin_expect and so on).

in-lining can't be forced when you know it gives better performance

Again, most compilers have this, not just GCC, e.g. __forceinline.

the compiler has a lot of trouble knowing when lines of code are independent and can be done in parallel (b/c const =/= immutable)

This is true, as aliasing is a real issue. The hardware itself has some say over this anyway, dependent on its instruction scheduling and OOE capabilities.

What you don't mention, however, is the fact that almost no other languages offer any of these, let alone all of them. Rust may be the exception here, although some of this is still in the words (SIMD, I'm not sure about the status of likely/unlikely intrinsics).

For GPU programming, if you're using CUDA, you're almost certainly using C or C++, or calling something that wraps C/C++ code. Not everything is suited to GPU processing anyway, there's still a lot of code that's not moving off the CPU any time soon that needs to be performant.

emtel3• 8 years ago

These are all good points, but I'd say two things:

1. Whatever C++'s weaknesses in this area are, it's superior to Go, so C++ programmers aren't going to switch to Go because of this.

2. Not everything is about raw throughput. You can't do anything latency sensitive on a GPU. Consider a game: the pixels get drawn on the GPU, and the physics might happen on the GPU, but you still have a ton of highly latency sensitive things that are going to have to be done by the CPU, such as input handling and networking. Also, even with low driver overhead APIs like Vulkan, you still have to have something on the CPU telling the GPU what to do. Finally, GPUs aren't good at branch-heavy workloads in general.

alexandercrohde• 8 years ago

I guess I don't get it. I agree the abstract idea that a simpler solution is usually preferable. But I don't see how this translates for a language like C++ or Go.

I understand the backlash against "magic," but this more a concern of "spooky action at a distance" rather than overhead.

Could somebody who understands the sentiment help articulate what type of solutions can be more easily expressed in Go than in say Scala (short of performance-centric cases? Or is this solely about performance-centric cases?).

Veedrac• 8 years ago

The claim isn't that it helps specific things, but that the more detail work you have to do, the less attention you can pay in the large. This is why, for example, Go has the proverb "a little copying is better than a little dependency"; you make a downpayment in the small to make your architecture cleaner.

This is something C++ makes exceedingly difficult (Linus Torvald's famous rant is half on this topic). This is also something Scala doesn't do well at, opting to provide a lot of features that make bits of code "prettier" at the cost of being able to see what is being built.

mark-r• 8 years ago

Is it coincidence that this is up on the front page at the same time as "C++ Core Guidelines" (rules for modern C++) and I started reading this just after glancing at that? The churn and complexity introduced into C++ in the name of simplicity is simply mind-boggling.

xg15• 8 years ago

I'm one of the people who never understand the absence of generics in Go and, to be honest, I don't find his reasons here very convincing.

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. [...] 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.

Does he suggest we write containers from scratch every time we need them? There is a lot of nontrivial logic, which I'd prefer not to have to get right again every time. (Not to mention that would feel very much the opposite than "programming in the large")

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. [... long rant why types are for mediocre people and interfaces are awesome... ]

I very much agree that interfaces are awesome and composition is way more useful than inheritance, but what does that have to do with generics?

If you have a function that takes a list of things and returns another list of the same things in sorted order, wouldn't you still want to have a way to keep track that the returned list contains the same things as the list you passed to it? That seems independent of whether the things are specified through types or interfaces.

Languages primitives for containers are a good idea, but the way Go eventually implemented that (hardwiring the few most-used containers into the language and making it really cumbersome to use custom containers) seems very unsatisfactory.

Less is Exponentially More (2012)

Related Stories