6 ms·

I'm quite bullish on this method of cross-platform i.e. a common shared core leveraging native UI toolkits. Every incarnation of cross-platform on the market to

I'm quite bullish on this method of cross-platform i.e. a common shared core leveraging native UI toolkits. Every incarnation of cross-platform on the market today sits somewhere between mediocre and bad in terms of the resulting UX. This approach strikes a good balance between sharing code and being platform native I think. Swift is a good contender for doing this and so is, I think, Rust.

bt4u 3y ago
[dead]
jamil7 3y ago
I feel like the problem with Swift in this context is its relationship with Foundation, its standard library. There are at least three versions of it now. The internal version that ships with Apple OSes, then are the forks swift-corelibs-foundation and swift-foundation, these are, as far as I know, incomplete or behave slightly differently on Linux. swift-foundation is the newest and most likely the future. However, it's unclear when or if it will ever be production ready. Apple doesn't appear to be dedicating that much engineering effort towards it right now.
- mplewis9z 3y ago
  Eh, I wouldn’t call Foundation its standard library - it sits somewhere in between your traditional stdlib (including things like Date/Time models) and third-party dependencies (things like networking requests). There’s no functionality in Foundation that is absolutely core to the language and that you can’t avoid. I agree with you the various forks are confusing, but disagree that Apple isn’t putting effort towards the new one - it was only announced earlier this year, and is looking like it will be ready for WWDC is 2024. Which, given the sheer scope of the project (completely rewriting everything from the ground up in Swift), would be quite a fast turnaround time.
  - jamil7 3y ago
    > There’s no functionality in Foundation that is absolutely core to the language and that you can’t avoid. Is that why they're splitting the newer one into further SPM modules? There seems to be "FoundationEssentials" listed in that package. > but disagree that Apple isn’t putting effort towards the new one - it was only announced earlier this year, and is looking like it will be ready for WWDC is 2024 Oh, interesting, where did you find this information? I follow the project on Github and got the impression it had slowed down since its announcement.
  - fauigerzigerk 3y ago
    >Eh, I wouldn’t call Foundation its standard library... You're absolutely right, because the Swift Standard Library is a separate thing. It contains only the absolute essentials such as Int, String or Array: https://developer.apple.com/documentation/swift/swift-standard-library https://developer.apple.com/documentation/swift/swift-standa...
fzeindl 3y ago
Kotlin is a much more likely candidate. Excellent IDE support, deep integration with Java, already the go-to language for Android, many years of production and less "different" than Rust.
- robertjpayne 3y ago
  Kotlin running on the JVM is a disadvantage outside of Android though in a lot of spaces. Rust/Swift/Go will use a fraction of the ram to run a server application than Kotlin will.
  - doctor_eval 3y ago
    I agree, a huge driver for me leaving the Java ecosystem for Go was the JVM. Maybe Kotlin native can address that, but despite what people in the Java world seem to believe, the JVM is a big disadvantage.
    - fzeindl 3y ago
      The JVM is one of the most optimized, most performant, most monitorable, most secure and most predictable software-runtimes there is. How exactly do you consider it a big disadvantage?
      - doctor_eval 3y ago
        The JVM may be full of technology that’s indistinguishable from magic, but deployment is a pain in the ass. Maybe things have changed in the last few years but - having to ship a huge file tree alongside the actual binary (or binaries because JARs are also a nightmare), and the slow startup time due to the need to interpret/compile bytecode instead of just running machine code, make Java really unpleasant to use in many common use cases.
        fzeindl 3y ago
        Well I shipped fat jars using capsule more than 15 years ago without any issues. Nobody ships file-trees. Also the Startup depends on how much memory you allocate, but much of it is due to verifying class security, a feature that other runtimes don't even have. Or badly used reflection, another feature others don't have. In any case I really never found it an issue if a server takes 3 seconds to start and I never understood why people complained about Java startup. My guess is they complain about clunky desktop application with a million classes written in it. Regarding the bytecode: the interpretation and just in time recompilation gives Java sometimes better than native performance. It also allows you to hook into the code on the fly and transform it with agents. Can native do that?
mistrial9 3y ago
> Every incarnation of cross-platform on the market today sits somewhere between mediocre and bad in terms of the resulting UX .. seems heavy handed..

bt4u 3y ago

[dead]

jamil7 3y ago

I feel like the problem with Swift in this context is its relationship with Foundation, its standard library. There are at least three versions of it now. The internal version that ships with Apple OSes, then are the forks swift-corelibs-foundation and swift-foundation, these are, as far as I know, incomplete or behave slightly differently on Linux. swift-foundation is the newest and most likely the future. However, it's unclear when or if it will ever be production ready. Apple doesn't appear to be dedicating that much engineering effort towards it right now.

mplewis9z 3y ago
Eh, I wouldn’t call Foundation its standard library - it sits somewhere in between your traditional stdlib (including things like Date/Time models) and third-party dependencies (things like networking requests). There’s no functionality in Foundation that is absolutely core to the language and that you can’t avoid. I agree with you the various forks are confusing, but disagree that Apple isn’t putting effort towards the new one - it was only announced earlier this year, and is looking like it will be ready for WWDC is 2024. Which, given the sheer scope of the project (completely rewriting everything from the ground up in Swift), would be quite a fast turnaround time.
- jamil7 3y ago
  > There’s no functionality in Foundation that is absolutely core to the language and that you can’t avoid. Is that why they're splitting the newer one into further SPM modules? There seems to be "FoundationEssentials" listed in that package. > but disagree that Apple isn’t putting effort towards the new one - it was only announced earlier this year, and is looking like it will be ready for WWDC is 2024 Oh, interesting, where did you find this information? I follow the project on Github and got the impression it had slowed down since its announcement.
- fauigerzigerk 3y ago
  >Eh, I wouldn’t call Foundation its standard library... You're absolutely right, because the Swift Standard Library is a separate thing. It contains only the absolute essentials such as Int, String or Array: https://developer.apple.com/documentation/swift/swift-standard-library https://developer.apple.com/documentation/swift/swift-standa...

fzeindl 3y ago

Kotlin is a much more likely candidate. Excellent IDE support, deep integration with Java, already the go-to language for Android, many years of production and less "different" than Rust.

robertjpayne 3y ago
Kotlin running on the JVM is a disadvantage outside of Android though in a lot of spaces. Rust/Swift/Go will use a fraction of the ram to run a server application than Kotlin will.
- doctor_eval 3y ago
  I agree, a huge driver for me leaving the Java ecosystem for Go was the JVM. Maybe Kotlin native can address that, but despite what people in the Java world seem to believe, the JVM is a big disadvantage.
  - fzeindl 3y ago
    The JVM is one of the most optimized, most performant, most monitorable, most secure and most predictable software-runtimes there is. How exactly do you consider it a big disadvantage?
    - doctor_eval 3y ago
      The JVM may be full of technology that’s indistinguishable from magic, but deployment is a pain in the ass. Maybe things have changed in the last few years but - having to ship a huge file tree alongside the actual binary (or binaries because JARs are also a nightmare), and the slow startup time due to the need to interpret/compile bytecode instead of just running machine code, make Java really unpleasant to use in many common use cases.
      - fzeindl 3y ago
        Well I shipped fat jars using capsule more than 15 years ago without any issues. Nobody ships file-trees. Also the Startup depends on how much memory you allocate, but much of it is due to verifying class security, a feature that other runtimes don't even have. Or badly used reflection, another feature others don't have. In any case I really never found it an issue if a server takes 3 seconds to start and I never understood why people complained about Java startup. My guess is they complain about clunky desktop application with a million classes written in it. Regarding the bytecode: the interpretation and just in time recompilation gives Java sometimes better than native performance. It also allows you to hook into the code on the fly and transform it with agents. Can native do that?

mistrial9 3y ago

> Every incarnation of cross-platform on the market today sits somewhere between mediocre and bad in terms of the resulting UX .. seems heavy handed..