Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift Static Linux SDK

swift.org

Post reply on HN
Print view View original

241–250 of 274 posts

Re: Swift Static Linux SDK

#241

Post by kibwen »

glandium wrote: post #236
kibwen wrote: post #125

Earlier quoted context omitted.

> I just don't want you to force me. Rust supports dynamic linking, and has since well before 1.0.

That's kind of a disingenuous take. Rust supports producing dynamically loadable libraries. It doesn't support dynamically linking arbitrary dependencies, which is what most people would understand from "Rust supports dynamic linking" in a discussion about static linking.

> It doesn't support dynamically linking arbitrary dependencies

I don't understand why one would think this. You make it sound as though Rust only supports dynamic linking for glibc, but that's certainly not true.

Re: Swift Static Linux SDK

#242

Post by kibwen »

palata wrote: post #195
kibwen wrote: post #187

Earlier quoted context omitted.

I'm against dlopen as well. If something makes use of LD_LIBRARY_PATH, rest assured that I want it excised from my system. Reproducibly-built, fully-static binaries are what I want, ideally with an accessible SBOM embedded.

So all your binaries are statically linked on your system? 100%?

That's the dream. I want a system that's 100% source-available, 100% reproducible, and 100% statically-defined. Nix looks like the closest thing to that right now.

Re: Swift Static Linux SDK

#243

Post by developerDan »

kbolino wrote: post #227
illusionyodel wrote: post #219

Earlier quoted context omitted.

The async question is actually really interesting - and gets at a few things Swift does very differently from some other languages. Normal languages just sort of call functions on threads - and use locks when there is contention. You certainly can write the same sort of code in Swift - but that is not how async functions work. The issue with locks is that waiting on a lock could be expensive - depending on the type o…

But that's the thing, we're comparing with Go, where all functions behave that way, and no async/await ceremony is required. Go has many weaknesses, but I don't think a language that treats async as unusual/special beats Go in that respect .

This is just a hunch but likely because of the application the two languages were originally designed for. Go is/was a purely backend lang (as I understand it) whereas Swift was built with the UI in mind which must be run on the main thread. So Swift has async/await for making clear boundaries between synchronous (aka UI) operations and asynchronous operations.

I’m am not well educated on the subject though so take that with a grain of salt.

Re: Swift Static Linux SDK

#244

Post by kibwen »

burntsushi wrote: post #181
kibwen wrote: post #123

Earlier quoted context omitted.

What problems did you have? As someone who's never in his life used musl before, I just now ran `rustup target add x86_64-unknown-linux-musl` and then built ripgrep with `cargo build --release --target=x86_64-unknown-linux-musl` and it worked without a problem. ldd confirms that it's statically linked. I'm surprised it was as painless as it was, I thought I'd have to install musl separately.

I just tried this myself and I did not have a painless experience. Hah. Without the `musl` Archlinux package installed, I get this: --- stderr configure: error: in `/home/andrew/rust/ripgrep/target/x86_64-unknown-linux-musl/release/build/jemalloc-sys-b7d053053989ba56/out/build': configure: error: C compiler cannot create executables See `config.log' for more details thread 'main' panicked at /home/andrew/.cargo/regis…

Interesting, I must have had musl preinstalled from some other package. And I did notice that jemallocator started showing up when I compiled for musl, I figured you must have had a good reason. :P

Re: Swift Static Linux SDK

#245

Post by glandium »

kibwen wrote: post #241
glandium wrote: post #236

Earlier quoted context omitted.

That's kind of a disingenuous take. Rust supports producing dynamically loadable libraries. It doesn't support dynamically linking arbitrary dependencies, which is what most people would understand from "Rust supports dynamic linking" in a discussion about static linking.

> It doesn't support dynamically linking arbitrary dependencies I don't understand why one would think this. You make it sound as though Rust only supports dynamic linking for glibc, but that's certainly not true.

The keyword is "arbitrary". Say you have dependencies on reqwest and clap, want to dynamically link against them? Not gonna happen. That's what people talk about most of the time for static vs. dynamic linking, at least in my circles.

Re: Swift Static Linux SDK

#247

Post by amszmidt »

kibwen wrote: post #242
palata wrote: post #195

Earlier quoted context omitted.

So all your binaries are statically linked on your system? 100%?

That's the dream. I want a system that's 100% source-available, 100% reproducible, and 100% statically-defined. Nix looks like the closest thing to that right now.

I don’t see how Nix is close to your dream, Nix is just like any other system and links things like any other system.. I.e. mostly avoids static linking.

Debian did the strongest push for reproducible builds, and is 100% source available.

Re: Swift Static Linux SDK

#249

Post by jkrejcha »

kbolino wrote: post #227
illusionyodel wrote: post #219

Earlier quoted context omitted.

The async question is actually really interesting - and gets at a few things Swift does very differently from some other languages. Normal languages just sort of call functions on threads - and use locks when there is contention. You certainly can write the same sort of code in Swift - but that is not how async functions work. The issue with locks is that waiting on a lock could be expensive - depending on the type o…

But that's the thing, we're comparing with Go, where all functions behave that way, and no async/await ceremony is required. Go has many weaknesses, but I don't think a language that treats async as unusual/special beats Go in that respect .

This melding of the sync and the async is actually kinda interesting to me. I know that at least in lots of environments, the sync and async paths are effectively separate for things like I/O[1]. I wondered (and still do for some cases) how Go handles this.

For those curious I looked at Windows and Linux, but not much else.

Linux: no io_uring support. There's debate on even whether to use it as people are discussing security implications[2]. It looks like (from perusing this issue, but could be wrong) AIO wasn't used.

Windows: it looks like they're using IOCP everywhere. Seems sensible enough.

General case: there seems to be an open issue regarding this[3].

[1]: For example, Windows has IOCPs, Linux has io_uring, FreeBSD has kqueue, POSIX has... POSIX AIO, etc.

[2]: https://github.com/golang/go/issues/31908

[3]: https://github.com/golang/go/issues/6817

Re: Swift Static Linux SDK

#250

Post by boffinAudio »

josephg wrote: post #189
boffinAudio wrote: post #179

Earlier quoted context omitted.

Lua, I would say. Far easier to get it everywhere, and a very nice language, also.

Lua is nice, but it’s a bit of a weird comparison for Swift. Swift is compiled and lua is interpreted. Swift is statically typed. Swift uses ref counting to Lua’s runtime GC. And Swift has non nullable types by default, classes, enums, ADTs, match expressions and so on. Lua is nice. But it’s chalk and cheese comparing the languages. I can’t think of many cases where you’re trying to decide between lua and Swift.

In this case, the question is whether to use Swift for a backend server on a Linux machine, or something else. That's the environment. I'd prefer Lua, simply because its a very proven language for that application.

Sure, Swift has sexy features that make it appealing to developers. But the ecosystem for server infrastructure on Lua is formidable.

Post reply on HN