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

201–210 of 279 posts

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

#201

Post by pjmlp »

imron wrote: post #200
pjmlp wrote: post #177

Earlier quoted context omitted.

The way you phrased it kind of implies it being legacy and we still need to deal with it.

It kind of is legacy. Yes, lower-level modern APIs are written in it, but you can write a modern windows GUI app without really needing to touch COM directly because there are other abstractions built on those APIs. This was not as true of Windows programming 20 years ago.

As someone that does Windows since version 3.0 I am quite curious what those would be.

Forms and WPF?

Forms is in maintainance mode, and WPF builds on top of COM via DirectX 9.

MFC?

Likewise maintainance mode.

WinRT and UWP/WinUI 2.0?

COM + IInspectable + .NET metadata + AppSandboxing

WinUI 3.0?

COM + IInspectable + .NET metadata

MAUI?

Built on top of WinUI 3.0

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

#203

Post by lll-o-lll »

rat9988 wrote: post #47
mr_00ff00 wrote: post #44

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.

reference counting is not necessarily faster.

It’s not faster in the normal case, it’s generally quite a bit slower. It is more predictable however (you can actually use it with real-time constraints!), and performs better under memory pressure. Whether this is a net benefit depends on what hardware you’re running on and what the app is supposed to be doing.

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

#204

Post by imron »

pjmlp wrote: post #201
imron wrote: post #200

Earlier quoted context omitted.

It kind of is legacy. Yes, lower-level modern APIs are written in it, but you can write a modern windows GUI app without really needing to touch COM directly because there are other abstractions built on those APIs. This was not as true of Windows programming 20 years ago.

As someone that does Windows since version 3.0 I am quite curious what those would be. Forms and WPF? Forms is in maintainance mode, and WPF builds on top of COM via DirectX 9. MFC? Likewise maintainance mode. WinRT and UWP/WinUI 2.0? COM + IInspectable + .NET metadata + AppSandboxing WinUI 3.0? COM + IInspectable + .NET metadata MAUI? Built on top of WinUI 3.0

Not sure how this disagrees with my statement that "you can write a modern windows GUI app without really needing to touch COM directly because there are other abstractions built on those APIs"

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

#205

Post by mike_hearn »

Kranar wrote: post #151
andyonthewings wrote: post #60

Earlier quoted context omitted.

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…

If what you care about is efficiency, then stick to static linking. Dynamic linking inhibits so many optimizations.

You can have both. JIT compiled languages are dynamically linked yet optimization is done across module boundaries.

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

#206

Post by e28eta »

josephg wrote: post #140
giantrobot wrote: post #105

Earlier quoted context omitted.

> The vast majority of libraries on your system are used by only one program. I find this is a Linux-ism rather than the common case on Windows or macOS. With Windows and macOS a given version of the OS is a fixed set of libraries and services available for third party software. Even third party libraries tend to call into the system libraries for some things. On Linux the only fixed facility of the OS is going to be…

I think dynamic libraries which are only used by a single program are even more common on windows and macos. Look at how many DLLs ship with applications, and get installed inside the Program Files/MyApp directories! (Seriously - do a search for .dll files there. They're everywhere). Practically all of those DLLs are only be used by a single program. In each case, the price is being paid for dynamic linking (in start…

iOS developers have the choice of bundling shared code into a static library, or a dynamic framework, and the tradeoffs between them has historically been a little hard to determine, and have also been a moving target.

Some reasons to choose a dynamic library, even though it’s only ever consumed by a single app bundle:

* Shared code between apps embedded in the same bundle (see sibling comment)

* Some apps may want to load portions of code on-demand with dlopen()

* Dependencies / duplicate symbols. Common example is an analytics static library that contains sqlite, and either the main app or another library also linking sqlite, and getting link warnings about “duplicate symbols, which one is used is undefined”. I think this isn’t necessarily a static / dynamic library issue, but 3rd party static libs were often a “single file with all dependencies” and didn’t always understand why that was a problem.

* for a long time, it was the cleanest way to provide & consume headers & object file when distributing closed-source 3rd party libraries.

There may be more, I’m fuzzy on some of the details. If I remember correctly, some of the reasons could be considered tooling issues: creating a Framework was easier for some cases, even if you didn’t want/need the dynamic linking inherent in that choice.

Found this interesting post: https://developer.apple.com/forums/thread/715385/

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

#207

Post by mike_hearn »

pornel wrote: post #50
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…

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.

Note that this is how things were done before dynamic linking was invented, and dynamic linking was seen as a big step forward. Processes+shared memory is a really painful and slow paradigm compared to just invoking function calls on the same stack and in the same process.

"a bad plugin won't crash or corrupt your own process."

It still can. The plugin just has to return bad data you're not prepared to handle, or crash in a way you didn't anticipate and code around.

And note that with higher level languages the whole thing is moot. A plugin crashing just means it throws an exception which can be caught, reported and quite likely the host process will survive just fine even though it's all in-process and dynamically loaded.

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

#208

Post by heinrich5991 »

imron wrote: post #158
Shorel wrote: post #146

Couldn't or wouldn't? In some part, dynamic linking is one of the reasons for the travesty of dunces that's Docker and Kubernetes. With static linking, most of that redundancy is not needed.

Docker and kubernetes excel in a world of static binaries. Gotta love those 5mb bare images.

Why use docker in that case?

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

#209

Post by pjmlp »

imron wrote: post #204
pjmlp wrote: post #201

Earlier quoted context omitted.

As someone that does Windows since version 3.0 I am quite curious what those would be. Forms and WPF? Forms is in maintainance mode, and WPF builds on top of COM via DirectX 9. MFC? Likewise maintainance mode. WinRT and UWP/WinUI 2.0? COM + IInspectable + .NET metadata + AppSandboxing WinUI 3.0? COM + IInspectable + .NET metadata MAUI? Built on top of WinUI 3.0

Not sure how this disagrees with my statement that "you can write a modern windows GUI app without really needing to touch COM directly because there are other abstractions built on those APIs "

It is like turtles but COM.

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

#210

Post by zozbot234 »

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…

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