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

Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

faultlore.com

Post reply on HN
Print view View original

71–80 of 279 posts

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#71

Post by pornel »

DelightOne wrote: post #69
pornel wrote: post #65

Earlier quoted context omitted.

You ask the vendor, since they need to look after their software anyway. Don't count on closed-source abandonware to conveniently have all vulnerabilities placed in external libraries.

I am talking about apps on the iPhone where Apple does not have access to developers' source code, right? We might be talking about different situations.

Updates of system libraries there are definitely a plus.

However, besides the OS itself Apple doesn't do anything about app security. Not only they don't require unbundling, they don't even support it. Even if you use dynamic libraries in your app, they will be bundled with your app, and never updated separately.

From App Store perspective there's absolutely no difference between a Swift app diligently split into frameworks and a Rust monolith library. They treat both as an opaque bundle.

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#72

Post by BulgarianIdiot »

Jweb_Guru wrote: post #48
mr_00ff00 wrote: post #44

Earlier quoted context omitted.

I know this might be opening a can of worms, but technically doesn’t Swift do reference counting? Which is faster than “mark and sweep” GC but will never compare to manual management (like C/C++ and rust ownership) I assume that’s the big reason.

Reference counting is not faster than tracing GC for general purpose workloads, at least not without a lot of extensive tuning that includes stuff like using tracing and moving GC for the young generation (prior to the first collection), deferring reference count increment/decrements using write barriers, limiting reference count bits (and reclaiming stuck objects with some variant of full heap tracing), and so on. M…

The Swift compiler does some of the optimizations/techniques you mention Rust does. It won't reference count, when the setup is possible to analyze statically and elide ref count. Swift also has widely used complex value types, which are stored on the stack. It will also even put some reference types on the stack after doing escape analysis etc.

I don't know which benchmark to trust anymore, but for some reason iOS software tends to seemingly overperform comparable ART (GC) code.

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#73

Post by pkulak »

mr_00ff00 wrote: post #44
jchw wrote: post #43

A lot of people who are invested in the Apple ecosystem have been trying to present Swift as a general competitor to Rust, but no matter how many bullet points you list, as far as I can tell, it hasn't made any progress at all on that front, and I haven't been convinced that it will change to become closer to that any time soon, either. As far as I can tell, there's really nothing wrong with Swift, and it probably ha…

I know this might be opening a can of worms, but technically doesn’t Swift do reference counting? Which is faster than “mark and sweep” GC but will never compare to manual management (like C/C++ and rust ownership) I assume that’s the big reason.

If reference counting was faster, Java would do it. It’s better for UIs and lower latency, but a modern, generational GC can beat C in throughput (because allocations get a lot faster).

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#74

Post by jchw »

galaxyLogic wrote: post #66
jchw wrote: post #53

Earlier quoted context omitted.

That's certainly a reason, but Go doesn't have the adoption issues that Swift has despite Google's reputation. Go's GC may be fast, and on some workloads maybe even competitive against ARC - But, I really don't think that has anything to do with why Swift isn't seeing widespread adoption outside of the Apple ecosystem. Here's my personal opinion for why. Bear with me for a second. I just searched "Swift programming l…

Apple's goal may be is to create a SW ecosystem that mostly only works on Macs. If a Swift application could be easily compiled to run on Windows, it would be much easier for Apple users to switch to Windows or Linux. And if Swift apps would run happily on all platforms Apple would still have an incentive to make them run fastest on Macs. Therefore it is not a good idea to rely on a computer manufacturer to provide y…

Microsoft has plenty of conflicts of interest to contend with, but that hasn't stopped them from being able to make some inroads towards appealing to other platforms. Perhaps it would be unwise to trust that they've "changed" and invest in Microsoft tools or ecosystems, but it's beside the point: I think it's fair to say that Visual Studio Code and TypeScript have achieved widespread success across the board.

I think that Apple could still make Swift a success outside of their own ecosystem if they wanted to. It would probably have a lot of benefits for them to do so too, but they're all pretty long-game gambles (not to mention quite large investments, too.)

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#75

Post by myko »

brundolf wrote: post #67
jchw wrote: post #43

A lot of people who are invested in the Apple ecosystem have been trying to present Swift as a general competitor to Rust, but no matter how many bullet points you list, as far as I can tell, it hasn't made any progress at all on that front, and I haven't been convinced that it will change to become closer to that any time soon, either. As far as I can tell, there's really nothing wrong with Swift, and it probably ha…

It's a bummer because I feel like I'd really like Swift if I felt it were a real, durable cross-platform language to spend time learning and using. Some of the trade-offs it makes seem really nice But I don't feel like Swift on non-Apple platforms will ever be more than a hobby for the Apple org

What's stopping you from using it on Linux, or your platform of choice?

It seems to be supported well enough, and Vapor is a decent toolkit for building a webapp with it.

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#76

Post by myko »

jasmer wrote: post #58
mr_00ff00 wrote: post #44

Earlier quoted context omitted.

I know this might be opening a can of worms, but technically doesn’t Swift do reference counting? Which is faster than “mark and sweep” GC but will never compare to manual management (like C/C++ and rust ownership) I assume that’s the big reason.

That's definitely the elephant in the room. And the fact that it does not have clean and easy C integration. If you could do direct memory stuff and control the ARC stuff, and easily integrate with C ... ... and the docs were clean, and you could easily use something other than XCode ... Then Swift would be huge. It's a neat language but it's just not designed to go beyond Mac. The entire C++ world would move away in…

Using VSCode instead of Xcode should work fairly well:

https://www.swift.org/blog/vscode-extension/

https://marketplace.visualstudio.com/items?itemName=sswg.swi...

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#77

Post by Klonoar »

jeroenhd wrote: post #10
zyang wrote: post #8

Earlier quoted context omitted.

Swift is backed by LLVM and Linux solid is pretty solid. The cross platform problem has always been the core libraries. Fortunately a pure Swift core foundation rewrite is underway. https://www.swift.org/blog/future-of-foundation/

Looks like I may eventually give Swift a try once the rewrite is done! I've been watching Swift for a while now but I don't have a Mac so I haven't had a reason to try it. Do you happen to have any idea about UI library support? Will UI still be Apple only?

It's not out of the question for someone to write a (e.g) GTK-backed SwiftUI API library.

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#78

Post by myko »

zokier wrote: post #9
apatheticonion wrote: post #4

I have heard great things about Swift but haven't spent a second looking into it because I assumed it's an Apple exclusive language - making it unsuitable for my use case of services deployed on Linux, developed from any OS. To what extent, if any, is Swift exclusive to Apple devices?

At one point IBM attempted to make swift viable on the sever-side: https://news.ycombinator.com/item?id=21808619

Kitura is no longer maintained but one of its primary competitors is still going strong: https://vapor.codes/

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#79

Post by sweetjuly »

jasmer wrote: post #58
mr_00ff00 wrote: post #44

Earlier quoted context omitted.

I know this might be opening a can of worms, but technically doesn’t Swift do reference counting? Which is faster than “mark and sweep” GC but will never compare to manual management (like C/C++ and rust ownership) I assume that’s the big reason.

That's definitely the elephant in the room. And the fact that it does not have clean and easy C integration. If you could do direct memory stuff and control the ARC stuff, and easily integrate with C ... ... and the docs were clean, and you could easily use something other than XCode ... Then Swift would be huge. It's a neat language but it's just not designed to go beyond Mac. The entire C++ world would move away in…

I've found Swift->C to interop very well with Swift. Yes, you get absolutely buried in UnsafeXXX wrapped types but it does do exactly what you expected. Going the other way is somewhat "herebe dragons" since @_cdecl is technically non-standardized (though there is a movement to standardize it [1]) but it definitely works fine.

[1] https://forums.swift.org/t/formalizing-cdecl/40677/7

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#80

Post by ridiculous_fish »

galaxyLogic wrote: post #57

How do they handle "DLL Hell"?

DLL Hell comes when you have multiple versions of dynamically linked libraries from third parties. In practice, Swift's dynamic linking exists to support Apple's own first-party libraries which are shipped with the system, so there is no DLL Hell. There is only one UIKit at a time.
Post reply on HN