Live data from Hacker News

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

faultlore.com

21–30 of 279 posts

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

#21

Love the article. In my mind I see the problem of dynamic linking in rust to have a bunch of overlap with the "I want this rust library to be exposed in my higher level GC'd language with minimal safety issues/tedious handmaintained bindings" problem. My hunch is that the lack of expressiveness of the C ABI is holding back both. the thing I'd love to see some sort of "higher level than the C ABI" come out. And someth…

So, COM?

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

#22
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?

I see no reason for Apple to ever make the UI stuff available on other platforms, I can’t see how that would benefit them.

But there’s nothing stopping other UI libraries from making Swift bindings.

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

#23

My very vague understanding of Swift’s dynamic linking is that it works but comes with a huge performance penalty. To the point of it becoming unusable for high-performance apps. Is that wrong?

Yes, it is wrong. The article explains this quite well how you can trade performance and ABI stability.

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

#24
post #12

Earlier quoted context omitted.

I'd say that it isn't particularly useful, outside of the Apple ecosystem, but I do know that there has been Linux, and even Windows, support. In my case, I don't really care, as I program Apple native. I think it's an excellent language. I enjoy writing in it. I write Swift, every day.

Conversely, I don't really care about swift because it isn't particularly useful outside of the apple ecosystem.

Exactly. I wasn't trying to be dismissive. It's just the way things are.

Some people loathe everything Apple. They Just. Hate. Apple.

I've been dealing with that for over thirty years. Some people hate me, for no reason, other than I write code for Apple devices.

I don't hate anyone else, but I've tried programming a number of systems, and haven't enjoyed it as much, as I do, working with Apple's stuff.

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

#25

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?

Not exclusive to Apple devices at all.

More details about platform support: https://www.swift.org/platform-support/ (tl;dr Apple platforms, Linux, Windows)

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

#26
post #21

Love the article. In my mind I see the problem of dynamic linking in rust to have a bunch of overlap with the "I want this rust library to be exposed in my higher level GC'd language with minimal safety issues/tedious handmaintained bindings" problem. My hunch is that the lack of expressiveness of the C ABI is holding back both. the thing I'd love to see some sort of "higher level than the C ABI" come out. And someth…

So, COM?

The greatest trick Swift's developers ever performed was convincing the world that it wasn't just a better UX layer on top of COM

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

#28
post #23

My very vague understanding of Swift’s dynamic linking is that it works but comes with a huge performance penalty. To the point of it becoming unusable for high-performance apps. Is that wrong?

Yes, it is wrong. The article explains this quite well how you can trade performance and ABI stability.

The article doesn’t have any performance metrics. It mentions surprising performance cliffs but I couldn’t find details. It says there is a perf cost you can opt out of but doesn’t detail the cost or what you lose by opting out.

It sure seems from the article that there are a lot of negative performance implications. Which totally be a price worth paying! But I would not agree that the article explains what that price actually is.

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

#29
post #17

Earlier quoted context omitted.

That's really not the case with C# or Go. C# has first class Linux support nowadays (minus GUI support) and using Go on windows is quite easy (I daily drive go on windows at work).

With Maui, you can now have first class Linux gui support, same with Blazor. You can also even do some of the more cutting edge stuff on linux like compiling straight to ASM.

.NET MAUI doesn't have first class Linux GUI support. Unless you count Android as Linux. [1]

There were some unofficial efforts for Linux GUI support for MAUI's predecessor (Xamarin Forms), but never first party support.

[1] https://learn.microsoft.com/en-us/dotnet/maui/supported-plat...

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

#30

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?

I think that Apple control where the language goes. That mean that things will serve other use cases only accidentally.

fast.ai was very interested in Swift but dropped that project for that reason.

Post reply on HN