With reference-counted smart pointers, you can guarantee that objects immediately go away once they leave scope, and that you can pass them around between threads without worrying too much about a thread forgetting to delete them. No other language has such easy support for doing something like that without relying on a background memory-management mechanism (at least that I'm aware of--I'd like to hear about it if you know one!).

Also, to answer your query, Rust uses unique pointers (the equivalent of std::unique_ptr in C++0x) for inter-thread communication. When the unique pointer goes out of scope, its memory is immediately freed (since it was the only owner of the data). And since the data has only one owner, it's data-race-free.

Cool on Rust, though! Thanks for the info!

Reference counting is also not even that great for shared memory multithreading. The (atomic) increment/decrement operations typically cause lots of cache invalidation, so you'll get a slowdown even for immutable objects.

The alternatives are either (a) avoiding shared state; (b) strong lifetime management such that you make sure one parent thread owns all of the data that its child threads are going to use; (c) concurrent GC; (d) pretending it's not a problem like Go does and doing stop-the-world GC.

Thanks again folks!

Interesting point about the cache invalidation, though. I wonder if we'll see chip vendors going out of their way to improve performance and invalidation when using atomic ops.

They already put a lot of effort into making this stuff as efficient as possible - the fact that Intel is going in the direction of hardware transactional memory indicates to me that they don't think the bus locking/cache snooping approach scales, and I can't say I'm surprised.

(not a Objective-C dev, so don't know)

The exception is the autorelease pool, which gets dumped at the end of every turn of the event loop. You can promote or demote objects from the autorelease pool at will.

Anyway, the biggest problems with Obj-C memory management are (a) you can't allocate objects on the stack, so you're forced into using the autorelease pool for stuff, and (b) you can promote or demote objects from the autorelease pool at will, which means that even the autorelease pool has to malloc, thus you don't get the nice benefits of super-cheap bump allocation that C++ arenas (or a generational GC's nursery) buy you.

Anyways, thank you for the information!

Second, why not assembly of some sort, or something very close to assembly? It's hard to break things out into threads and not incur performance problems due to platooning or thundering herds or contention for critical section(s). You want to maximize each individual CPU's work even in a massively multi-processor environment. Assembly gets you performance, guaranteed atomic operations, guaranteed memory barriers. and precise locations of those things.

I smell a return to the "semantic gap" and highly orthogonal ISAs.

However, it doesn't even mention that just having multiple cores on a chip isn't the same thing as having 2 chips, you still have shared memory and the bus, so having 2 cores is not going to be as fast as having 2 chips and 2 sets of memory in most cases, so adding cores is never going to be a linear increase. I believe right now that intel's hyperthreading needs to be turned off for some compile scenarios, as the collisions are too high either for memory or something else (at least 2 people I know who have to do huge compiles disable some of the hyperthreads).

In short, I don't believe it's easy to just scale up on multi-core systems, regardless of language. Threads are a pretty dangerous way to do things, processes are much safer, but not all problems fall easily into a parallel model.

C/C++ is popular only in the application programming and possibly industrial programming category. I believe that the latter category will become increasingly popular/important in the future (robotics, space travel, even consumer gadgets are becoming "smarter"), and C is a really bad language for any kind of life-critical software, mainly because it cannot be statically analysed (without significantly restricting the language features). Another thing is, in embedded systems, there's much less legacy code, so a new language for that field could very easily win over any existing ones.

Anyone who has chased a time-sensitive bug caused by data structures that mutate unexpectedly (be it by conflicting threads, be it by hardware changing it) can tell you that getting the types right won't help you a bit with making code that runs correctly on multi-core machines.

Compiling to javascript makes sense because javascript is the lowest common denominator for browsers.

Compiling to c++ wouldn't make any sense when you can compile directly to assembly/bytecode.

It would be like writing a python like language that compiled to coffeescript. It would be silly not to compile it directly to javascript.

Not very readable C, of course, but not significantly worse than what the first C++ preprocessors did (yes, kids, C++ started its life as a compiler that compiled C++ code into horribly mangled C).

C++ is likely to be the language of the future, as it is getting to the point where you can pick a subset of the language and emulate your favorite other programming language and paradigms.

This is not a good thing.

The languages on top of the VMs will evolve fast while the VMs become progressively broader in scope.

It has already happened for many languages and is already a route companies like Apple have and are investing heavily into, e.g. Clang.

Bleeding edge examples include Rust (http://www.rust-lang.org/) and Clay (http://claylabs.com/clay/) both on the LLVM.

This guy must be right. I don't see why my opinions should matter because, according to him, I haven't done any rock solid enterprise quality software since 2002 or so. I sure must warn my clients my software isn't up to the current standards of quality, for they rely on my "lesser" solutions.

Am I the only one who is sick of this kind of arrogance?

This guy must be good; I've been looking for the source code for the systems of the U.S.S Enterprise for months now on The Pirate Bay, and still haven't found it.

ALSO: I didn't know that this was an Object Oriented world! Ya lern sumthin new evry day.

Squirrel!