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

111–120 of 274 posts

Re: Swift Static Linux SDK

#111

Post by stux »

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…

> Anonymous enums/structs in parameters

Can you share an example of this? It sounds really interesting but I couldn’t find any references. Do you mean the parameter “packs” features?

Re: Swift Static Linux SDK

#113

Post by plorkyeran »

coldtea wrote: post #19
christophilus wrote: post #13

Earlier quoted context omitted.

How’s the compilation speed?If it’s going to replace Go, that’s gotta be sub second for a medium sized project on my clunky old laptop.

Why, would you care if it's a full second or even 5 seconds? Go hyped their compilation speed a lot in its early years, but unless it's C++ templates level slugginess it's not like it's that big of deal.

Swift compilation is slower than C++.

Re: Swift Static Linux SDK

#114

Post by newZWhoDis »

palata wrote: post #27
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…

As you say, a typical Rust program can easily depend on hundreds of crates that nobody really checks. That's a security issue. The whole point of a distro is that someone distributes them, so you can choose which distro you want to trust. What I don't like about Rust and Go is that they enforce their preference. I am fine if you want to link everything statically. I just don't want you to force me.

More software should “enforce” their preferences, many decisions are objectively superior and this “anything goes” attitude has done nothing but hurt OSS/Linux adoption.

Everything about the shared lib model is stupid, and has contributed to poor Linux market share to date.

Re: Swift Static Linux SDK

#115

Post by jimbobthrowawy »

Vt71fcAqt7 wrote: post #6

Genuine question: is there any reason to use Swift without iOS/SwiftUI? (Outside of devs who are primarily Swift developers that want to use something they already know for a small project or similar.)

Has nobody made a polyfill for swiftUI on other platforms yet? Or is it too tied to apple OS-level APIs? The language itself is pretty nice, last I used it. Even if some of the method (argument?) names in most SDKs are absurdly long.

Re: Swift Static Linux SDK

#116

Post by 1vuio0pswjnm7 »

This website is sending gzip _and_ ignoring the client Accept-Encoding header. Specifiying "identity" has no effect.

Ignoring the Accept-Encoding header is common but sending gzip compressed response body and _also_ ignoring the header, thereby making it impossible for the client to disable compression using Accept-Encoding: identity, is relatively rare.

Another example that comes to mind is www.amazon.com. However in that case one can disable compression by sending a Viewport-Width header.

Re: Swift Static Linux SDK

#117

Post by cqqxo4zV46cp »

1vuio0pswjnm7 wrote: post #116

This website is sending gzip _and_ ignoring the client Accept-Encoding header. Specifiying "identity" has no effect. Ignoring the Accept-Encoding header is common but sending gzip compressed response body and _also_ ignoring the header, thereby making it impossible for the client to disable compression using Accept-Encoding: identity, is relatively rare. Another example that comes to mind is www.amazon.com. However i…

There is, in reality, nothing unusual about that.

Re: Swift Static Linux SDK

#119

Post by Cyph0n »

School-Cotton wrote: post #18
e63f67dd-065b wrote: post #11

Earlier quoted context omitted.

Yeah, I'm really glad for the trend of statically linked binaries that came with Rust/Go. No more version incompatibilities, fights with downstream packagers, weird build configs, etc, just distribute the binary and that's it.

Rust binaries (at least on Linux) are not statically linked by default. They depend on libc.

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

Re: Swift Static Linux SDK

#120

Post by jclay »

dagmx wrote: post #22
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…

As another huge rust fan myself, Swift 6 has really won me over. I find myself reaching for Swift as the default for a lot of things rather than Rust, especially with the advent of C++ Interoperability and the new Swift embedded stack and ownership model. The only thing I really need is a UI story on other platforms, but it’s an area Rust is lacking great solutions too. I suspect the C++ interop might eventually make…

There’s a very minimal example using C++ interop in Qt’s test suite:

https://github.com/qt/qtdeclarative/tree/dev/tests/manual/he...

I’ve kicked around with the C++ interop a few times. Projects like Qt that use raw pointers extensively seem hard to expose. Ended up having to wrap Qt classes to model as a value type which was straight forward but it’s not nearly as seamless as the Objective-C++ experience

Post reply on HN