Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interoperability: Swift’s Super Power

browsercompany.substack.com

Post reply on HN
Print view View original

31–40 of 74 posts

Re: Interoperability: Swift’s Super Power

#31

Post by FlyingSnake »

robertjpayne wrote: post #22
fzeindl wrote: post #19

Earlier quoted context omitted.

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.

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.

One big potential pitfall people seldom discuss is that Java is moving in a different direction and taking JVM along with it. This will cause problems in the future for Kotlin in areas such as reification and nullability.

Re: Interoperability: Swift’s Super Power

#32

Post by robmccoll »

robertjpayne wrote: post #22
fzeindl wrote: post #19

Earlier quoted context omitted.

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.

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.

Kotlin compiles to the native architecture on non-JVM targets. It works just as well as using Swift on non-Apple targets, that is to say it's a bit of a pain development-wise but runs fine once you have your tool chain and interop code setup. Honestly versus either, I'd recommend dart/flutter. Insanely productive, native compiled code, performant UIs that reasonably emulate native (although I'd recommend avoiding that and going stylized - users are more willing to accept something different than something close but not quite right). And interop with C++ is pretty easy.

Re: Interoperability: Swift’s Super Power

#33

Post by mplewis9z »

jamil7 wrote: post #18
K0nserv wrote: post #7

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.

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,…

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.

Re: Interoperability: Swift’s Super Power

#34

Post by jwells89 »

robertjpayne wrote: post #22
fzeindl wrote: post #19

Earlier quoted context omitted.

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.

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.

Also, it brings various Java baggage along for the ride, which isn’t everybody’s cup of tea.

And while it’s syntactically similar to Swift, I find it to be overall less ergonomic in various ways.

Re: Interoperability: Swift’s Super Power

#35

Post by jamil7 »

mplewis9z wrote: post #33
jamil7 wrote: post #18

Earlier quoted context omitted.

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,…

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…

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

Re: Interoperability: Swift’s Super Power

#36

Post by fzeindl »

doctor_eval wrote: post #23
robertjpayne wrote: post #22

Earlier quoted context omitted.

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.

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.

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?

Re: Interoperability: Swift’s Super Power

#37

Post by fzeindl »

jwells89 wrote: post #34
robertjpayne wrote: post #22

Earlier quoted context omitted.

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.

Also, it brings various Java baggage along for the ride, which isn’t everybody’s cup of tea. And while it’s syntactically similar to Swift, I find it to be overall less ergonomic in various ways.

Which Java baggage do you mean?

Re: Interoperability: Swift’s Super Power

#38

Post by fauigerzigerk »

mplewis9z wrote: post #33
jamil7 wrote: post #18

Earlier quoted context omitted.

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,…

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…

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

Re: Interoperability: Swift’s Super Power

#39

Post by jwells89 »

fzeindl wrote: post #37
jwells89 wrote: post #34

Earlier quoted context omitted.

Also, it brings various Java baggage along for the ride, which isn’t everybody’s cup of tea. And while it’s syntactically similar to Swift, I find it to be overall less ergonomic in various ways.

Which Java baggage do you mean?

Package/build management is one, gradle drives me crazy sometimes. Haven’t used maven so can’t speak about it.

Re: Interoperability: Swift’s Super Power

#40

Post by auggierose »

pjmlp wrote: post #27
auggierose wrote: post #16

Earlier quoted context omitted.

Yes, exactly. Interoperable doesn't mean much if it is not properly cross platform. I've tried Dart for a project, and it worked OK, but in my opinion TypeScript is clearly the way to go in the foreseeable future.

Typescript is limited by V8 capabilities, and the constraints of a dynamic language JIT. To achieve best perfomance one needs to write C++ code as native modules. Interoperable means a lot even inside Apple ecosystem, bringing all those C, Objective-C and now C++ code with ease into Swift projects. Using Metal from Swift, althought implemented in Objective-C and C++, is already a productivity boost compared to anythi…

If you are on the Apple platform only, Swift is great, and I enjoyed using Metal myself. But eventually I accepted how much it limited what I can do as a developer. So, I prefer TypeScript now. I am not touching C++ or stuff like that, if I need performance, I compile to web assembly, hopefully soon from my own language :-)
Post reply on HN