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

51–60 of 74 posts

Re: Interoperability: Swift’s Super Power

#51

Post by fauigerzigerk »

robmccoll wrote: post #32
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.

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

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?

Re: Interoperability: Swift’s Super Power

#52

Post by geodel »

jwells89 wrote: post #39
fzeindl wrote: post #37

Earlier quoted context omitted.

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.

Re: Interoperability: Swift’s Super Power

#53

Post by fzeindl »

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.

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.

Re: Interoperability: Swift’s Super Power

#54

Post by whoopsie »

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.

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.

Re: Interoperability: Swift’s Super Power

#55

Post by auggierose »

pjmlp wrote: post #46
auggierose wrote: post #40

Earlier quoted context omitted.

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

Web Assembly and performance on the same sentene is an oxymoron.

WebGPU + WebAssembly + TypeScript is going to be a pretty potent combo. I doubt Swift + Metal is more performant. Actually, when I translated some Swift code to JavaScript, it ran faster.

Re: Interoperability: Swift’s Super Power

#56

Post by pjmlp »

auggierose wrote: post #55
pjmlp wrote: post #46

Earlier quoted context omitted.

Web Assembly and performance on the same sentene is an oxymoron.

WebGPU + WebAssembly + TypeScript is going to be a pretty potent combo. I doubt Swift + Metal is more performant. Actually, when I translated some Swift code to JavaScript, it ran faster.

WebGPU exposes 2015 hardware.

If you failed to make Swift + Metal perform better than JavaScript, there is something really horrible with your code.

Re: Interoperability: Swift’s Super Power

#57

Post by newZWhoDis »

robmccoll wrote: post #32
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.

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

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.

Re: Interoperability: Swift’s Super Power

#58

Post by cageface »

newZWhoDis wrote: post #57
robmccoll wrote: post #32

Earlier quoted context omitted.

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

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

Re: Interoperability: Swift’s Super Power

#59

Post by Narishma »

auggierose wrote: post #6

I don't know, I left Swift (although I like the language) because it is not interoperable whatsoever, in the sense that you can use it on whatever platform you like. I switched to TypeScript.

You can use it on any platform you like, as long as it's an Apple platform.

Re: Interoperability: Swift’s Super Power

#60

Post by BrianHenryIE »

Narishma wrote: post #59
auggierose wrote: post #6

I don't know, I left Swift (although I like the language) because it is not interoperable whatsoever, in the sense that you can use it on whatever platform you like. I switched to TypeScript.

You can use it on any platform you like, as long as it's an Apple platform.

The article is about how great it is now to use on Windows.

I have projects using Swift on AWS Lambda and on Arduino.

* https://github.com/swift-server/swift-aws-lambda-runtime

* http://www.swiftforarduino.com/

* https://forums.swift.org/t/embedded-swift/67057

Post reply on HN