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

241–250 of 279 posts

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

#241

Post by pcwalton »

lll-o-lll wrote: post #199
pcwalton wrote: post #176

Earlier quoted context omitted.

> Most projects do not require what Rust provides at the cost it provides it at. If this is true, it's because most projects should use a GC'd, memory safe language, not because most projects should use memory unsafe languages. There is little to no place for memory unsafe languages such as C++ for new projects in 2023. > Also I think that Rust is a 'V1' version of a borrow checker and I can't wait for newer iteratio…

Swift is memory safe. It’s the better C++ I want, just out of reach because Apple. There is at least one memory safe alternative to Rust that doesn’t require a GC. I’ve made this argument before but here we go again. GC is great and works better and faster than reference counting in most cases, but there are degenerate cases and they matter on phones. One degenerate case is memory pressure. A GC running out of memory…

Reference counting is a form of garbage collection, and therefore Swift is a GC'd language.

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

#242

Post by [deleted] »

lll-o-lll wrote: post #199
pcwalton wrote: post #176

Earlier quoted context omitted.

> Most projects do not require what Rust provides at the cost it provides it at. If this is true, it's because most projects should use a GC'd, memory safe language, not because most projects should use memory unsafe languages. There is little to no place for memory unsafe languages such as C++ for new projects in 2023. > Also I think that Rust is a 'V1' version of a borrow checker and I can't wait for newer iteratio…

Swift is memory safe. It’s the better C++ I want, just out of reach because Apple. There is at least one memory safe alternative to Rust that doesn’t require a GC. I’ve made this argument before but here we go again. GC is great and works better and faster than reference counting in most cases, but there are degenerate cases and they matter on phones. One degenerate case is memory pressure. A GC running out of memory…

[deleted]

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

#243

Post by brundolf »

hutattedonmyarm wrote: post #157
brundolf wrote: post #91

Earlier quoted context omitted.

My understanding is that it's got second-class Linux support, for now. What happens when Apple loses interest? What about Windows? I don't get a sense of commitment from them outside of their own platforms, and that doesn't make me want to commit to learning or starting major projects in the language (outside of their platforms). If I can't have faith my project's foundation will continue to be solid, then I don't wa…

Foundation (Swift's stdlib so to speak) is being rewritten as OSS [0] which will unify it between Linux and macOS. Right now, they use a different implementation on each platform [0]: https://www.swift.org/blog/future-of-foundation/

And that's well and good, it's clear there are some engineers at Apple who would really like to see Swift become something more than just The Apple Language, but at the end of the day they aren't the ones getting to set the priorities. And my (very subjective/anecdotal/external) impression is that the business is just sort of humoring them - maybe Linux support helps a little with internal CI or something - without actually prioritizing multi-platform Swift. If a company with Apple's resources cared about multi-platform Swift, at the business level, we would've seen sterling support yesterday.

For comparison, look at what Microsoft's done with .NET since they started to prioritize multi-platform support.

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

#244

Post by neerajsi »

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?

GC has worse p99 latency, even if it may have better throughout.

Also, with manual memory management, you can do all your allocs and frees on other threads that are not executing your latency sensitive logic.

With GC, you have to at least execute a stack scan on every thread, and possibly a few extra stw passes. The highest performance gcs also have a lot of peanut butter costs from read barriers.

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

#245

Post by ahartmetz »

ahartmetz wrote: post #193
gumby wrote: post #145

The TL;DR is: Swift strives for ABI stability, Rust does not. There's also a driveby comment that C++ doesn't really support dynamic linking because of all the templates in its standard library, which is a weird statement to make.

Yeah - the big, complicated parts of platform libraries for which post-release bugfixes make sense are usually not templated. The vector container class is a template, but Korean input method support is not.

(Actually, Korean was not a great choice of example. The Korean writing system isn't very complicated. Japanese would have been better - they even have three writing systems!)

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

#246

Post by jchw »

Kukumber wrote: post #234
jchw wrote: post #231

Earlier quoted context omitted.

No doubt people are busy using Swift, but Apple technology advocates are about as "religious advocates" as they come. And frankly, I'm not trying to say that as some kind of negative. It can be annoying, but clearly Apple users are genuine enthusiasts, even if I can't really see eye-to-eye with them. I do think that this genuine enthusiasm creates some distorted images of the reality of the world, though. The thing i…

for 1 article like this, you get 1000000 ones from "rust evangelists from the Rust Evangelism Strike Force" both can coexist, yet for the rust crowd only one must prevail that's what's annoying about rust and its religious community my previous comment's score is (-1), that speaks for itself don't you think ;)

All that says is that people decided to downvote the comment. I honestly think that's mainly because people feel it is an unfair or flippant characterization; obviously, plenty of people DO write Rust. Even despite the position Apple is able to hold Swift in with iOS, that has not stopped Rust from being similarly popular among professional developers; in Stack Overflow's last survey, double the professional respondents claimed to use Rust than Swift:

https://survey.stackoverflow.co/2022/#section-most-popular-t...

Even if you consider some of the respondents to be lying on purpose to skew the stats, I'm of a mind to believe that failing any real incentive, a majority of the correspondents are likely telling the truth. (The numbers don't show anything too wild, after all: JS on top, and C/C++ having a commanding lead on "modern" alternatives.)

Believe me though, some of my comments in this thread also got downvoted before recovering. The sad thing is, I don't really harbor any ill intent, I'm being blunt because I genuinely want things to be better; after all, if Swift is so good for developers, then I definitely would like to be able to consider it an option, especially considering that Rust is, frankly, a pain in the ass to code in sometimes. Today I do not, and what I need is a louder and clearer signal from Apple, not assurance from a community.

All in all, I am not really disagreeing that Rust has an extremely enthusiastic userbase. But what I am definitely disagreeing with is the idea that it's just hype. From my PoV, I 100% understand the value proposition of Rust. As an alternative to C and C++ it's extremely compelling, and in practice it's being integrated into large and complex applications like web browsers today in core components like the rendering engine, video codecs, etc.

As a closing note, to see why Rust and Swift are different ball games entirely, I feel you only need to ask just one simple question: "Why can't Swift serve the purpose Rust is serving in the Linux kernel, Firefox, Chromium, etc?"—each one has its own answers: insufficient control over memory allocations, interoperability issues, missing support for platforms or CPU architectures, lack of alternative toolchains (believe it or not, both Go and Rust have multiple complete toolchains; see gccgo, rust-gcc, mrustc, and even more if you count less complete implementations), and probably more things that I lack knowledge of. Finally, Rust just simply has more outreach: I can install it from my distribution's own packaging in virtually any Linux distro, it supports a lot of architectures and platforms even if they're not all tier-1, the rustup and cargo tools make it extremely fast and easy to get started, and more. Apple could totally close the gap here, but until they do, I don't feel like investing time into this language is a good idea for me personally. Like I said, I genuinely consider this to be a shame.

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

#247

Post by atq2119 »

josephg wrote: post #135
comex wrote: post #130

Earlier quoted context omitted.

That post keeps being linked in these discussions but it's highly misleading. > Do your installed programs share dynamic libraries? > Findings: not really The posted findings actually show that common libraries ranging from libc to libX11 are used by high-hundreds to thousands of binaries. The fact that there are also a lot of not-widely-shared dynamic libraries doesn't seem particularly significant. > Wouldn't stati…

> This analysis is completely wrong because it ignores the effect of transitive dependencies. I hear your criticism, and I'd love to see the corrected results for this. My instinct is that most fully statically linked binaries wouldn't be that much bigger than their dynamically linked counterparts even with transitive inclusion. But I don't know for sure. Honestly I'm surprised its not easier to run these experiments…

At least with ELF, shared libraries are organized into segments and you really only have a handful of them. The information about where individual function boundaries are has been thrown away and in principle this can matter, e.g. if cold code was moved away from hot code. Therefore, the linker can't just split the segments apart.

As for your instinct, it'd be wildly wrong depending on the use case. Maybe if you only link with libc, sure. But now consider linking against something like a GUI framework...

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

#248

Post by maldev »

mpawelski wrote: post #41
maldev wrote: post #17

Earlier quoted context omitted.

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.

MAUI is not working on Linux, still Microsoft market it as "cross-platform" which is super misleading at best (and pure lie at worst).

Wow, you're right. I stand corrected. I've been leveraging it for Windows and Macos, and incorrectly assumed it would work on Linux as well. And when I did target linux it was using the Blazor(Webview stuff). Thanks for the correction, such a weird decision for Microsoft to market it as cross platform so heavily and omit Linux. I would definitely put it on Lie tier. Even more strange since some other features have first class linux support like compiling to native code, but others like Blazor apparently omit only linux.

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

#249

Post by oconnor663 »

zaphar wrote: post #112
oconnor663 wrote: post #97

Earlier quoted context omitted.

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

There are many differences when it comes to safety:

- Like you said, Rust doesn't let you data race on the contents of an Arc.

- Rust also doesn't let you data race on the Arc itself (i.e. repointing a global Arc without synchronization). This is Bug #5 in this great talk: https://youtu.be/lkgszkPnV8g

- Rust also doesn't let you retain a reference to the contents of an Arc longer than you retain the Arc. This is the bug that C++ Core Guideline R.37 is about: http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#...

But I'm not sure I'd call these Arc vs shared_ptr differences per se, because almost any comparison between a Rust container and its C++ equivalent looks similar.

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

#250

Post by mr_00ff00 »

pjmlp wrote: post #235
mr_00ff00 wrote: post #233

Earlier quoted context omitted.

I don’t think your article makes the claim Java keeps up with C++. That article seems to be about getting latency low and consistent so Java can compete with C++.

It keeps enough when the measurement is delivering products into production, that is what matters to business owners, not winning language benchmarks.

Fair enough, although is Java specifically the only language that could do this?

It surprises me that people turn to Java instead of say Go or Elixir or (keeping on topic with the article) Swift?

Post reply on HN