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

251–260 of 279 posts

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

#251

Post by pcwalton »

jasmer wrote: post #236
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…

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…

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

It's demonstrably not "just fine", as the steady stream of security issues that hurt real people will attest to. It's also important to remember that C++ is an extreme outlier here: the majority of programs written in 2023 are in memory-safe languages. Memory safety is not some weird new thing; it's the norm everywhere but in C and C++, usage of which declines every year.

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

#252

Post by wongarsu »

lamontcg wrote: post #240
eschaton wrote: post #161

Earlier quoted context omitted.

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

> and static compilation probably just hides the problem unless security scanners these days can identify statically compiled vulnerable versions of libraries

Some scanners like trivy [1] can scan statically compiled binaries, provided they include dependency version information (I think go does this on its own, for rust there's [2], not sure about other languages).

It also looks into your containers.

The problem is what to do when it finds a vulnerability. In a fat app with dynamic linking you could exchange the offending library, check that this doesn't break anything for your use case, and be on your way. But with static linking you need to compile a new version, or get whoever can build it to compile a new version. Which seems to be a major drawback of discouraging fat apps.

1: https://github.com/aquasecurity/trivy

2: https://github.com/rust-secure-code/cargo-auditable

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

#253

Post by zaphar »

mr_00ff00 wrote: post #250
pjmlp wrote: post #235

Earlier quoted context omitted.

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?

There is a long tail of other languages. JaneStreet uses Ocaml. I wouldn't be surprised if there was some usage of Go out there. I'm familiar with at least one trading house that uses Elixir. The bulk of it is Java or C++ though.

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

#254

Post by Jweb_Guru »

pjmlp wrote: post #220
zozbot234 wrote: post #210

Earlier quoted context omitted.

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

Rust isn't the only one with affine types, only the one that has managed more mindshare.

None of the other languages you're thinking of are particularly usable as industrial strength languages for general purpose programming, for reasons that go way beyond mindshare.

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

#255

Post by malkia »

justincormack wrote: post #226
malkia wrote: post #39

Earlier quoted context omitted.

You can't ship reasonable plugin for most of the popular content creation tools - be it audio, video effects, 3d modelling, etc. without support for dynamic/shared libs. Okay, maybe you can - at the risk of performance cost - e.g. your out-of process plugin that need to move data in/out with a cost, and then it over complicates - because the plugin process might've died - how do you restart it, how do you get it back…

Cross process shared memory is a thing on Unix so there is no need for the performance cost of copying across a pipe. Sure you have to manage if it dies, but you have to manage it crashing you in the dl case.

But you don't have only Linux, you have (and probably first) OSX and/or Windows and then Linux, and you need an API that works well in that case. Being an in-process dll/so plugin, while fraught with perils gets you to avoid other issues (state, health, restart, identity, etc.)

Also sometimes you don't have a choice, but have to make a dll, for example:

https://github.com/steinbergmedia/vst3sdk or https://ae-plugins.docsforadobe.dev/ and many others. Sometimes it's the only viable choice.

(I wish most have used grpc/flatbuffers/whatever to communicate, but then every RPC call have to be checked/retried/handled, and or shared memory well handled, with (?) locks, etc. - not a trivial thing for someone who is deeply specialized in making a very good effect/renderer/etc instead of dealing with this extra complexity on top).

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

#256

Post by malkia »

Shorel wrote: post #148
malkia wrote: post #39

Earlier quoted context omitted.

You can't ship reasonable plugin for most of the popular content creation tools - be it audio, video effects, 3d modelling, etc. without support for dynamic/shared libs. Okay, maybe you can - at the risk of performance cost - e.g. your out-of process plugin that need to move data in/out with a cost, and then it over complicates - because the plugin process might've died - how do you restart it, how do you get it back…

You can, just change the strategy. Shared memory exists. That's how we read timing information from AMS, Project Cars 2, AMS2, rFactor2, etc.

I would like to learn more! (gamedev here too) - Is there any GDC presentation about it?

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

#257

Post by malkia »

pjmlp wrote: post #195
Ygg2 wrote: post #191

Earlier quoted context omitted.

Doesn't it work on all platforms? In theory, at least?

Like plenty of other bytecode formats that predated it.

And good luck debugging / make it performant and still not clear how well the memory allocation is handled (in the dll-host situation, often the plugin may use the alloc/free functionality from the host, and give hints, in wasm case - this would be a bit of sandbox)

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

#258

Post by pornel »

pjmlp wrote: post #164
pornel wrote: post #50

Earlier quoted context omitted.

Apart from most perf critical cases, it's a good idea to run plugins in a separate process anyway. This way a bad plugin won't crash or corrupt your own process. You will be able to stop and unload it without risk of leaving locks locked or thread-locals leaking. And also there's WASM now which has even better sandboxing and OS/architecture independence.

WASM is nothing new, just a recyling of old ideas with refueled marketing.

Something existing and succeeding is not automatically a claim that it's the only one possible thing, or even a novel idea, so dismissal "it's just recycling old ideas" is non-sequitur.

I'm not even sure what you're trying to say with this comment. Is only 1958 LISP or maybe SmallTalk worthy and truly novel, and every other technology must come with a disclaimer that it's just a pale imitation and everything has been done before?

Maybe there was some underappreciated pioneer PL/BYTECODE-1968, but in 2023 there's WASM, CIL, Java bytecode (with marketing as large as the dotcom bubble), maybe Lua or eBPF. For practical application it absolutely doesn't matter which one was first or the most humble. What matters is that WASM is common popular standard now. It has easy to embed runtimes and decent language support. The marketing around it is a huge plus too, because I can tell people "use WASM" and it'll be cool and they'll use it, instead of e.g. instinctively reacting "ewwww, Java".

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

#259

Post by galangalalgol »

xedrac wrote: post #99
galangalalgol wrote: post #88

Earlier quoted context omitted.

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.

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.

I think that is a good idea, but dynamic linking seems to be reserved for system level stuff like glibc. When even embedded arm7 targets are shipping as comtainers, what difference does it make if we use dynamic or static linking within that container? The dynamic libraries aren't getting used by multiple executables anyway. The main case I see is to protect yourself from a copy-left license impacting all the bsd and mit stuff from crates.

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

#260

Post by m4rtink »

darknavi wrote: post #128
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…

Steam encourages devs to dynamically link SDL2 so that they can patch it for them [0]. Pretty neat IMO. Sorry for the terrible link, Google+ is deleted now but luckily a bot mirror the post to reddit. [0]: https://www.reddit.com/r/linux_gaming/comments/1upn39/commen...

This is also how Linux distro wide CVE fixes in crypto libs are done - done tmit once in the shared lib and reboot, done.

Otherwise you would have to find all the bundled copies and fix them separately & hope you didn't miss any.

Post reply on HN