Live data from Hacker News

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

faultlore.com

51–60 of 279 posts

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

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

I think you’re missing the context that people are choosing Rust over Swift even in domains like backend web development which should theoretically be a good fit for Swift. And this is largely because the Swift ecosystem outside of Apple is pretty minimal.

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

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

After using Rust for my own personal tryouts, I liked it more than expected, and though I see the value in the borrow-checker don't work in areas where it's warranted.

In most of my uses, I would be fine always using Rc/Arc which would make Rust equivalent to using Swift.

As a language though, I much prefer Rust to Swift.

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

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

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 language" on my search engine and the first result looks promising:

> https://developer.apple.com/swift/

OK. It's a language by Apple, so it's not surprising that it's on Apple's website, even though I think if you want people to get the idea that it's a serious independent project you probably should give it its own top-level site personally. (edit: Yes, I know it does. This is my honest first impression. Please keep reading.)

> Swift is a powerful and intuitive programming language for iOS, iPadOS, macOS, tvOS, and watchOS.

Alright, we're only talking about Apple platforms. Technically it doesn't say that it can't work outside of these OSes, but it's clear that Apple is not marketing Swift as a general purpose operating system. From Apple's marketing PoV, it's an operating system that is made for Apple platforms and anything else is incidental.

> Download Xcode and learn how to build apps using Swift with documentation and sample code.

No download links for users of other operating systems. But if you go to that link, all the way at the bottom, you get:

> Swift is developed in the open. To learn more about the open source Swift project and community, visit Swift.org.

Finally, you might notice that Swift is actually available outside of macOS. It's available for Windows and Linux, but not BSD as far as I can ascertain. The platform support of Swift is excellent when it comes to Apple devices, but it lags far behind other options when it comes to other platforms and architectures.

My perception is that Apple hasn't really made a serious enough investment into making Swift a general purpose programming language outside of its own ecosystem. That's honestly fair, as doing so is no doubt extremely expensive and time-consuming, and it's an on-going investment.

What they're doing now appears to kick it to the community, who has done a lot, including as far as I can tell, make Swift work on RISC-V. But Apple is literally the world's biggest technology company, so it's not exactly desirable to put a bunch of community effort into giving it the on-going support that it needs to feel "first-class" outside of Apple platforms.

Even just the optics here are quite bad, and I think the fact that it's still like this is going to haunt the long-term prospects of Swift outside of Apple platforms.

All of this is aside from its technical merits. Normally, I'd like to stick to purely just technical merits, but unfortunately this stuff does matter. It's part of the reason why Go is still a solid choice today even though Rust has a lot of technical advantages on paper.

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

#54
In 2020 I wanted to leverage the new apple silicon in my Rust app, so I needed to do some work in Swift, and maybe i was looking in the wrong spots - but the Swift community felt incredibly dead. Swift documentation is horrible, I asked for help in a few places online and got none. I eventually solved the problem by guessing to fill in the gaps of documentation. A very different experience than the rust community, which was extremely eager to help with every problem I had.

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

#55
Aria is so good at putting things into accessible (and entertaining) words. One of the best at it I've ever seen (they're the same person who wrote the (in)famous "Learn Rust by writing Entirely Too Many Linked Lists", which is one of my favorite pieces of technical writing of all time)

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

#56
post #53

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

> OK. It's a language by Apple, so it's not surprising that it's on Apple's website, even though I think if you want people to get the idea that it's a serious independent project you probably should give it its own top-level site personally.

You mean like it does have? https://www.swift.org/

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

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

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 an instant to something clean and flexible. Rust is just too specific for most things, and Swift is just about outside. So sad.

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

#59
post #37
post #33

Earlier quoted context omitted.

Security updates, though? I mean, you aren't wrong. But there were other advantages to dynamic linking.

Dynamic linking is not the only way to deliver security fixes, just one particular, limited, C-oriented solution. Note that dynamic linking is also not sufficient to change C++ templates or C header-only libraries. It shifts all of the code replacement complexity from the OS (just replace a file) onto the language and library authors (ABI compat, fragile base classes, no inlining or generics). Rust/Cargo gives you Ca…

So.. how do you rebuild apps without having access to their source code?

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

#60
post #31

Dynamic linking is in my opinion not that useful anymore in this day and age where the few MB of RAM and disk space you save is not worth the hassle. The amount of dynamic linking issues I encountered on GNU/Linux was insane (fuck libstdc++). Not even glibc manages to keep forward compatibility working (breaking memcpy, breaking DT_HASH, ...)! It's much better to just statically link your binaries (unfortunately many…

It's a common argument of computers getting powerful so we don't need to care that much for performance and/or efficiency regarding to cpu/memory/storage etc. In some limited cases the argument is valid but most of the time it's not.

First of all while maybe desktops and mobile phones are more powerful now, but we're getting more and more lower spec devices, like smart watches. Even when smart watches will be powerful enough one day, there will be eventually smaller computers, like smart contact lens, nano robots that run in blood vessels etc.

Secondly efficiency is still favourable for powerful computers. A small percentage of cost reduction can be big money save for large corps. A small percentage of energy save of all (or just a portion of) computers in the world can be a big win for the environment.

Lastly, we also run VMs and containers everywhere. Notice how we've already come up with all kind of ways to minimise VMs and containers size and footprint, in order to run more of them, to start them faster, and to transfer images quicker.

Post reply on HN