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

221–230 of 274 posts

Re: Swift Static Linux SDK

#221

Post by mannuch »

vips7L wrote: post #81
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…

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

First of all, traditional (tracing) GCs require more expensive runtimes and consume much more memory. ARCs are also much more predictable in their behavior and pave the way for greater compile time optimizations. ARC is key in providing Swift its ability to maintain its low memory footprint compared to, say, Java.

Second, yes, ARC is a GC method. But when the language says "no garbage collector", they just mean no traditional (tracing) GC runtime because, for better or worse, tracing GC is what people think of when they hear "garbage collector".

Re: Swift Static Linux SDK

#222

Post by robertjpayne »

jimbobthrowawy wrote: post #115
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.

You can implement the same syntax for a renderer on other platforms but all of SwiftUI is closed source. So the diffing engine etc… all would need to be re-created from the ground up.

SwiftUI, like react uses some language constructs to make it look really fancy but in reality it's really simple nested data structs.

The real hard part is what the "DOM" provides for React and likewise what UIKit/iOS is doing with those data structs.

Re: Swift Static Linux SDK

#223

Post by RantyDave »

janice1999 wrote: post #93
w10-1 wrote: 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.

Wow, I had no idea people were using Swift for Embedded: https://github.com/apple/swift-embedded-examples

Swift on Zephyr! I wonder if you can attach a debugger to it? https://github.com/apple/swift-embedded-examples/tree/main/n...

Re: Swift Static Linux SDK

#224

Post by mannuch »

heavyset_go wrote: post #56
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…

Given there is native C++ interop, is exporting a C ABI still a seemingly experimental/niche feature? Same question with interop between C and Swift. Recently went with using Kotlin Native over Swift on macOS for this reason, the C ABI export and C interop were painless.

Swift has had first-class C interop for a long time.

It is only C++ interop that is more experimental/in-progress.

Re: Swift Static Linux SDK

#225

Post by OKThatWillDo »

Redoubts wrote: post #174
potatolicious wrote: post #101

Earlier quoted context omitted.

Not a super-expert but I've used Vapor on some personal projects. Do you have a link to the mention for "protocol server"? I'm not familiar with the concept but might be able to help.

I'm guessing they clicked onto the Built with SwiftNIO link and saw this at https://github.com/apple/swift-nio .

That's right. I did a search but this term does not seem to have a trendy or thorough definition.

Re: Swift Static Linux SDK

#226

Post by OKThatWillDo »

PaulDavisThe1st wrote: post #145
OKThatWillDo wrote: post #83

Earlier quoted context omitted.

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

Thanks. Not an appropriate use of the noun "vendor," so I would never have guessed that.

Re: Swift Static Linux SDK

#227

Post by kbolino »

illusionyodel wrote: post #219
kbolino wrote: post #137

Earlier quoted context omitted.

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?

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.

Re: Swift Static Linux SDK

#228

Post by icedchai »

j1elo wrote: post #176
icedchai wrote: post #151

Earlier quoted context omitted.

You are right. It's not a good experience for new developers, especially given how long Python has been around.

They are so close, though! I think one lesson Python took is that it's better, even mandatory, to use venv and install stuff in isolated containment. This is exactly what Node/NPM does: "npm instal" creates a new dir, "./node_modules" and installs stuff there, and next "npm" commands will transparently refer to that subdir. This is, in effect, the same thing as a Python's venv! to the point that in my scripts I alway…

Yeah, they should just define a new command line option (and perhaps a new command that defaults to this behavior, say vpip or vpython or something.) The virtualenvs take some getting use to. I've been using python for over 15 years so it's second nature.

Re: Swift Static Linux SDK

#229

Post by [deleted] »

hugodan wrote: post #72
w10-1 wrote: 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?

[deleted]

Re: Swift Static Linux SDK

#230

Post by helge5 »

29athrowaway wrote: post #209
singularity2001 wrote: post #73

Earlier quoted context omitted.

Swift is elegant, beautiful and concise, whereas Rust is an ugly verbose sigil mess.

Would it be fair to say that Rust is a better C++ and Swift is a better Objective-C?

No, both Rust and Swift can be seen as better C++'s. And both do not provide the Smalltalk like OO Objective-C has. Swift (only) on Apple platforms integrate w/ ObjC, but the core language is more like C++ and very little like Smalltalk.
Post reply on HN