Earlier quoted context omitted.
>The last time I checked concurrency isn't possible with standard C++ If you don't know, then I can't tell you. People have been doing threading, re-entrant code, libevent/libev in C and C++ for decades. (cf. DragonflyBSD) I didn't say it was trivial, just that it's an industry standard for when you need to get things done (TM).
It appears you are being intentionally obtuse, so I repeat: Neither the current C and C++ language standards provide any support whatsoever for concurrent programming . Therefore you cannot do concurrent programming in either of those languages without resorting to using operating system specific or 3rd party libraries. DragonflyBSD, a project that was only started in 2003, has obviously not been around for "decades"…
They're not supposed to. They're systems programming languages. When you're writing a kernel or embedded software, having the language mandate some kind of concurrency model at the standards level is nonsensical.
I wasn't linking decades to DragonflyBSD, I was saying that the techniques and methods have been known and used for decades.
The original point, restated here for clarity is this.
Go was supposed to be a new-age systems programming language. Its current design (mandated concurrency model and global GC) preclude that from ever happening without fundamental changes.
Rust has a better chance of becoming the next systems programming language.
I don't know what your niche or corner of the realm of software is, but I get the feeling you're commenting on a field you have no substantial experience in.
It's evident to anybody with any real experience or wisdom concerning software that having choices like concurrency made for you at the language-level narrow the scope of usefulness for that particular language and pretty much precludes it from being a top-grade choice for embedded/systems development.
Example:
Were it not for the glut of hardware performance and memory capacity improvements in smartphones, Dalvik/java would've been impractical at best on Android. It's still a vastly inferior experience compared to the iPhone, which is obj-c with optional drop-down to C/C++.
And don't mention the NDK for Android, it's a bad joke.
Bootstrapping a runtime for a language that depends on a particular concurrency model irrespective of the problem at hand is stupid beyond my faculty for describing with words.
tl;dr good luck using Go for hard real-time systems.
Why do you think C++ achieved popularity so quickly? It was pliable to the demands of the problem being solved just like C at the expense of complexity.