Hacker News Reader

Comment by K0nserv | Hacker News Reader

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.

View on HN

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.

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.

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

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

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.

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?

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.

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?

The file tree I was referring to is the JRE, not the code.

In any case, if Java works for you then that’s great. I’m just relating my own experience, where I found that the need for a JVM was less of a blessing than a curse.

As a former C developer who has been using Java for 20+ years, moving to Go was like lifting a weight off my shoulders. (I suspect I’d have felt the same with Rust, Swift or any other modern AOT language). It’s so refreshing to just have a binary, and be able to execute it, and not worry about a pile of irrelevant external factors.

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.

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.

So if Kotlin targets two completely seperate platforms (JVM and native) does that mean any C++ interop would have to be written seperately and differently for each of those platforms?

Flutter is trash (slow and ugly) built on a dead end language (dart).

Any company building their business on flutter is setting themselves up for disaster and an expensive double-rewrite to native, while having a useless engineering team because they skilled up previously mentioned dead-end.

I guess you better let Apple know so they don’t accidentally make a Flutter app their app of the day again:

https://flutter.dev/showcase/so-vegan

the article displays a couple of screenshots on why it's a poor experience, bottom navigation is to small and the back button is behind the camera, it's very unlikely to be fixed at the component level so devs end fixing these issues themselves by creating a new component that may not behave entirely as the system one, using the device's safe area

I don’t see the same issues you mentioned when checking the screenshots on their App Store / Play Store pages. But that was a good catch of yours.

I’m relatively confident that they used a device frame around their actual screenshots, which leads back to those issues you mentioned. You can tell that they’ve used different device frames in their current store listings compared to the realistic looking ones on the aforementioned Flutter showcase page.

This whole process can even be automated. I’m talking about a CI/CD workflow that takes screenshots of specific pages, and adding device frames around them etc. See this tool for example: https://docs.fastlane.tools/actions/frameit/

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.

Exactly right. It seems difficult for so many folks to understand Kotlin is not some independent language from scratch but another JVM language trying to avoid Java's supposedly shortcomings. And Kotlin/Native/Web doesn't matter because core language design is simply informed by Java and other JVM ecosystem languages' features and limitations. I think Kotlin is newer/better horse cart to Java's old cart rather than automobile.

Further as others have mentioned Java's 6 month release cycle and ton of changes at language/VM/library layers will make it difficult for Kotlin to choose between complying to latest JVM or chart an independent path.

So true. I feel sorry for my Android colleagues. There’s a reason our iOS team ships much faster and has a far lower crash rate.

This is correct but not because of Java. The android SDK is terrible because of many reasons.

Which is also the reason why kotlin is so popular there. Using extensions function and concise syntax you can build clutches around this terrible abomination of an SDK.

The JVM uses as much RAM as you allocate in your program. If you get along with 4 megabytes then you can set the maximum memory of the JVM to 4 megabytes and it will never use more than that.

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

.. seems heavy handed..

Reply on news.ycombinator.com