Hacker News Reader

Comment by zer0zzz | Hacker News Reader

Objective-C is probably the worst language I’ve ever encountered (speaking as a compiler guy).

A language where you can’t prove anything is dead, where you can’t make any changes to the runtime to deal with the dynamic semantics is not great.

ObjC did one neat thing by having language level runtime type resolution address the component oriented programming and Abi stability issues present in c++ and later addressed by things like COM. But at the cost of some seriously bad performance characteristics.

View on HN

Yeah, compiler people hate it. Because there's very little for them to do.

The question is whether programming languages exist to make the compiler (people) happy, or to enable programmers to build great software.

I'd argue the latter.

Apple has now accepted the former.

They have done some nice stuff recently with objc_direct. The minute you can annotate away the dynamism it’s much better. Question is what’s the best way to do this? Lots of folks have been investigating analysis of entire apps either at the source level or some ir (maybe mlir some day).

objc_direct is pretty awful.

> The minute you can annotate away the dynamism it’s much better.

Only if you think dynamism is a bad thing. It isn't. There are cases when you might want or need to take it away, but they are both (a) rare and (b) context sensitive. So taking the dynamism away at the supplier side is the wrong approach.

> analysis of entire apps either at the source level

Dramatically worse build times for little to no gain. What's not to like?!

People already enable pgo and lto which dramatically makes their build times worse all the time just to produce a shipable app/dylib. When large objc codebases (apple, meta, google scale code bases) ship frameworks and apps they basically can’t do so without this sort of thing. World builds at apple literally take days.

It’s also not little to no gain, codebases that misuse/overuse objc instead of C/C++ often get vastly better startup time (less selectors to page in at app boot) and app size because of this sort of thing (especially with lto and -Oz).

> People already enable pgo and lto which dramatically makes their build times worse all the time

No. Not "all the time". Even the cases you listed are fairly unique corner cases.

> When large objc codebases (apple, meta, google scale code bases) ship frameworks and apps they basically can’t do so without this sort of thing

Apple does this not because the code would not be shippable, but because doing so for an OS once before shipping is a useful performance optimisation. Source: I used to work on the OS X performance team.

Haven't heard that FB needs to do this, though their mobile development practices are so fubared that I wouldn't be surprised.

The case that I do know about where they absolutely had to do crazy things to be shippable (more precisely: to remain below the iOS AppStore cellular download limit, a P1) was Uber. But that wasn't Objective-C, that was their Swift rewrite.

> Source: I used to work on the OS X performance team.

I am so sorry to hear that.

When I was at Apple I worked on a different part of the stack so my experience is not first hand here, but the folks I knew who worked on optimizing the shared cache either through ld or clang paint a different picture. I don't think they would ship without those performance optimizations, but I take your point that at least at the time you were there it was not as dire. That's not what it sounds like when I speak to those folks in the last year or two however (for iOS anyways). I don't think there's any universe where they wouldn't do these optis at the very least before shipping, but I don't mean that they can't have functioning non-optimized builds internally.

Certain apps mentioned above really can not ship without this stuff, but you're right about the development practices. Given the app size limits and startup time constraints as well as the coding practices it is really not feasible to not do things like LTO, objc_direct as much as possible, and align the startup path of an app by page boundary etc.

> was Uber.

I am well aware of the Uber Swift rewrite and when I say "unable to ship" I don't mean it to that extent in every case, but my point is I don't think anyone is going to worry about lengthy prod build times if having faster builds means less engagement even in the single digits.

OS X performance was lots of fun. Mostly ;-)

> I don't think they would ship

Notice "they" and "would". Which is completely different from "all the time just to produce a shipable app/dylib".

Sure we would apply various optimisations, including some very nasty, hacky and slow techniques in order to produce order files. But this is not something people do "all the time", it is something that Apple does. Because Apple produces the operating system, and because Apple has certain performance goals. Including not having performance regressions (unless specifically allowed). So once you start doing this, you can't stop unless you can find the performance elsewhere.

It is not necessary to produce a "shippable" app or dylib, the vast majority of apps or dylibs can be and are shipped without doing any of this.

> It is not necessary to produce a "shippable" app or dylib, the vast majority of apps or dylibs can be and are shipped without doing any of this.

You're not wrong. I think I engaged in a little bit of hyperbole here because I often fall into the thinking of top 10 or 20 appstore app terms. Not certain but if memory serves I think probably even Meta's least aggressively optimized app still does the orderfile thing.

> I often fall into the thinking of top 10 or 20 appstore app terms

You're not the only one. As far as I can tell, the vast majority of (particularly, but not exclusively) compiler work is driven by these edge cases.

As an example, when I look a the justifications for pushing undefined behavior exploitation in C, invariably some Very Smart Compiler Guy™ will state with great authority that this is absolutely essential and completely unavoidable. When you check more closely, it turns out that it enables a somewhat obscure optimisation that at best most people can do without and at worst is just about completely useless.

See Proebsting's Law, which was unduly optimistic, and also some of the work on variability in benchmarking, for example how different lengths of environment variables can dwarf most optimisation effects.

Daniel Bernstein stated this a bit more aggressively as "The Death of Optimising Compilers"[1]. He's not wrong, either, but when I mentioned this at a Google event, Chandler Carruth basically blew up and said it was complete garbage. Apparently he and Daniel almost came to blows over this at some conference.

At the time, Google was working on a far less optimising JS runtime for Chrome, after they found out that their super-simple runtime (mostly just interpreted) for small devices was beating their super-duper sophisticated Turbofan JIT on many real world tasks. And of course Microsoft found out that just turning off the JIT completely has marginal real-world impact.[2]3][4]

So what's the disconnect? How can these two very smart and knowledgeable people come to such stunningly different conceptions of reality, so different as to be not just incompatible, but apparently mutually incomprehensible? I think (Turing Award Winner) Michael Stonebraker had a great analysis[5] of what is happening, though for him it was in the field of databases: nearly all the research today, when it isn't completely removed from reality, is focused on the needs of what he calls the "whales", the 0.01% or so of users who are big enough that they sponsor that sort of work (Google, Apple, Microsoft, Facebook, ..).

So in the relevant community, the needs and the problems of the whales define reality. But they are far, far removed from and often in conflict with the needs of the other 99.99% of users.

Which goes back to your comment about compilers and compiler people optimising for the "common case". For that to work, you have to actually be aware of the common case.

[1] https://cr.yp.to/talks/2015.04.16/slides-djb-20150416-a4.pdf

[2] https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...

[3] https://blog.metaobject.com/2015/10/jitterdammerung.html

[4] https://news.ycombinator.com/item?id=28735392

[5] https://youtu.be/DJFKl_5JTnA?t=677

Also my answer to your question is: I think both. If it’s generally too hard for compiler people to optimize for the common case then it will be harder for folks to build great software. I’d also argue that apple did not do the former in regards to memory safety, rust did.

Demonstrably false.

It is easy to write fast software in Objective-C. Harder in Swift, for example.

What part are you responding to? I in no way made any claims about objc versus swift performance. I said the way they have tried to address memory safety assumes more compiler optimization and less burden to the programmer than rust.

"If it’s generally too hard for compiler people to optimize for the common case then it will be harder for folks to build great software."

The compiler people don't need to optimise for the common case.

That’s literally all compiler people do.. if we see a pattern people are using 80 percent of the time we find a way to make it better. There are ways to make ObjC better optimized at the compiler and runtime level but no one is exactly asking for patches for doing so for objc for very obvious reasons (which I am not going to discuss on a public forum).

> That’s literally all compiler people do.

I know. My point is that in lots of cases it is unnecessary and in fact unhelpful.

> make it better

Well, you first need to get agreement from your language users on what constitutes "better". Removing the dynamism from a dynamic language does not make it "better".

> Well, you first need to get agreement from your language users on what constitutes "better". Removing the dynamism from a dynamic language does not make it "better".

I think that depends on if said dynamism is being intentionally used. Far too often it is not, and it gets even worse when that is paired with tools that do automated source code generation like the kinds Meta and Google use (or misuse depending on your definition).

Can you give some examples? "Easy" and "hard" are subjective.

1. Swift tends to be about on par with Java in the language shootout.

2. Java tends to at least around 2x slower than C.

3. For my book[1], I wrote a chapter on Swift and did quite a bit of benchmarking. Just how bad Swift was actually surprised me, and I wasn't expecting it to be particularly good.

4. Case study: https://blog.metaobject.com/2020/04/somewhat-less-lethargic-...

Even the worst Objective-C implementation I could think of (really comically bad) was 3.8x the speed of Swift's compiler-supported super-duper-sophisticated implementation. With a bit of work I took that to around 20x.

[1] https://www.amazon.com/gp/product/0321842847/ref=as_li_tl?ie...

The other thing that ObjC does right is that it builds on top of an unmodified C (unlike C++ which went full in, messed everything up and now needs the C++ standard to change to integrate new C features, which then usually ends up as half-assed and incomplete attempt - see designated initalization). C and ObjC can be improved independently from each other, and combining them "just works" without "harmonization efforts" by language committees.

Also, doesn't the existance of ARC mean that ObjC supports better "static lifetime analysis" than C++? Or is C++ just behind the curve there?

ARC is runtime reference counting. How does that offer static lifetime analysis? C++ also has a form of ARC in the form of shared pointers, the only difference is that in C++ it's opt-in while in ObjC/Swift ARC it's just the way it is.

ARC does static lifetime tracking (or maybe better: ownership tracking) to remove redundant reference counting operations (highly simplfied: it basically makes the decision for you when to use the equivalent of a shared_ptr or unique_ptr under the hood - which is at least nice for API design, since functions just take or return generic "object references" instead of raw, shared or unique pointers like in C++ (which then is usually not what the caller wants in a specific situation).

ARC is not perfect because it has to be fairly conservative (it can be manually tuned though), but ObjC still seems to give the compiler more static information than shared_ptr and unique_ptr in C++ which are purely stdlib runtime constructs.

I'd imagine Swift also does this?

AFAIK Swift's ARC is the same thing, yeah.

Objective-C has an advantage, the compiler is able to elide retain/release pairs due to ARC semantics, where in C++ there is no special semantics defined in ISO C++ for smart pointer classes.

That “one neat thing” was absolutely huge for APIs and applications. Much more significant for a platform than any feature of C++ ever, for instance.

The performance wasn’t a real problem because you could always use C types for data on performance-sensitive paths. Nobody does Obj-C message calls to iterate over audio samples.

Yep. I think right now we just have too much objc code written that doesn’t need any of the parts of objc needed for frameworks.

But as an app developer, I love using Objective-C because it lets me build beautiful things without worrying about making the compiler happy.

Reply on news.ycombinator.com