Hacker News new | past | comments | ask | show | jobs | submit login

I think Swift was a strategic mistake mainly due to the niche effect, even if it's a better language.

It would have been much more productive to team up with the C# team as C# is a mature language, and a combined Apple + Microsoft would have been able to compete against java (esp. with Oracle as owner of java).




An Apple C# future is a neat idea, but I'm not sure how you square that with the (IMO correct) observation that allocation control really matters for quality of experience on constrained platforms.

Obviously iOS platforms are much less constrained today, but not having to run a GC is a pretty nice thing.

Maybe C# could've been extended into that universe (I know Midori had their own variant but don't know much about it) but it seems daunting to then make that compatible.


I agree with you, and I've long speculated that lack of tracing GC is the main reason why iOS devices don't need as much RAM. It's too bad that the options for implementing a GC-free GUI that can target Android are quite limited, and as a consequence, the low-end devices used by people who can't afford an iPhone are inevitably saddled with GC.


Apple tried to do automatic GC but did so very badly and with a language not designed for it, so they had a bad experience and were scared away.

The modern GC in java is amazingly fast and with a few tricks likely to be good enough.


I'm fairly convinced that GC is the reason that Android phones need much more RAM and much more CPU to generally be worse than Apple phones in terms of performance.


You may be both right, as android is actually not using Java garbage collectors that are quite good, but they have their own runtime.


I'm pretty familiar with the modern Java GCs, and they're very impressive, but at the same time having to do manifestly less work with ARC is probably good for responsiveness and battery life.


I'm not saying you're wrong about ZGC, but I will say everyone heard exactly that line also at the time of Android 1. And that was not a language "not designed for it." (And Android is still not using it.)


So why are Android developers still complaining about their apps running poorly than iOS apps for years, especially contributing to battery drain?

Sounds like a lot of armchair generals debating in hindsight about any problem in anything that fits their dislike bias rather than fore-sighting about the specifics before it has happened.


You’re confusing Android with OpenJdk. The parent was talking about Java/OpenJdk’s gc implementations, not androids.


From the perspective of the user or app developer, they do not care. When they see an app perform slower on another platform for whatever reason they will complain. Maybe the problem was Java in Android (along side its sheer fragmentation) all along. Hardly any complaints about any of that for iOS.

No wonder that is the reason why they are preferring to moving everyone to use Dart / Flutter in their future operating system instead of continuing to use Java.

It is like as if Android was designed to be a disaster.


Again this isn’t Java’s fault. This is the Android Runtime’s fault. The Android Runtime is not Java or OpenJdk.


It's both of their fault; including the entire Android system design and Google knows it.

It's evident that Google and many developers have had enough of it from the runtime, Java, JDKs and the whole system. Otherwise, why on earth are they planning to move away from it all in the first place?

Once again, from the perspective of the user or the app developer, they don't care, Android still just doesn't cut it against iOS. No wonder Android is always second place.


Java is fast but takes 5x-10x memory that a proper AOTC language app.


Swift needed perfect interoperability with all the existing Objective C code, and that probably would have been difficult to accomplish with C#.


It's arguably difficult with Objective-C today, let alone C#!


Rust would be a more realistic choice, as it's built on LLVM.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: