Live data from Hacker News

Swift Static Linux SDK

swift.org

131–140 of 274 posts

Re: Swift Static Linux SDK

#131

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

Haven't written Swift ever but it seems very elegant language. In that spot, only go stands but go although simple but has very ugly corners such as error handling and a weird type system.

So yes for me, I might switch to Swift which seems very elegant and readable compared to some other options.

Re: Swift Static Linux SDK

#132
post #72
post #68

This static SDK is just one example of Swift's new support for user-definable platforms, timed to amplify support for embedded and WASM. Along with the move to a non-Apple GitHub organisation, it represents real progress in extending swift to other platforms. It would be interesting to see if this is used for the AI OS that they are inviting researchers to validate for security purposes.

Wasm? Care to provide source for that?

https://swiftwasm.org

https://github.com/swiftwasm/swift

https://github.com/swiftwasm/WasmKit

Re: Swift Static Linux SDK

#133

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…

> IMO Swift 6 is a better Go and than Go, and a better Rust for app-dev type stuff, which seems to be what people want to use Rust for.

This is a great assessment. There are some shortcomings in go that I wish weren't and I'm kind surprised that people having decades of language design experience under their belt ended up designing go.

I'm looking for a way to generate server stubs from OpenAPI specs. If that, I'm all set with Vapor+OpenAPI and would retire go for my container adventures.

Re: Swift Static Linux SDK

#134
post #119

Earlier quoted context omitted.

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

(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?

Re: Swift Static Linux SDK

#135
post #120
post #22

Earlier quoted context omitted.

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

Ah, very cool. Thanks for the link and write up

Re: Swift Static Linux SDK

#136

I guess this means it can compete with golang on ease of distribution. Pushes all the complexity away from the end user

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.

>the trend of statically linked binaries that came with Rust/Go

"Trend"? Maybe "recent reverse trend" is more appropriate.

Static linking preceded dynamic linking by several years, for compiled languages, AFAIK.

https://en.m.wikipedia.org/wiki/Static_library

https://en.m.wikipedia.org/wiki/Dynamic_linker

Re: Swift Static Linux SDK

#137

Earlier quoted context omitted.

Swift and Go are on polar ends of the language complexity spectrum. Someone who enjoys Go for what it is, i.e. a dead simple, straightforward language, would not see Swift as being "better".

Some people want generics and ADTs in Go. If you're using go because it's 1) fast 2) expressive 3) concurrent 4) compiles natively then I think Swift is the better of the two. If you just want a very simple language, then sure, Go is there. But I don't think that's necessarily what makes Go, Go.

Swift has its strengths against Go but it does not really beat Go at Go's own game.

Where are channels and select? Why is async code special? Why do protocols have to be explicitly adopted? Why are errors "thrown" instead of returned?

Re: Swift Static Linux SDK

#138
post #105
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.

No they're not. Reference counting is a garbage collection algorithm. Its even described as such in most literature on garbage collection.

Re: Swift Static Linux SDK

#140

Earlier quoted context omitted.

I'm primarily a C++ developer these days, and if the C++ interop is actually good then I'm very excited for the future. For app-dev type stuff it really does seem like it's better than Rust, and I can definitely see a world where we start migrating some code into Swift. Edit: back from watching the video, and a few observations: - Swift does not suffer from Rust's refusal to add things into the standard library. gasp…

The default testing framework made my jaw drop a bit - I have a very hard time seeing Rust have the enthusiasm or momentum to implement something like that right now.

But Rust has had a default testing framework since 1.0?
Post reply on HN