Less is exponentially more

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

My experience in Python is the opposite than yours, but then I've only been using it for 12 years :-) Undocumented serious exceptions are no different than Go's panic - they will probably terminate the program. But the usual case is extremely useful and not littering intermediate functions with error handling is wonderful.

And sure they can be abused, but virtually any functionality gives you "power" and that power can be used wrong. That isn't a good reason to take something away from the developers who would use them right.

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

1. Rob Pike is immensely proud that the language has no generics, but this means that in the last 2 years, there isnt a proper implementation of a linked list that can hold an arbitrary type, or a min-heap, an ordered map, or a b-tree, or any one of countless data structures that one can take for granted in every other language. And yes, there are implementations that take interfaces, but you have to very odd-looking casts to coerce values in and out of them.

2. Go - or its testing support - doesnt allow a simple assert or EQUALS macro, simply because Rob believes everything should be done with if/then structures. Along with error handling, this makes go tests painful to read.

3. Idiosyncratic handling of pointers and values, leading to confusion everywhere and accidental copies and bugs where people pass by value accidentally because its extremely easy to.

4. Channels aren't really that useful beyond small programs (IMHO, maybe I'm wrong), and by making them synchronous any non-trivial go concurrent program has to reason very carefully to avoid deadlocks.

There are countless similar things. People will put up with these idiosyncracies for a while but move on in the end.