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

231–240 of 279 posts

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

#231

Post by jchw »

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

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 is, Apple users are likely so used to having more enthusiasm than competing communities of higher marketshare products and services that it's not surprising at all that the perception is that Rust is all hype. I'm more a Go coder than Rust by SLoC, and Rust has to be one of the most enthusiastically supported languages I've ever seen.

Still, it'd be silly to discredit Rust on the basis of its enthusiastic userbase: it's successful by any measure. It's invading the Linux kernel, the campuses of Amazon, Google, Microsoft, it's going to be in both Firefox and Chromium, and that's really just the beginning. Even if Swift had more collective SLoC than Rust, Rust is clearly on its way to solidifying its place as one of the most impactful programming languages of the past 20 years. That impact is even going to be felt in Swift: when talking about Swift, it is very common to advertise it in terms of Rust. I mean hell, that's basically what this blog post title does: "Look, Swift did something even Rust couldn't!" -- If Rust wasn't so influential, I do not think anyone would bother to compare the two in this way.

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

#232

Post by xedrac »

zozbot234 wrote: post #212
xedrac wrote: post #99

Earlier quoted context omitted.

I think for Rust to truly replace C++, it needs a better dynamic linking story. I wish they would make their ABI stable within a given edition. That would make it much easier for people to rely on dynamic linking, similar to how C++ does it. Without it, Rust binaries are quite huge.

The stable ABI in Rust is called the C ABI. Which means you can write C compatible dylibs/.so in Rust that can be used by any language with a C FFI. This is used in the real world for seamless rewrites of existing dynamic libraries in Rust - librsvg being a well-known case. You don't need all the hacks OP is talking about.

Sure, dropping down to a C interface is easy enough, but far from ideal. So much of Rust's expressive power is lost by doing so. What would be the downside of providing a stable ABI for an edition? It seems to me it resolves both sides of the argument on stable ABIs. By the way, I'm mostly thinking about Rust -> Rust dynamic linking.

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

#233

Post by mr_00ff00 »

pjmlp wrote: post #222
mr_00ff00 wrote: post #127

Earlier quoted context omitted.

Yeah I guess I used C and C++ interchangeably, but I believe C++ is the language of HFT. Do you have evidence to the contrary?

"Why we chose Java for our High-Frequency Trading application" https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-...

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

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

#234

Post by Kukumber »

jchw wrote: post #231
Kukumber wrote: post #98

Earlier quoted context omitted.

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

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

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

#235

Post by pjmlp »

mr_00ff00 wrote: post #233
pjmlp wrote: post #222

Earlier quoted context omitted.

"Why we chose Java for our High-Frequency Trading application" https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-...

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.

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

#236

Post by jasmer »

pcwalton wrote: post #176
jasmer wrote: post #117

Earlier quoted context omitted.

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…

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

Most C++ apps are mostly memory safe and that's just fine. It's ridiculous to suggest that this secondary artifact concern is raised to primacy for all projects.

Rust V1 is a vastly complicated and verbose language, slow to make, slow to write, difficult to integrate, which offers really only one glorious feature that's not important to such a degree for most projects. To suggest wanting something better has nothing to do with vapourware.

Hypersensitivity over a compiler might be a sure sign in a cult!

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

#237

Post by jasmer »

zozbot234 wrote: post #210
lll-o-lll wrote: post #199

Earlier quoted context omitted.

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…

Ubiquitous ARC has even worse performance than tracing GC. Only Rust gives you complete memory safety with fine-grained control over memory management strategy.

"Only Rust gives you complete memory safety with fine-grained control over memory management strategy."

Yes, and it comes at a cost. Pay that cost for those advantages if necessary. Otherwise, use something else.

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

#238

Post by pkulak »

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?

Because that is _very_ latency sensitive, not throughput sensitive.

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

#239

Post by taeric »

tsimionescu wrote: post #184
pornel wrote: post #37

Earlier quoted context omitted.

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…

Note that dynamic linking is also done in Java, C#, and any dynamic language. It's not something specific to C, not by a long shot.

I was confused by that line. I think they are mainly referring to most dynamic linking in linux? Not sure.

I do think the world lost a bit by not embracing cross language linking more. Not sure when that got lost.

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

#240

Post by lamontcg »

eschaton wrote: post #161
alexvoda wrote: post #155

Earlier quoted context omitted.

What is the philosophy behind why it's not done like this Linux? Also, what about Nix?

You assume there’s a philosophy or coherent reasoning behind it, rather than “This is the way we did it with static libraries, so when we adopted shared/dynamic libraries we didn’t change anything else.” Because near as I can tell that’s exactly what happened when BSD and Linux implemented Sun-style .so support in the early 1990s, and there hasn’t been any attempt to rethink anything since then.

Probably because the purpose of the dynamic linker serves the typical O/S layout where there's only one copy of different dynamic libs and everything is linked against those, and packages installed by package managers are authoritative for the things they ship. Distro maintainers want this and lots of system admins expected packages to behave like this.

There's an alternative universe somewhere in which containerization took a different path and Unix distros supported installing blobbier things into /opt, but without (or optionally) the hard container around it. Then fat apps could ship their own deps.

The problem is that there's a lot of pushback from people who want e.g. only one openssl package on the system to manage and it legitimately opens up a security tracking issue where the fat apps have their own security vulns and updates need to get pushed through those channels. It was more important to us though to be able to push a modern ruby language out to e.g. CentOS5, so that work was more than an acceptable tradeoff.

Containerization of course has exactly the same problem, and static compilation probably just hides the problem unless security scanners these days can identify statically compiled vulnerable versions of libraries.

I need to look at NixOS and see if it supports stuff like multiple different versions of interpreted languages like ruby/python/etc linking aginst multiple different installed versions of e.g. openssl 1.x/3.x properly. That would be even better than just fat apps shoved in /opt, but requires a complete rethink of package management to properly support N different versions of packages being installed into properly versioned paths (where `alternatives` is a hugely insufficient hack).

Post reply on HN