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

111–120 of 279 posts

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

#111

Post by acomjean »

andyonthewings wrote: post #60
greyw wrote: 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 powerfu…

So are you saying use Rust, more efficient at the expense of maybe using more memory? Or swift which may save some memory by being dynamically linked but perhaps is a little slower.

Honestly a ton of code is utility code, not run that often and nobody wants to take the time or expense to rewrite that Perl/python/bash script.

Some code efficiency is much more important than others.

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

#112

Post by zaphar »

oconnor663 wrote: post #97
low_tech_punk wrote: post #95

Could someone help explain the difference between Rust ARC (Atomically Reference Counted) vs. Switch ARC (Automatic Reference Counting)? Do the language designers intentionally chosen the same acronym to confuse us?

Rust's Arc is very similar to C++'s shared_ptr. It's a generic container type, which does reference counting on the inside. I haven't written Swift, but I believe reference counting is mostly automatic and transparent there, more like a GC strategy than like a container. Not sure whether anyone's to blame for the name collision :)

With one very important difference. Unless you use a thread_safe interior mutability implementation like Mutex Arc won't allow you modify or change the wrapped value. C++'s shared_ptr does not enforce the same. All of which means that while the shared_ptr control block is thread safe what the shared_ptr contains may or may not be. This has caused, and will continue to cause, no end of confusion for folks doing C++ especially for less experienced devs.

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

#113

Post by greyw »

Joker_vD wrote: post #85
greyw wrote: post #42

Earlier quoted context omitted.

The end user gets a single statically linked binary which is what matters. The quoted sentence refers to distro maintainers providing new binaries.

Ah, so I (the programmer) build object files, send them to the distro maintainers, they link them with their specific versions of the libraries, ands send the resulting executable binary to me/other users. ...that's remote dynamic linking, only with (potentially) human intervention in the loop. I kinda see how it would have worked better if the distro maintainers cared about package quality and speedy updates but the…

The distro maintainers take your source code and package it. If they need to update the program due to an outdated dependency they don't need to recompile the whole program but rather just relink their cached object files with the newer version of the static library (if applicable).

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

#114

Post by saagarjha »

sweetjuly wrote: post #84
alin23 wrote: post #13

This past week I’ve been reverse engineering the macOS IOMobileFramebuffer to find a way to disconnect displays in software for Lunar ( https://lunar.fyi/ ). And I kept stumbling upon these witness tables while debugging. This led me to find this write-up and the much more interesting story behind it. The end note was priceless ^_^ collapses

I feel your pain, reverse engineering Swift is such a nightmare. I don't know if Ida handles it better but both Ghidra and Binja produce entirely inscrutable disassembly.

Nobody really cares about it, unfortunately. There’s not much reason things have to be this bad, other than lack of investment.

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

#115

Post by zaphar »

mr_00ff00 wrote: post #90
pkulak wrote: post #73

Earlier quoted context omitted.

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

Genuine question, but if that were true then why does High Frequency Trading and Performance critical applications use C if GCs can beat it?

The two biggest languages I'm aware of in that space are Java and C++. I don't think I've heard of any shop using C. Java seems to be keeping up with C++ there as far as I know. Do you have evidence to the contrary?

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

#116

Post by acomjean »

wilg wrote: post #89
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…

This is all very hand-wavey. Are you just describing a chicken-and-egg scenario? Also, Swift probably can compete with Rust, especially when they finish adding Rust-style lifetimes. But the real advantage of Swift is it has a much more "high-level" feel than Rust – it's much more familiar to use than Rust by virtue of having classes and things. Swift also doesn't instantly force you into weeds of dealing with memory…

I think swift competes more with go than rust.

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

#117

Post by jasmer »

galangalalgol wrote: post #88
jasmer wrote: post #58

Earlier quoted context omitted.

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…

What do you mean about rust being too specific for most things? It seems like a fairly obvious choic for c++ replacement in a new project, the issue is large c++ codebases already exist, and that migration is painful in my experience. Autocxx type support is still largely missing or in work, diplomat seems reasonable, but I haven't had an opportunity to use it for something real yet.

Rust will not replace C++. Everything is thrown out the window, including developer productivity in order to provide the 'zero overhead runtime guarantee' feature. The code ends up quite laborious, and it's just not suitable for many things, and it doesn't play so easily with C.

Most projects do not require what Rust provides at the cost it provides it at.

C++ people really wants a C++ that is clean, modern, parsable, without all the legacy cruft.

Also I think that Rust is a 'V1' version of a borrow checker and I can't wait for newer iterations which I think will be better.

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

#118

Post by [deleted] »

brink wrote: post #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, wh…

[deleted]

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

#119

Post by saagarjha »

Kukumber wrote: post #98
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…

People are busy using Swift rather than trying to religiously advocate for Rust on various websites One example: Arc is a webkit powered browser written in swift and is crossplatform: https://twitter.com/hursh/status/1612472691747090432

Don’t think it is yet, and it uses Chromium

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

#120

Post by saagarjha »

BulgarianIdiot wrote: post #72
Jweb_Guru wrote: post #48

Earlier quoted context omitted.

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

Value types are stored wherever appropriate. If they escape they’re going on the heap like everything else.
Post reply on HN