Yeah, it's reasons like that that lead me to point (1). When stuff is done for the programmer for nonobvious reasons, it leads to problems like this - there's nothing in the conceptual mechanics of (obj ...) that would make you think "oh, it's wrapped in a global mutex", and yet it is because assignment itself uses a global mutex. It's not so much that the language is "doing it for me" that's the issue with (1); that's fine. It's "explicitness" that's the problem: I want to know when I'm using a concurrency-controlling form like 'atomic. Otherwise, it's hard to reason about how my program is going to behave.
Also, this stuff about profiling to fix hotspots is mostly true, but hotspots come in many forms: tough algorithmic problems, folding or mapping some operation over a large data structure, etc. One form of hotspot is a common operation that isn't particularly localized in use. For example, some people have experimented with adding infix math to arc by having numbers cause infix parsing when they're called; they found this caused a slowdown of ~10%. I strongly suspect assignment falls into this category: it's used everywhere, it's a fundamental language feature, and making it faster will reap noticeable (albeit not overwhelming) benefits. However, I must admit I haven't tested this, so feel free to prove me wrong.
For the second, well, I wouldn't be surprised if someone who worked at optimizing Arc could make it run twice or maybe even ten times as fast, while still implementing the full specification. So if a particular language feature is actually useful, and happens to cause a 10% slowdown, I mostly don't worry about it myself... I suspect greater gains would be found from a systematic optimization approach.
Besides, most of the programs I write already run fast enough, so I wouldn't mind a 10% slowdown for a feature that was actually useful. Which, unless I'm presented with new information that changes my mind, I agree with you that Arc's implicit locking is not.
