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

61–70 of 74 posts

Re: Interoperability: Swift’s Super Power

#61

Post by auggierose »

pjmlp wrote: post #56
auggierose wrote: post #55

Earlier quoted context omitted.

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.

I'd say there are plenty of use cases where access to 2015 hardware capabilities is more than enough, given that you will profit from any automatic speed improvements beyond 2015 hardware as well. Which features beyond 2015 are you referring to?

The code I ported wasn't Swift+Metal, it was just Swift. It certainly wasn't optimized in any way, but the Javascript one wasn't either. Javascript data structures are just faster, because they are fully imperative, the Swift ones are more expensive, despite some copy-on-write tricks. And remember, carefully written Javascript is just as fast as C.

Re: Interoperability: Swift’s Super Power

#62

Post by pjmlp »

auggierose wrote: post #61
pjmlp wrote: post #56

Earlier quoted context omitted.

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

I'd say there are plenty of use cases where access to 2015 hardware capabilities is more than enough, given that you will profit from any automatic speed improvements beyond 2015 hardware as well. Which features beyond 2015 are you referring to? The code I ported wasn't Swift+Metal, it was just Swift. It certainly wasn't optimized in any way, but the Javascript one wasn't either. Javascript data structures are just f…

Mesh shaders, ray tracing, unified memory, direct IO,...

V8 JIT is hardly as fast as C, almost there yeah, there is still a speed bump.

Re: Interoperability: Swift’s Super Power

#63

Post by doctor_eval »

fzeindl wrote: post #36
doctor_eval wrote: post #23

Earlier quoted context omitted.

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.

Re: Interoperability: Swift’s Super Power

#64

Post by mistrial9 »

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.

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

.. seems heavy handed..

Re: Interoperability: Swift’s Super Power

#65

Post by auggierose »

pjmlp wrote: post #62
auggierose wrote: post #61

Earlier quoted context omitted.

I'd say there are plenty of use cases where access to 2015 hardware capabilities is more than enough, given that you will profit from any automatic speed improvements beyond 2015 hardware as well. Which features beyond 2015 are you referring to? The code I ported wasn't Swift+Metal, it was just Swift. It certainly wasn't optimized in any way, but the Javascript one wasn't either. Javascript data structures are just f…

Mesh shaders, ray tracing, unified memory, direct IO,... V8 JIT is hardly as fast as C, almost there yeah, there is still a speed bump.

Yes, if you need these things, you will have to go native (although you will probably automatically benefit from unified memory).

For many many things, you won't, and then the ability to target Apple/Windows/Linux with exactly the same code, pain-free GPU access etc, that's just great. The other day I checked if I can access from the browser the 3D coordinates of my space mouse, and it just works, based on a standard Web API (GamePad API). While from Swift, it would be a hassle to setup and maintain.

Re: Interoperability: Swift’s Super Power

#66

Post by nsn90 »

cageface wrote: post #58
newZWhoDis wrote: post #57

Earlier quoted context omitted.

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

Re: Interoperability: Swift’s Super Power

#67

Post by fzeindl »

whoopsie wrote: post #54
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.

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.

Re: Interoperability: Swift’s Super Power

#68

Post by fzeindl »

doctor_eval wrote: post #63
fzeindl wrote: post #36

Earlier quoted context omitted.

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

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?

Re: Interoperability: Swift’s Super Power

#69

Post by doctor_eval »

fzeindl wrote: post #68
doctor_eval wrote: post #63

Earlier quoted context omitted.

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

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

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.

Re: Interoperability: Swift’s Super Power

#70

Post by dep_b »

pjmlp wrote: post #8

On the same note, watch Apple's talk at CppCon 2023, "Introducing a Memory-Safe Successor Language in Large C++ Code Bases" https://www.youtube.com/watch?v=lgivCGdmFrw

This is why I often skip the article and go straight to the comments on HN!

"Emergency recovery can be handled by a supervisor process" - this sounds a lot like Elixir to me, but I can't find any example in Swift.

Post reply on HN