20 ms·

Less is exponentially more (2012)

238 points by MrBuddyCasino 13y ago

I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" 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++.

raverbashing 13y ago
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.
sigzero 13y ago
"It seems almost paradoxical that other C++ programmers don't seem to care." It probably doesn't scratch their itch.
- masklinn 13y ago
  And it doesn't help that where it does scratch their itch it leaves a massive bleeding wound the size of a plate.
krosaen 13y 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. 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.
- fein 13y ago
  > C++ was the first language I really invested in mastering during and after college This is partially why you picked up Python so easily. It's one thing to approach a language like Python as your first, but if you took the dive and learned c/c++ prior, everything else is going to be much easier to grok.
  - krosaen 13y ago
    Yeah good point, impossible to forget what it's like not to know something. I also haven't done systems programming in a long time - so it would really be more fair to have someone comment who is considering a language under higher performance constraints. That said, I can report on what I prefer right now, knowing what I already know (having spent 4 years programming java professionally as well) - and I truly prefer a more functional approach that comes a lot more easily in languages that support closures and first class functions. It also strikes me that many of the best practices in java / c++ are basically moving towards more functional programming (prefer composition to inheritance, make objects immutable by default, interfaces over classes when possible, dependency injection / referential transparency and parameterizing methods by interfaces e.g functions).
- H3g3m0n 13y ago
  I'm not an expert but in the gamedev domain, control over memory is fairly vital. It seems like it would be for lots of the other stuff C++ is used with too. In C++ I can allocate all my memory upfront in a pool since I know the exact size of my level, the number of objects and so on. Then use custom allocators/static for just about everything. When I make an object at runtime I can just snag preallocated space from the pool. With the ability to cast the pool's primitive data types to pointers I can even save on any need to index the blocks since I can use the unused memory to point to the next block of unused memory (although it's probably a minor optimization). Go drops that control totally in favour of it's inbuilt garbage collector which the Go devs think they can just get right. That seems unlikely (the current implementation is apparently quite bad stop-the-world implementation). Another issue that strikes me is library building. Afaik Go doesn't produce object that can be linked against by non-go stuff. C does this, it has a ABI. This means I can write one library in C/C++ (and apparently Rust) and then have wrappers for just about every other programming language in existence. (Although C++ can make this painful with things like exceptions http://250bpm.com/blog:4 http://250bpm.com/blog:4 ). It might be that Go's interfaces make it really useful for making Go libraries in, but some libraries need to be language agnostic as much as possible. Many of the things Go initially solved over C++ are being chipped away too. I love reflection, it would be very useful for games, serialization and so on. C++ doesn't have it but there is a standards working group looking at it now, so we could see it in either C++14 in a year, or C++17 (probably with implementations before then). C++11 got threads and so on and there is a working group doing transactional memory, more threading stuff, networking and so on. So we could see something like Gorutines and Channels but still have access to low level things like raw memory barriers. C++ tooling is set to explode with what the clang people are up to. Go seems great, but it does seem focused in the 'business' kind of domain. Maybe future versions could address some of the issues like the GC (either fixing it so it does meet the performance requirements, or allowing custom memory options, C# has the unsafe keyword for example). EDIT: I note that Go might provide a package "unsafe" that could allow for some things like a custom GC but apparently would be hard to implement.
epi8 13y 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. ... 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 13y ago
  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++.
  - epi8 13y ago
    Both of those are problems for me. The garbage collection is probably the larger one, though, since I'm sure one could add explicit, hand-tuned SIMD into any language (auto-vectorization, while useful in many contexts, just doesn't cut it here). The main thing is that the garbage collector is a problem in time-constrained and memory-constrained environments. I can't afford to wait to clean up my large data set until the GC decides to, and I can't afford to wait the 100ms that the GC may take. Or, more accurately, I might be able to, but I just don't know, and that lack of certainty means that a GC language is not an option for me. But that's not to say that Go suxxors! Different solutions to different problems. I'm just saying why I won't be using Go to work on the project I'm on now.
nfoz 13y ago
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 13y ago
  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 13y ago
    The tone of article implied that it is somehow expected that C++/Java developers would come to Go. Well, no - there are choices.
    - 59nadir 13y ago
      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.
tinco 13y ago
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.
- Pxtl 13y ago
  > 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. All of those foist garbage collection on you. Many of them find text-based macros such as C++'s template engine morally offensive and so they don't include that feature. If you want a statically-typed Python, then Scala and C# and the like will serve your needs nicely. If you want a modernized C++... it still doesn't exist. Rust looks promising, but that's not exactly mature technology.
- detrino 13y ago
  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 13y ago
    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.
    - 13y ago
eonil 13y ago
Less is more. No data mutation. No ordered execution. Go Haskell.
oo 13y ago
"Go was designed to help write big programs, written and maintained by big teams." If this is true, isn't it obvious why? Small projects do not need Go, while big teams with big projects will always be extremely slow to adopt anything new.
akkartik 13y ago
Previous discussion: http://news.ycombinator.com/item?id=4158865 http://news.ycombinator.com/item?id=4158865
- cbhl 13y ago
  (218 points, 1 year ago, 123 comments)
- MrBuddyCasino 13y ago
  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.
nly 13y ago
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.
penguindev 13y ago
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 13y ago
  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 13y ago
    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.
FigBug 13y ago
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 13y ago
  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 13y ago
    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.
lnanek2 13y ago
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 13y ago
  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.
  - jre 13y ago
    One of the major (the only?) reason I still write C++ code is the amount of libraries available. I'm writing computer vision stuff and all the important libraries (OpenCV, PCL, nonlinear optimization stuff) are in C++... Sure there are bindings, but they are often incomplete and not quite stable. I will switch the day a language allows me to transparently call my existing C++ library, without having to spend time writing and debugging swig/boost::python/whatever wrappers.
  - rwj 13y ago
    Just because some people are using C++ in projects where another language would be better, it does not follow all projects using C++ would be in another language. I have some projects I would hate to do in C++, but I also have projects I would hate to do in another language. To quote an old cliche, right tool for the job.
  - 13y ago
solomatov 13y ago
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.
nimrody 13y ago
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.
Wilya 13y ago
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 13y ago
  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
  - terio 13y ago
    I find it funny that when I had to switch to C++ I found it slow compared to C and Object-Oriented Pascal. There are also some tradeoffs when switching languages. Some people would never make the move from C to C++ citing unnecessary complexity (e.g. Linus Torvald). This is essentially a question of having the right tool for the job. Switching from C++ to Go is probably a good decision some cases and a bad one in others. But one should not remain so anchored in one language that won't be able to consider some other, probably better, option.
  - tlb 13y ago
simias 13y ago
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 13y ago
  I think you should be given a choice whether to use GC. Now that's a killer feature.
  - ori_b 13y ago
    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 13y ago
      I don't know much about Rust, but they do promise "optional task-local GC, safe pointer types with region analysis".
      - ori_b 13y ago
        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.
deleted 13y ago
[deleted]
bloodorange 13y ago
"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 13y ago
  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 13y ago
    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.
Mikeb85 13y ago
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 13y ago
  Ada, D
  - TheLegace 13y ago
    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.
  - mamcx 13y ago
    And pascal! Sadly, C/C++ take the world.
- legulere 13y ago
  Two exemplary reasons why Go occupies a different space: - Mandatory garbage collection. Sometimes you need more control over memory than being able to use just one standard garbage collection. - No dynamic linking. Just think about what would happen if qt, webkit or llvm would be statically linked in in all programs using them.
  - easytiger 13y ago
    > Mandatory garbage collection. Sometimes you need more control over memory than being able to use just one standard garbage collection. Not only that, sometimes you don't want a runtime overhead plain and simple. I don't know anyone in high throughput app development who would be happy with go. You want to generate a sequence of instructions which get executed.
    - qznc 13y ago
canthonytucci 13y ago
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 13y ago
  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.)
kps 13y ago
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.
aurelius 13y ago
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++.
pfortuny 13y ago
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?
rachelbythebay 13y ago
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.
dbcfd 13y ago
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.
jacques_chester 13y ago
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 13y ago
  They probably work in start-ups or are free-lancers on small projects. Or they work at Google.
skriticos2 13y ago
Somehow I miss the biggest advantage of C++ here: you can still maintain a 20 year old code-base without a complete rewrite.
nikic 13y ago
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.
static_typed 13y ago
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 13y ago
  To earn upvotes at HN :)
debacle 13y ago
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.
api 13y ago
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 13y ago
  One way they could push it, would be to give first class support for Android development, but I doubt it will ever happen.
bjoernbu 13y ago
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
jlarocco 13y ago
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.
- rwj 13y ago
  Actually, I think this is the genius of Go. It has the a lot of the expressiveness of Python, but the static typing of C++. This makes it useful in projects that don't require the performance/sharp edges of C++, but that do require the discipline of a static type system. > 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.
- justinhj 13y ago
  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++.
  - option_greek 13y ago
    I code in both c++ and c# and switching between the two is so much easier. I don't even feel like I'm in a different language.
  - jlarocco 13y ago
    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?
bliti 13y ago
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.
luikore 13y ago
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.
cheery 13y ago
Every C++ programmer wishes that their software is blazing fast. That's why they code C++. Using C++ is a premature optimization, which we should eliminate entirely.
mietek 13y ago
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 13y ago
  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 13y ago
    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++."
- 13y ago
jamesmiller5 13y ago
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.
saosebastiao 13y ago
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.
detrino 13y 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." 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.
programminggeek 13y ago
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.
deleted 13y ago
[deleted]
qznc 13y ago
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 13y ago
  > 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 13y ago
    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 13y ago
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 13y ago
  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.
CmonDev 13y ago
"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?
mseepgood 13y ago
Didn't we discuss this already last year? https://news.ycombinator.com/item?id=4159703 https://news.ycombinator.com/item?id=4159703
transfire 13y ago
"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.
geertj 13y ago
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.
hsmyers 13y ago
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'
asdasf 13y ago
>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.
craigyk 13y ago
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.
RogerL 13y ago
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.
EugeneOZ 13y ago
I'm very dissapointed in Go philosophy... Edpecially about RAII...

238 points by MrBuddyCasino 13y ago

raverbashing 13y ago

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.

sigzero 13y ago

"It seems almost paradoxical that other C++ programmers don't seem to care." It probably doesn't scratch their itch.

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

krosaen 13y 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. 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.

fein 13y ago
> C++ was the first language I really invested in mastering during and after college This is partially why you picked up Python so easily. It's one thing to approach a language like Python as your first, but if you took the dive and learned c/c++ prior, everything else is going to be much easier to grok.
- krosaen 13y ago
  Yeah good point, impossible to forget what it's like not to know something. I also haven't done systems programming in a long time - so it would really be more fair to have someone comment who is considering a language under higher performance constraints. That said, I can report on what I prefer right now, knowing what I already know (having spent 4 years programming java professionally as well) - and I truly prefer a more functional approach that comes a lot more easily in languages that support closures and first class functions. It also strikes me that many of the best practices in java / c++ are basically moving towards more functional programming (prefer composition to inheritance, make objects immutable by default, interfaces over classes when possible, dependency injection / referential transparency and parameterizing methods by interfaces e.g functions).
H3g3m0n 13y ago
I'm not an expert but in the gamedev domain, control over memory is fairly vital. It seems like it would be for lots of the other stuff C++ is used with too. In C++ I can allocate all my memory upfront in a pool since I know the exact size of my level, the number of objects and so on. Then use custom allocators/static for just about everything. When I make an object at runtime I can just snag preallocated space from the pool. With the ability to cast the pool's primitive data types to pointers I can even save on any need to index the blocks since I can use the unused memory to point to the next block of unused memory (although it's probably a minor optimization). Go drops that control totally in favour of it's inbuilt garbage collector which the Go devs think they can just get right. That seems unlikely (the current implementation is apparently quite bad stop-the-world implementation). Another issue that strikes me is library building. Afaik Go doesn't produce object that can be linked against by non-go stuff. C does this, it has a ABI. This means I can write one library in C/C++ (and apparently Rust) and then have wrappers for just about every other programming language in existence. (Although C++ can make this painful with things like exceptions http://250bpm.com/blog:4 http://250bpm.com/blog:4 ). It might be that Go's interfaces make it really useful for making Go libraries in, but some libraries need to be language agnostic as much as possible. Many of the things Go initially solved over C++ are being chipped away too. I love reflection, it would be very useful for games, serialization and so on. C++ doesn't have it but there is a standards working group looking at it now, so we could see it in either C++14 in a year, or C++17 (probably with implementations before then). C++11 got threads and so on and there is a working group doing transactional memory, more threading stuff, networking and so on. So we could see something like Gorutines and Channels but still have access to low level things like raw memory barriers. C++ tooling is set to explode with what the clang people are up to. Go seems great, but it does seem focused in the 'business' kind of domain. Maybe future versions could address some of the issues like the GC (either fixing it so it does meet the performance requirements, or allowing custom memory options, C# has the unsafe keyword for example). EDIT: I note that Go might provide a package "unsafe" that could allow for some things like a custom GC but apparently would be hard to implement.

epi8 13y 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. ... 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 13y ago
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++.
- epi8 13y ago
  Both of those are problems for me. The garbage collection is probably the larger one, though, since I'm sure one could add explicit, hand-tuned SIMD into any language (auto-vectorization, while useful in many contexts, just doesn't cut it here). The main thing is that the garbage collector is a problem in time-constrained and memory-constrained environments. I can't afford to wait to clean up my large data set until the GC decides to, and I can't afford to wait the 100ms that the GC may take. Or, more accurately, I might be able to, but I just don't know, and that lack of certainty means that a GC language is not an option for me. But that's not to say that Go suxxors! Different solutions to different problems. I'm just saying why I won't be using Go to work on the project I'm on now.

nfoz 13y ago

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 13y ago
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 13y ago
  The tone of article implied that it is somehow expected that C++/Java developers would come to Go. Well, no - there are choices.
  - 59nadir 13y ago
    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.

tinco 13y ago

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.

Pxtl 13y ago
> 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. All of those foist garbage collection on you. Many of them find text-based macros such as C++'s template engine morally offensive and so they don't include that feature. If you want a statically-typed Python, then Scala and C# and the like will serve your needs nicely. If you want a modernized C++... it still doesn't exist. Rust looks promising, but that's not exactly mature technology.
detrino 13y ago
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 13y ago
  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.
  - 13y ago

eonil 13y ago

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

oo 13y ago

"Go was designed to help write big programs, written and maintained by big teams." If this is true, isn't it obvious why? Small projects do not need Go, while big teams with big projects will always be extremely slow to adopt anything new.

akkartik 13y ago

Previous discussion: http://news.ycombinator.com/item?id=4158865 http://news.ycombinator.com/item?id=4158865

cbhl 13y ago
(218 points, 1 year ago, 123 comments)
MrBuddyCasino 13y ago
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.

nly 13y ago

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.

penguindev 13y ago

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 13y ago
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 13y ago
  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.

FigBug 13y ago

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 13y ago
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 13y ago
  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.

lnanek2 13y ago

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 13y ago
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.
- jre 13y ago
  One of the major (the only?) reason I still write C++ code is the amount of libraries available. I'm writing computer vision stuff and all the important libraries (OpenCV, PCL, nonlinear optimization stuff) are in C++... Sure there are bindings, but they are often incomplete and not quite stable. I will switch the day a language allows me to transparently call my existing C++ library, without having to spend time writing and debugging swig/boost::python/whatever wrappers.
- rwj 13y ago
  Just because some people are using C++ in projects where another language would be better, it does not follow all projects using C++ would be in another language. I have some projects I would hate to do in C++, but I also have projects I would hate to do in another language. To quote an old cliche, right tool for the job.
- 13y ago

solomatov 13y ago

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.

nimrody 13y ago

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.

Wilya 13y ago

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 13y ago
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
- terio 13y ago
  I find it funny that when I had to switch to C++ I found it slow compared to C and Object-Oriented Pascal. There are also some tradeoffs when switching languages. Some people would never make the move from C to C++ citing unnecessary complexity (e.g. Linus Torvald). This is essentially a question of having the right tool for the job. Switching from C++ to Go is probably a good decision some cases and a bad one in others. But one should not remain so anchored in one language that won't be able to consider some other, probably better, option.
- tlb 13y ago

simias 13y ago

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 13y ago
I think you should be given a choice whether to use GC. Now that's a killer feature.
- ori_b 13y ago
  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 13y ago
    I don't know much about Rust, but they do promise "optional task-local GC, safe pointer types with region analysis".
    - ori_b 13y ago
      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.

deleted 13y ago

[deleted]

bloodorange 13y ago

"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 13y ago
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 13y ago
  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.

Mikeb85 13y ago

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 13y ago
Ada, D
- TheLegace 13y ago
  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.
- mamcx 13y ago
  And pascal! Sadly, C/C++ take the world.
legulere 13y ago
Two exemplary reasons why Go occupies a different space: - Mandatory garbage collection. Sometimes you need more control over memory than being able to use just one standard garbage collection. - No dynamic linking. Just think about what would happen if qt, webkit or llvm would be statically linked in in all programs using them.
- easytiger 13y ago
  > Mandatory garbage collection. Sometimes you need more control over memory than being able to use just one standard garbage collection. Not only that, sometimes you don't want a runtime overhead plain and simple. I don't know anyone in high throughput app development who would be happy with go. You want to generate a sequence of instructions which get executed.
  - qznc 13y ago

canthonytucci 13y ago

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 13y ago
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.)

kps 13y ago

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.

aurelius 13y ago

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++.

pfortuny 13y ago

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?

rachelbythebay 13y ago

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.

dbcfd 13y ago

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.

jacques_chester 13y ago

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 13y ago
They probably work in start-ups or are free-lancers on small projects. Or they work at Google.

skriticos2 13y ago

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

nikic 13y ago

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.

static_typed 13y ago

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 13y ago
To earn upvotes at HN :)

debacle 13y ago

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.

api 13y ago

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 13y ago
One way they could push it, would be to give first class support for Android development, but I doubt it will ever happen.

bjoernbu 13y ago

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

jlarocco 13y ago

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.

rwj 13y ago
Actually, I think this is the genius of Go. It has the a lot of the expressiveness of Python, but the static typing of C++. This makes it useful in projects that don't require the performance/sharp edges of C++, but that do require the discipline of a static type system. > 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.
justinhj 13y ago
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++.
- option_greek 13y ago
  I code in both c++ and c# and switching between the two is so much easier. I don't even feel like I'm in a different language.
- jlarocco 13y ago
  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?

bliti 13y ago

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.

luikore 13y ago

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.

cheery 13y ago

Every C++ programmer wishes that their software is blazing fast. That's why they code C++. Using C++ is a premature optimization, which we should eliminate entirely.

mietek 13y ago

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 13y ago
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 13y ago
  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++."
13y ago

jamesmiller5 13y ago

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.

saosebastiao 13y ago

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.

detrino 13y 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." 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.

programminggeek 13y ago

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.

deleted 13y ago

[deleted]

qznc 13y ago

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 13y ago
> 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 13y ago
  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 13y ago

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 13y ago
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.

CmonDev 13y ago

"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?

mseepgood 13y ago

Didn't we discuss this already last year? https://news.ycombinator.com/item?id=4159703 https://news.ycombinator.com/item?id=4159703

transfire 13y ago

"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.

geertj 13y ago

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.

hsmyers 13y ago

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'

asdasf 13y ago

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

craigyk 13y ago

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.

RogerL 13y ago

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.

EugeneOZ 13y ago

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