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

271–279 of 279 posts

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

#271

Post by lll-o-lll »

jchw wrote: post #224
pjmlp wrote: post #169

Earlier quoted context omitted.

I would say it is the reverse on what concerns Apple platforms, Rust isn't a competitor to Swift. It will never have tooling parity with Swift. Trying to use Rust instead of Swift on Apple platforms is only for those that enjoy the pain of creating ecosystems from scratch.

Definitely! There's only one enormous issue with this outlook: the rest of the world is bigger. Much bigger. Exactly how much bigger depends on who you ask, but it's a lot bigger. Just on the consumer side... https://gs.statcounter.com/os-market-share Maybe it doesn't matter because developers prefer macOS, so the rest can be treated as a secondary case? Not even close. https://survey.stackoverflow.co/2022/#section-m…

Your argument seems to contradict itself. On the one hand you say “objective c failed because it was available on multiple platforms, but no one cared” but you also infer “Apple is failing because it hasn’t made Swift available on multiple platforms”.

Is it possible that it just doesn’t matter (for Apple) whether Swift is Apple ecosystem only?

It makes me sad, because I really like Swift. Not enough to become an Apple dev though.

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

#272

Post by Shorel »

malkia wrote: post #256
Shorel wrote: post #148

Earlier quoted context omitted.

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?

I use a Python script to read the shared memory and generate JSON with this information, then a web page using this JSON is overlaid using OBS, and this way we transmit races on YouTube.

Here is how it looks like: https://youtu.be/ijSL8uN8cIw?t=5582

If you want to read about a public project that uses this strategy, here is the repository link:

https://gitlab.com/winzarten/SecondMonitor

I don't know C#, but it should work similarly. This also means you definitely don't need to use the same language to create and to consume the information.

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

#273

Post by Jweb_Guru »

pjmlp wrote: post #266
Jweb_Guru wrote: post #265

Earlier quoted context omitted.

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…

Nice goal post moving. So which imaginary language with affine types are you referring to? Being specialized doesn't automatically mean being industrial strength or usable.

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

#274

Post by jchw »

lll-o-lll wrote: post #271
jchw wrote: post #224

Earlier quoted context omitted.

Definitely! There's only one enormous issue with this outlook: the rest of the world is bigger. Much bigger. Exactly how much bigger depends on who you ask, but it's a lot bigger. Just on the consumer side... https://gs.statcounter.com/os-market-share Maybe it doesn't matter because developers prefer macOS, so the rest can be treated as a secondary case? Not even close. https://survey.stackoverflow.co/2022/#section-m…

Your argument seems to contradict itself. On the one hand you say “objective c failed because it was available on multiple platforms, but no one cared” but you also infer “Apple is failing because it hasn’t made Swift available on multiple platforms”. Is it possible that it just doesn’t matter (for Apple) whether Swift is Apple ecosystem only? It makes me sad, because I really like Swift. Not enough to become an Appl…

I'm saying Objective C was further along in some regards and it still wasn't enough; the investment that Apple would need to make to make Swift popular across platforms is very non-trivial, and just simply nowhere near where they're at today. That's basically it. They're doing some things with Swift that they never did for Objective C, like making a cross-platform version of Foundation. That helps... but it's not good to start out behind on other aspects.

I'm sure they invested tons into devrel on macOS and that family of operating systems. It's weird to think that they could get away with doing less on other platforms where they're already on a much more competitive and less favorable landscape and still have it work out.

Maybe accounting-wise, it's difficult to justify putting all of this effort into something that will ultimately make it easier to leave your ecosystem. That's fair enough but that makes Swift's cross-platform strategy broken.

Ultimately, they're competing with programming languages that have the level of support they do not, but as far as I can tell they're treating it as more of a tool for developers who are primarily Apple-oriented but wish to deploy software across platforms.

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

#275

Post by alexvoda »

wongarsu wrote: post #252
lamontcg wrote: post #240

Earlier quoted context omitted.

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…

Indeed, containers and static linking are just hiding the problem.

> each software is installed in it's own folder, and the search path for dynamic linking starts in the binary's folder.

I think the benefit of this is that an app can be fat but doesn't have to. And an app can be made fat afterwards if need be. The app folder is just the starting point for searching. If the library is not there it is probably shared.

Wrappers and a build system that tweaks everything feel like a hack, not a system wide solution.

There is also Gobo Linux. I wonder if they solved this.

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

#276

Post by saagarjha »

BulgarianIdiot wrote: post #133
saagarjha wrote: post #120

Earlier quoted context omitted.

Value types are stored wherever appropriate. If they escape they’re going on the heap like everything else.

If they are very large and implement copy-on-write, sure, parts of them may be on the heap. But they don't need to be on the heap if they escape if they're just returned by copy.

s/very large/a couple of words/

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

#277

Post by lll-o-lll »

jchw wrote: post #274
lll-o-lll wrote: post #271

Earlier quoted context omitted.

Your argument seems to contradict itself. On the one hand you say “objective c failed because it was available on multiple platforms, but no one cared” but you also infer “Apple is failing because it hasn’t made Swift available on multiple platforms”. Is it possible that it just doesn’t matter (for Apple) whether Swift is Apple ecosystem only? It makes me sad, because I really like Swift. Not enough to become an Appl…

I'm saying Objective C was further along in some regards and it still wasn't enough; the investment that Apple would need to make to make Swift popular across platforms is very non-trivial, and just simply nowhere near where they're at today. That's basically it. They're doing some things with Swift that they never did for Objective C, like making a cross-platform version of Foundation. That helps... but it's not goo…

What you are saying makes a good deal of sense. It’s a shame though, as Swift seems a really great language with an interesting value proposition. If it were properly cross platform, you could see it being a real competitor to Rust in luring away C++ devs as opposed to traditional GC (deterministic destruction! Can do RAII! Better handling of real-time constraints! Easy learning curve!). Ahh well.

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

#278

Post by jessermeyer »

palata wrote: post #180
jessermeyer wrote: post #34

Earlier quoted context omitted.

There is obviously a trade off here, but categorically speaking, new releases introduce new bugs and security exploits too.

But they do patch the known security exploits that are likely to be actively used. I'm happier with a security exploit (almost) nobody knows than with a published one that appears in hacking tutorials from 10 years ago.

There are two degrees of separation here though: The software vendors and then the linux distros.

If you sell software that requires your clients to upgrade their system-wide security stack, so they might not. If it is statically linked, no need for them to.

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

#279

Post by wilg »

verdagon wrote: post #137
wilg wrote: post #89

Earlier quoted context omitted.

This is all very hand-wavey. Are you just describing a chicken-and-egg scenario? Also, Swift probably can compete with Rust, especially when they finish adding Rust-style lifetimes. But the real advantage of Swift is it has a much more "high-level" feel than Rust – it's much more familiar to use than Rust by virtue of having classes and things. Swift also doesn't instantly force you into weeds of dealing with memory…

I'm particularly interested in this line of thinking, and I'd probably lean the same way. Would love to hear more, why do you think it's a better approach to default to more high-level, with the ability to drop down into manual memory management for hot paths?

Simply because hot paths are less common for a "typical" workload. So you'd want it to be more ergonomic by default. Where possible, jam all optimizations into the compiler so nobody has to think about it. If you can't do that, then allow developers to give the compiler more information even if it's more complex.

Relatedly, it allows the language to help you "first make it work, then make it good".

Post reply on HN