4 ms·

It appears you are being intentionally obtuse, so I repeat: Neither the current C and C++ language standards provide any support whatsoever for concurrent prog

• alnayyir 16y ago
  >Neither the current C and C++ language standards provide any support whatsoever for concurrent programming. 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.
  • jbarham 16y ago
    Fair enough, if you define a "systems programming language" as one in which it's appropriate to write a real-time operating system kernel, Go is very likely not the language for you given its built-in garbage collection. Its suitability as a language for OS kernels has been discussed in this thread, with comments from the Go authors: http://groups.google.com/group/golang-nuts/browse_thread/thread/5206d398e5d9ff2c http://groups.google.com/group/golang-nuts/browse_thread/thr... However, if you define a systems programming language more broadly to include statically typed languages that compile to machine code with good support for a theoretically and practically sound concurrency model based on CSP, Go might very well be something worth investigating. And I wouldn't say that C++ achieved popularity "quickly" inasmuch as according to Stroupstrup he started working on it in 1979 (http://www2.research.att.com/~bs/bs_faq.html#invention http://www2.research.att.com/~bs/bs_faq.html#invention) but it wasn't in widespread use until the early/mid-1990's and wasn't standardized until 1998. By that timetable I'd say that Go has a few years yet before it can fairly be judged a success or a failure.
    • alnayyir 16y ago
      >By that timetable I'd say that Go has a few years yet before it can fairly be judged a success or a failure. I don't care, that's not what I'm talking about. I was talking about the use-case uncanny valley it sits in. If you have a point unrelated to anything I said, use your blog. I've had enough grief from hackerne.ws over the past week that I have zero patience for someone using me as some kind of pontification aid. I know what's involved in making a kernel, and what's typical for systems programming and embedded development today. I don't give a good goddamn what the devs of Go have to say about it. Use case inappropriate. That's the last time I'm repeating myself.