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

141–150 of 274 posts

Re: Swift Static Linux SDK

#141

Post by dagmx »

azinman2 wrote: post #106
dzonga wrote: post #91

Swift could've easily replaced python. but the language got complex and is now a baby C++.

Those are pretty different languages. One you just run as a script with no compilation and no static typing, the other is fully compiled and linked into a binary. How could they replace each other? And what’s the complexity now that even remotely approaches c++?

Fwiw, you can use Swift in a very Python like way.

If you give a Swift file a shebang, it’ll execute as a standalone script.

I still don’t agree they’re necessarily as overlapped as the other person claims but there is a decent area where Swift is easy enough to replace Python tooling

Re: Swift Static Linux SDK

#143

Post by kibwen »

MBCook wrote: post #105
vips7L wrote: post #81

Earlier quoted context omitted.

> - No garbage collector ARC is a GC, and a slower one than most traditional tracing GC's.

Reference counting and garbage collection are different. They’re both forms automatic memory management, but they work in very different ways.

Reference counting and garbage collection are different, yes. But in terms of classifying "no garbage collection" under "things that Swift took from Rust", Swift's pervasive reference counting is much closer to classic tracing GC than it is to Rust's system of single ownership.

Re: Swift Static Linux SDK

#144

Post by PaulDavisThe1st »

e63f67dd-065b wrote: post #3
palata wrote: post #2

> Additionally, a program built for a particular distribution, or even a particular major version of a particular distribution, would not necessarily run on any other distribution or in some cases even on a different major version of the same distribution. Not sure I understand that. Is it something specific to Swift, or is it exactly what is expected from using shared libraries? Say my Linux distribution distributes…

It's just classic dependency issues. I'm not familiar with swift specifics, but probably a combination of ABI instability and just plain version incompatibility from one distro to the next with your target program. My opinion is the opposite: I think the old paradigm of distros managing a giant set of system libraries is a bad one, and is how we ended up in the land of docker. Go and Rust made the right decisions her…

> Modern languages are not like C/C++

I think there's a bit of a misconception here.

Ardour is written in C++ and depends on 80+ other libraries.

The dependency situation may be exacerbated by packaging culture that encourages the use of lots of relatively small dependencies, but it is by no means determined by language or even context.

Re: Swift Static Linux SDK

#145

Post by PaulDavisThe1st »

OKThatWillDo wrote: post #83
e63f67dd-065b wrote: post #3

Earlier quoted context omitted.

It's just classic dependency issues. I'm not familiar with swift specifics, but probably a combination of ABI instability and just plain version incompatibility from one distro to the next with your target program. My opinion is the opposite: I think the old paradigm of distros managing a giant set of system libraries is a bad one, and is how we ended up in the land of docker. Go and Rust made the right decisions her…

"vendor all the dependencies" What does that mean?

It means "add the source for your dependencies to your own codebase and build them with your build system".

Re: Swift Static Linux SDK

#146

Post by PaulDavisThe1st »

School-Cotton wrote: post #14
palata wrote: post #2

> Additionally, a program built for a particular distribution, or even a particular major version of a particular distribution, would not necessarily run on any other distribution or in some cases even on a different major version of the same distribution. Not sure I understand that. Is it something specific to Swift, or is it exactly what is expected from using shared libraries? Say my Linux distribution distributes…

Dynamic linking works fine for software that is distributed by distros, but lots of software isn't.

For decades, Unix-y software has been distributed with dynamic linking made possible by the use of a startup script that also sets LD_LIBRARY_PATH (which means the dynamic linker will find the libs that come with the software in preference to system-provided ones.

Re: Swift Static Linux SDK

#147

Post by School-Cotton »

freedomben wrote: post #134
Cyph0n wrote: post #119

Earlier quoted context omitted.

Fairly easy to build against musl thanks to rustup and cargo (except if you have native deps): https://doc.rust-lang.org/rustc/platform-support.html#tier-2...

(not directed at parent specifically) Do you have to link againt musl? I have some C applications that I link into a static binary using the glibc-static package (in Fedora). Can the same be used with Rust?

Nothing stops you from linking against glibc statically from rust. It’s recommended to link against glibc dynamically, but that’s just as true for any language.

Re: Swift Static Linux SDK

#148

Post by pcwalton »

jkelleyrtp wrote: post #10

Swift 6 is amazing - I say this as a big Rust person. It seems like Swift is now its own entity outside the Apple bubble and has a few very interesting features: - An "embedded" mode that turns off reflection for kilobyte-sized binaries - An upcoming WASM target - An LSP for VSCode - Native C++ interop - Typed "throws" - Static linking on linux and the linux sdk - Porting a number of "core foundation" / foundation pr…

Swift has a garbage collector. Reference counting is a form of garbage collection.

Re: Swift Static Linux SDK

#149

Post by pcwalton »

MBCook wrote: post #105
vips7L wrote: post #81

Earlier quoted context omitted.

> - No garbage collector ARC is a GC, and a slower one than most traditional tracing GC's.

Reference counting and garbage collection are different. They’re both forms automatic memory management, but they work in very different ways.

Automatic memory management is a synonym for garbage collection. Reference counting is a form of garbage collection.
Post reply on HN