Swift Achieved Dynamic Linking Where Rust Couldn't (2019) • Hacker News Board

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

#261

Post by galangalalgol » Mon, Jan 30, 2023, 10:56 PM UTC

pcwalton wrote: post #251

jasmer wrote: post #236

Earlier quoted context omitted.

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

I think Jasmer has a good point about c++ users wanting a safe enforced subset. I jave suggested a cpp23{} to denote code where the compiler is free to break anything older and enforce best modern practices. Its like a version of safe{} vs unsafe{}

I don't agree that rust is particularly difficult to use, and certainly not verbose. My productivity level is not as high as pytorch or matlab, but it is already on par with c++17 and I've been using that for ~5yrs (c++ for 30yrs) and I've only been using rust for work projects for a year.

Lastly I agree that memory safety isn't a small thing. 70% of security vulnerabilities MS and google find they say are memory safety related. 70% of the financial losses due to security vulnerabilities is... A really big number. And rust, unlike a GC language like java, go, swift, or c#, isn't just memory safe, the borrow checker adds thread safety and more generally safe access to any resource, like file or network io. That is a huge benefit in any domain, and the cognitive overhead just isn't that high.

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

#262

Post by pjmlp » Mon, Jan 30, 2023, 10:58 PM UTC

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?

Due to language features, ecosystem and tooling, neither Go nor Elixir are even close, in what Java has improved upon since 1996.

Swift is mostly Apple platforms.

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

#263

Post by pjmlp » Mon, Jan 30, 2023, 11:01 PM UTC

Jweb_Guru wrote: post #254

pjmlp wrote: post #220

Earlier quoted context omitted.

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.

Mind reader?

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

#264

Post by imron » Tue, Jan 31, 2023, 1:53 AM UTC

pjmlp wrote: post #209

imron wrote: post #204

Earlier quoted context omitted.

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.

Glad we agree then that it permeates the lower levels of windows programming.

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

#265

Post by Jweb_Guru » Tue, Jan 31, 2023, 2:03 AM UTC

pjmlp wrote: post #263

Jweb_Guru wrote: post #254

Earlier quoted context omitted.

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.

Mind reader?

I don't need to be a mind reader because I know which languages other than Rust support sound affine types. They broadly fall into three categories:

* Languages with comprehensive support for affine types, but that are otherwise too limited to be really useful for general purpose programming. Usually this is due to a lack of industry support.

* Languages with bolted on support for affine types where you can't get consistent performance benefits out of code written in that style and it's very difficult to write and compose code written in that style.

* Complex languages with advanced type systems that can emulate affine types, and are extremely powerful, but are borderline unusable for any purpose.

Like I said, whichever of those three language categories you're thinking of, my reasoning applies. No mind reading necessary! I understand though that you believe safe concurrency has been solved since Modula 3 because you can just lock every object while it's in use (why didn't anyone else think of that?), so maybe you don't really appreciate the vast gulf in usability between affine types in these kinds of languages and in Rust.

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

#266

Post by pjmlp » Tue, Jan 31, 2023, 7:32 AM UTC

Jweb_Guru wrote: post #265

pjmlp wrote: post #263

Earlier quoted context omitted.

Mind reader?

I don't need to be a mind reader because I know which languages other than Rust support sound affine types. They broadly fall into three categories: * Languages with comprehensive support for affine types, but that are otherwise too limited to be really useful for general purpose programming. Usually this is due to a lack of industry support. * Languages with bolted on support for affine types where you can't get con…

See you don't know which languages I mean.

I never said such thing about Modula-3, but I do believe indeed that Rust doesn't solve the concurrency problem when accessing external resources in distributed computing.

It is nice it has an answer for data concurrency for internal in-memory data structures, that is a tiny slice of solving distributed computing access patterns.

Like those languages that you "know", Rust's place is being specialized on deployments where no form of automatic memory management is allowed.

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

#267

Post by int_19h » Tue, Jan 31, 2023, 8:17 AM UTC

zdimension wrote: post #160

vrnvu wrote: post #156

Earlier quoted context omitted.

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

The result of Microsoft developers in the 90s drunkenly making up an object model on top of C with the goal of it being cross-language and cross-platform (in theory). The idea being that you can define an interface and implement it in any language and consume it in any language. A good idea in theory. In practice, DLL hell often made the experience unpleasant. A big part of Windows's APIs are COM-based. For historica…

At the most basic level (IUnknown), COM doesn't care about DLL loading at all, so DLL hell is not in the picture. Many Windows libraries are actually like that - you call a single global exported function that gives you an "entrypoint" COM object, and from there you call methods on that and/or on other things that it returns. This is the extent of COM that you would usually see in cross-platform code (e.g. Mozilla's XPCOM, or COM Interop in Mono when running on Linux or Mac).

Beyond that, if we're talking about coclasses etc, one of the things about Win32 COM was kinda sorta solving DLL hell by using UUIDs as primary identifiers for those classes - CLSIDs - and mapping them to actual files on disk via the registry. Thus, you could have things installed wherever, including DLLs with identical names in different folders. A new version of the class would get the new CLSID, so multiple versions could be installed and correctly resolved at runtime.

Of course, that just made it a registry hell instead, where messing up those (global!) entries would break apps that depended on the affected classes. So Windows XP (IIRC) added the ability to register CLSIDs and map them to DLLs directly in the app manifest, allowing for a fully self-contained solution.

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

#268

Post by int_19h » Tue, Jan 31, 2023, 9:04 AM UTC

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.

Templates are not a problem if you're defining the complete set of valid specializations in advance, as would be the case here - that's what "extern template" is for.

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

#269

Post by int_19h » Tue, Jan 31, 2023, 9:15 AM UTC

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.

In C++ land, classes are a part of the stable ABI. Pretty much everything is, except for templates (but including explicit template specializations).

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

#270

Post by int_19h » Tue, Jan 31, 2023, 9:28 AM UTC

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…

I'd say that Swift is more of a general competitor to the likes of C# and Java. The lack of JIT-compiling VM is the obvious difference, but if you set that aside and look at the language itself, I'd say that it's on a similar level of abstraction - a fair bit higher than either Rust or C++.