5 ms·

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 t

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

eropple 5y ago
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.
- silvestrov 5y ago
  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.
  - richardwhiuk 5y ago
    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.
    - miskin 5y ago
      You may be both right, as android is actually not using Java garbage collectors that are quite good, but they have their own runtime.
  - eropple 5y ago
    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.
  - morelisp 5y ago
    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.)
  - rvz 5y ago
    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.
    - vips7L 5y ago
      You’re confusing Android with OpenJdk. The parent was talking about Java/OpenJdk’s gc implementations, not androids.
      - rvz 5y ago
        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.
        vips7L 5y ago
        Again this isn’t Java’s fault. This is the Android Runtime’s fault. The Android Runtime is not Java or OpenJdk.
        rvz 5y ago
        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.
  - lenkite 5y ago
    Java is fast but takes 5x-10x memory that a proper AOTC language app.
- mwcampbell 5y ago
  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.
jimbokun 5y ago
Swift needed perfect interoperability with all the existing Objective C code, and that probably would have been difficult to accomplish with C#.
- andrewcl 5y ago
  It's arguably difficult with Objective-C today, let alone C#!
krzat 5y ago
Rust would be a more realistic choice, as it's built on LLVM.

eropple 5y ago

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.

silvestrov 5y ago
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.
- richardwhiuk 5y ago
  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.
  - miskin 5y ago
    You may be both right, as android is actually not using Java garbage collectors that are quite good, but they have their own runtime.
- eropple 5y ago
  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.
- morelisp 5y ago
  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.)
- rvz 5y ago
  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.
  - vips7L 5y ago
    You’re confusing Android with OpenJdk. The parent was talking about Java/OpenJdk’s gc implementations, not androids.
    - rvz 5y ago
      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.
      - vips7L 5y ago
        Again this isn’t Java’s fault. This is the Android Runtime’s fault. The Android Runtime is not Java or OpenJdk.
        rvz 5y ago
        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.
- lenkite 5y ago
  Java is fast but takes 5x-10x memory that a proper AOTC language app.
mwcampbell 5y ago
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.

jimbokun 5y ago

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

andrewcl 5y ago
It's arguably difficult with Objective-C today, let alone C#!

krzat 5y ago

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