Live data from Hacker News

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

faultlore.com

211–220 of 279 posts

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

#211
post #156
post #21

Earlier quoted context omitted.

So, COM?

Sorry, does anyone mind to explain/reference what COM is?

COM is several things. Although COM on its own always means Microsoft's version and they invented it, there have been quite a few reinventions over time. Mozilla uses/used their own version called XPCOM inside Firefox for example. It can be thought of as a standardized way to expose objects across languages, compilers, incompatible ABIs, processes and machines. It provides:

1. A standardization of vtables and how to obtain/query them from objects.

2. A standardized memory management protocol based on reference counting.

3. A standardized type description/reflection IDL and binary data format, so dynamic languages can reflect objects to learn what methods/properties/events they support.

4. A standardized protocol for dynamically invoking methods and properties by string and using variant types, for scripting languages again.

5. A whole lot of machinery for auto-generating implementations of dynamic method dispatch for objects written in C++/Pascal/C#/etc.

6. A way to load/dynamically link against objects by UUID instead of library name. In COM the actual location and name of a shared library is (in theory) unimportant.

7. A way to "activate" objects either in-process, which is basically a wrapper around dynamic library loading, or out-of-process, in which case Windows starts an EXE that then exposes objects as a server using RPC.

8. A way to do OOP RPC on objects over the network or a process boundary (DCOM).

9. A protocol for negotiating UI embeddings (OLE) so one component could contribute menus and toolbars that would get merged with the host program's UI.

And a lot more stuff that I've probably forgotten.

It's really a very feature complete and powerful framework for solving common problems you face when writing software made up on components written in different languages and by different teams. For example, an advanced use of COM is to run some objects at one privilege level and others at lower privilege levels. Installers/updaters often do this so the GUI runs as the user, and the engine runs as an administrator.

Most platforms (except the web) have something vaguely COM-like or COM inspired. Apple's stack uses MIG, Mach ports and Objective-C for similar purposes. Linux never really did but the closest equivalent is DBUS. Android has the Binder.

COM doesn't get much use these days outside a few stock use cases because other platforms never implemented it, so modern devs (web+mobile) aren't familiar with it and so we are now seeing a new generation 'rediscover' parts of it in the context of WASM, thinking it's new. However in its heydey COM was ubiquitous. There were large markets of components for sale, distributed in binary form and written in/for many different languages. COM stood in the middle making it all work. It was one reason that Windows was relatively language neutral and friendly to language innovation. In comparison other platforms are quite language and binding unfriendly.

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

#212
post #99

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.

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.

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

#213
post #151

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.

Better not do plugins with static linking, given the waste in hardware resources for communication and process managment.

Both approaches have plus and minus regarding efficiency.

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

#214
post #130

Earlier quoted context omitted.

Dynamic linking doesn't even really save disk space https://drewdevault.com/dynlib The vast majority of libraries on your system are used by only one program. I'd imagine dynamic linking also freezes progress and improvements on libraries because it's extremely difficult to roll out changes without breaking packages that haven't been tested and updated for them.

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…

A better test would check at any point in time how many running programs are sharing object files and how much memory is saved.

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

#215
post #26
post #21

Earlier quoted context omitted.

So, COM?

The greatest trick Swift's developers ever performed was convincing the world that it wasn't just a better UX layer on top of COM

IBM did it first with SOM, but unfortunely it went the way it did.

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

#216
post #156

Earlier quoted context omitted.

Sorry, does anyone mind to explain/reference what COM is?

COM is several things. Although COM on its own always means Microsoft's version and they invented it, there have been quite a few reinventions over time. Mozilla uses/used their own version called XPCOM inside Firefox for example. It can be thought of as a standardized way to expose objects across languages, compilers, incompatible ABIs, processes and machines. It provides: 1. A standardization of vtables and how to…

They make a point of having most of their software built with COM as ABI for native APIs, however COM roots are in DCE/RPC and IBM's OS/2 SOM.

COM has plenty of use nowadays for Windows developers, as it is the main way to expose Windows APIs since Vista.

WinDev has picked the .NET ideas for Longhorn and redone them as COM/WinRT.

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

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

Indeed, on Windows C++ dynamic linking has always been available, sure there is the ABI issue, but that doesn't mean there aren't C++ frameworks being shipped as dynamic libraries, e.g. MFC, VCL, Qt,...

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

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

Did you bother to look into the Apple developer forums?

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

#219

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.

Swift has some tricks to make things faster than naive ARC, but the point is that you trade a little speed for deterministic behavior. The post I was replying to was making the argument I see frequently. That if not Rust, you should go GC. This is simply wrong. The degenerate GC cases can be avoided with Swift. It’s better for a phone application in nearly every case. If it wasn’t bound to Apple, I’d say it’d be a better choice than Rust in 90% of the places Rust is used.

Rust has its place, but the idea that it’s the obvious and only replacement for C++ is overblown. A language like Swift seems like a better path forward.

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

#220

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.

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