5 ms·

C/C++ are necessary for a lot of things, things that Go isn't capable of doing or wouldn't be very good at doing. Go isn't a systems programming language. They

C/C++ are necessary for a lot of things, things that Go isn't capable of doing or wouldn't be very good at doing. Go isn't a systems programming language. They called it that because compared to a language like Python it's closer to the hardware. A systems language has various properties, like strict memory layout and management control, varying degrees control over code output, being able to bootstrap an OS without depending on a wrapper OS / bootstrap VM / extensive stdlib, etc. Go fails to meet any realistic definition of a systems language. Go is instead a compiled alterative to VM languages like Java and Python. Black is not white just because Rob Pike said so. He's a brilliant man but he's always been a bit off to the side in terms of not really being in 'sync' with everybody else. This is just an uncommonly concrete and inarguable example of that. He himself backed off the 'systems' descriptor when he realized his error. You're fighting a bogeyman that doesn't exist. >because C/C++ is so unnecessary for so many projects People don't really default to C/C++ for anything they shouldn't anymore. They live way higher up the stack by default by FAR. C is generally only used where appropriate (kernel, embedded, drivers, services like Redis, etc.) C++ is the province of Microsofties, game developers, database coders, browser implementors, and OKCupid employees. (Mild exaggeration) I mean seriously. When was the last time you heard of somebody doing a GUI desktop app or web app in C or C++? Dropbox is Python, most Ubuntu/Gnome/GTK apps are Mono/C#, most web apps are Java/PHP/Python/Ruby, frontend web code is inescapably JavaScript with their ongoing attempts to shoehorn Node.js onto the server-side. Some weirdos and Perl6 hopefuls even use Perl for their primary language these days. Node.js is as good an example of the "sidegrades" I mentioned in my original comment, except it's spectacularly awful in so many ways that I have to wonder if it's trying to draw even more uninformed and informed detractors than C++. So who exactly is using C for everything on the planet? It's a strawman. Nobody does that anymore. People have become comfortable with resorting to higher levels of abstraction as appropriate. Mostly because of Perl, PHP, Java, Python, and Ruby. In the end, performance and control either matter or they don't. If they do matter, you need that last-mile escape hatch that will never-fail. If they don't, pick something "fast enough" that makes sense for your personal tastes that suits the problem and have a ball. There will always and forever be a place for languages like Fortran, Ada, C, and C++ even if they themselves might not survive the next century.

willvarfar 14y ago
all good points, well made. I find it disappointing that we've come to label systems languages as the languages with the properties to implement the 'systems' of yesteryear instead of the systems of tomorrow; Singularity, for example. One wonders if Pike and co were to build a new OS just where they'd put the managed/unmanaged line. Wikipedia says http://en.wikipedia.org/wiki/System_programming_language http://en.wikipedia.org/wiki/System_programming_language "The distinction between languages for system programming and applications programming became blurred with widespread popularity of C and Pascal." and I'd hazard that Pike was smearing that blur wider by saying Go. The Go FAQ http://golang.org/doc/go_faq.html http://golang.org/doc/go_faq.html still starts by saying "No major systems language has emerged in over a decade" and implicitly saying Go is to be it. Now to my point that C/C++ is usually a bad choice. Most C++ projects I've seen have been misguided, legacy choices from the late 90s when C++ was the rage. Then again, I've always been mystified by the appeal of STL, since it only just got a hashtable. I have always ended up building higher-performance custom collections for stuff and found STL with its iterator-instead-of-ranges clunky. I've written buckets of C/C++ code for OS and multimedia projects, some fairly recently; but even then, I'd rather have written only the innermost mechanics of them in C and lashed them together in something that was nice to work with, good C interoperability (no I don't think python tooling is nice) and didn't throw completely out all performance concerns. And until Go came along, there really wasn't anything. Python and so on are only useful for coordinating stuff when the task is embarrassingly and massively parallel. Along comes Go; you can still x-ray some Go code and have a pretty shrewd idea what the resulting machine code looks like, just like C/C++. Its within spitting distance of C/C++ code for performance and will improve. And as the concurrent scheduling is all in the hands of wizards, one expects it to scale multi-core rather better than something working at the lib-level that requires more discipline to use. Having said that, I'm actually using Java for a current no-compromise-performance rewrite-from-Python project now. Its Go but its tried and tested. Still, I am not enjoying myself too much. FWIW, had a fun bug in production the other day; turns out I must be the biggest user of Python in a sense, since I discovered - via a crash - that multiprocessing is using `select()` internally and will fail if it it gets a descriptor over 1024.. how come nobody else has discovered this? I see only one person has, and the fix is in ... 3.3. Just a fun story.

willvarfar 14y ago

all good points, well made. I find it disappointing that we've come to label systems languages as the languages with the properties to implement the 'systems' of yesteryear instead of the systems of tomorrow; Singularity, for example. One wonders if Pike and co were to build a new OS just where they'd put the managed/unmanaged line. Wikipedia says http://en.wikipedia.org/wiki/System_programming_language http://en.wikipedia.org/wiki/System_programming_language "The distinction between languages for system programming and applications programming became blurred with widespread popularity of C and Pascal." and I'd hazard that Pike was smearing that blur wider by saying Go. The Go FAQ http://golang.org/doc/go_faq.html http://golang.org/doc/go_faq.html still starts by saying "No major systems language has emerged in over a decade" and implicitly saying Go is to be it. Now to my point that C/C++ is usually a bad choice. Most C++ projects I've seen have been misguided, legacy choices from the late 90s when C++ was the rage. Then again, I've always been mystified by the appeal of STL, since it only just got a hashtable. I have always ended up building higher-performance custom collections for stuff and found STL with its iterator-instead-of-ranges clunky. I've written buckets of C/C++ code for OS and multimedia projects, some fairly recently; but even then, I'd rather have written only the innermost mechanics of them in C and lashed them together in something that was nice to work with, good C interoperability (no I don't think python tooling is nice) and didn't throw completely out all performance concerns. And until Go came along, there really wasn't anything. Python and so on are only useful for coordinating stuff when the task is embarrassingly and massively parallel. Along comes Go; you can still x-ray some Go code and have a pretty shrewd idea what the resulting machine code looks like, just like C/C++. Its within spitting distance of C/C++ code for performance and will improve. And as the concurrent scheduling is all in the hands of wizards, one expects it to scale multi-core rather better than something working at the lib-level that requires more discipline to use. Having said that, I'm actually using Java for a current no-compromise-performance rewrite-from-Python project now. Its Go but its tried and tested. Still, I am not enjoying myself too much. FWIW, had a fun bug in production the other day; turns out I must be the biggest user of Python in a sense, since I discovered - via a crash - that multiprocessing is using `select()` internally and will fail if it it gets a descriptor over 1024.. how come nobody else has discovered this? I see only one person has, and the fix is in ... 3.3. Just a fun story.