"In a language with closures and Go-style goroutines and channels, the amount of programmer effort required to manage memory would be absolutely immense without a garbage collector."

That isn't the whole story though. Microsoft Singularity achieved this with the exchange heap: closures and Go-style goroutines and channels can exist without concurrent GC, or even without GC at all on a per-goroutine basis.

I agree that it's always a target conflict. I'm just not convinced that gc is the way to go in an environment where optimization might become important. GC lets you get a correctly working program easier, but once you are into optimizing runtime performance you quickly loose that advantage, often by simulating memory management with pools. Take a look at the new Obj C with automatic reference counting. It lets you forget about the standard case and only requires you to take action for circular reference by defining them weak - thus it replaces a hard problem to solve with an easy one. For my taste that's the right balance in an environment that is run close to the hardware.

1986 - Brad Cox and Tom Love create Objective-C, announcing "this language has all the memory safety of C combined with all the blazing speed of Smalltalk."

http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m...

Once you're optimizing the runtime performance of Objective-C code, you're suddenly writing in C.

The "close to hardware" thing is an illusion created by the "-C" part.

While that blog post is a fun read, it's a bit of a stretch to quote it in this context don't you think? ;)

"Once you're optimizing the runtime performance of Objective-C code, you're suddenly writing in C."

1) in idiomatic obj c you have already more control over runtime behavior than in managed environments, simply because you don't have to worry about a GC kicking in at a bad time (like "user has touched my interface, expects immediate GUI response").

2) If you do want to dig deeper, yes you go into C programming. However, I don't see what's wrong with that. In a managed environment it's not even possible to do that.

"The "close to hardware" thing is an illusion created by the "-C" part."

It always depends what you mean by "close". In Obj C it's abstracted away but accessible. In a managed language it's hidden by the runtime environment and not accessible anymore. Don't get me wrong, I think that managed languages certainly do have their merrit for many applications. It's just pretty obvious to me that they won't replace languages like C or C++ in the near future. Obj C is something in between - and I like its balance. Obviously it's not well suitable for cross platform development, but that doesn't defy the idea behind it.

I'm not sure what kind of "managed environment" you're talking about, but Go is not one.

1) You're right about GC pauses, but you certainly don't have more control over the memory layout in idiomatic Objective-C than in Go. In ObjC you're mostly dealing with heap-allocated objects (by the way, remember that malloc is not deterministic too), and you don't have control over the objects' memory layout.

In the recent SDK, your typical NSNumber may be a tagged pointer or it may be a pointer to a number on heap -- you don't know, it's an implementation detail.

Hell, you don't even know the big O of NSArray! http://ridiculousfish.com/blog/posts/array.html

Oh, and autoreleasing. Do you know how many objects will be released at the end of your NSAutoreleasePool? Nope -- you don't know how many were allocated by other people's code you called.

2) Again, I don't know what "manage environment" you're arguing against, but from Go you certainly can call C functions. But nobody does this for speed, only for compatibility with existing C libraries, if needed. You're programming in Go, not in two languages.

Go is not a 'managed language', whatever this Microsoft's term means, so I'm not even sure what to answer to your last paragraph.

> In a language with closures and Go-style goroutines and channels...

Is that also filed under doing less? I believe C/C++ programmers aren't flocking to Go because it isn't strictly less. Every language that has tried to replace C/C++ always ends up doing too much. I'd love to see a replacement for C that solves the obvious flaws but doesn't add to much to the basic premise.

We're certainly hoping that Rust is that language.

In particular, we're trying to get the raw no-compromises performance of idiomatic C++ in a practical, memory-safe (and data-race-free) language. That means that our type system is more complex than that of C or Go, but it also lets us squeeze performance out of the machine without sacrificing safety.

We do have an optional per-thread garbage collector (it doesn't stop the world, only the thread), but it's more like shared_ptr than what you'd usually think of as a GC; it's there if you want it on your objects, and you don't have to use it.

(Disclaimer: I work on Rust.)

(Second disclaimer: Go is an awesome language and, as this talk illustrates, we aren't competing with Go; Go and Rust have totally different goals and Rob Pike's languages were quite the influence on Rust.)

There are several of those languages too, but they suffer from the opposite problem: not enough differentiation to overcome the inertia, tool support, and installed base of C.

The most developed attempt that comes to mind is Cyclone http://en.wikipedia.org/wiki/Cyclone_(programming_language).

I agree. In the end, it's not really surprising that C/C++ continue on. Replacements either include too much to be a strict replacement or do too little to warrant the change.

"Is that also filed under doing less?"

Compared to writing concurrent code in C++... yes, absolutely. No question.