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