5 ms·

> C++ and Java are the gold-standard for library-centric concurrency methodologies The last time I checked concurrency isn't possible with standard C++. And m

by jbarham 16y ago

> C++ and Java are the gold-standard for library-centric concurrency methodologies The last time I checked concurrency isn't possible with standard C++. And multi-threaded programming in Java has been called many things, but "gold-standard" isn't one of them.

alnayyir 16y ago
>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).
- jbarham 16y ago
  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" so hardly serves to advance your claim.
  - 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.
philwelch 16y ago
You can use Java's concurrency features to implement better concurrency features (as opposed to the language just giving you better concurrency features from the outset), which is presumably what was meant by "less opinionated" or "library-centric". You can have asynchronous or synchronous message passing or STM on mutable references to immutable data or really anything built on top of Java, but an opinionated language like Go just picks something (synchronous message passing in Go's case) and makes you use it.[1] [1] You can implement asynchronous message passing on top of synchronous message passing, but not the other way around. Presumably the "least opinionated" language would simply give you the concurrency primitive with which you can implement the greatest number of other concurrency primitives, which presumably[2] is locks. [2] I could be wrong about this.
- alnayyir 16y ago
  I think you're the only one to get my point so far. A lot of the best libraries and concurrency approaches I've implemented in Clojure so far have been imports from Java. (NIO2 being one example)

by jbarham 16y ago

alnayyir 16y ago

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

jbarham 16y ago
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" so hardly serves to advance your claim.
- 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.

philwelch 16y ago

You can use Java's concurrency features to implement better concurrency features (as opposed to the language just giving you better concurrency features from the outset), which is presumably what was meant by "less opinionated" or "library-centric". You can have asynchronous or synchronous message passing or STM on mutable references to immutable data or really anything built on top of Java, but an opinionated language like Go just picks something (synchronous message passing in Go's case) and makes you use it.[1] [1] You can implement asynchronous message passing on top of synchronous message passing, but not the other way around. Presumably the "least opinionated" language would simply give you the concurrency primitive with which you can implement the greatest number of other concurrency primitives, which presumably[2] is locks. [2] I could be wrong about this.

alnayyir 16y ago
I think you're the only one to get my point so far. A lot of the best libraries and concurrency approaches I've implemented in Clojure so far have been imports from Java. (NIO2 being one example)