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

191–200 of 274 posts

Re: Swift Static Linux SDK

#191

Post by palata »

lmz wrote: post #188
newZWhoDis wrote: post #114

Earlier quoted context omitted.

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.

Dynamic linking seems to work fine for Windows or OSX. Maybe it's open source + dynamic linking that's the problem.

Honestly a problem is that most developers just don't understand how it works. Docker / static linking solves a lack of understanding, mostly. That's why they are popular.

Re: Swift Static Linux SDK

#192

Post by palata »

PaulDavisThe1st wrote: post #186
palata wrote: post #185

Earlier quoted context omitted.

I started a small project both in C++ and Rust. When in C++ I had 2 direct dependencies it resulted in 6 total dependencies (direct + transitive). In Rust I had 5 direct dependencies (because some standard stuff is not in the standard lib) and it resulted in... 300 total dependencies. > but it is by no means determined by language or even context. Not sure what you mean there. My feeling is that making it super easy…

> My feeling is that making it super easy to pull 50 transitive dependencies without realizing it does not help What is it that makes you think that C/C++ does not do this also? [ EDIT: this also has something to do with the typical size and scope of C/C++ libraries ]

> What is it that makes you think that C/C++ does not do this also?

My experience. I haven't worked in a single C++ project that had hundreds of dependencies, but I encounter those regularly in Rust/npm.

Re: Swift Static Linux SDK

#193

Post by veidr »

glhaynes wrote: post #159
dzonga wrote: post #91

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

"Swift is too complex now" has seemed to have achieved meme status of late but I don't see it. For the average developer, writing modern Swift is generally not any more difficult than it was several years ago (much more often it's easier), it's just that the language can do a lot more now. But you only need to learn those new parts if you're using them. If you're not writing low-level or special-purpose code, you don…

I'm rooting for Swift, but OMFS (S=Science btw, join my acronym club, it's free) the complexity has doubled? tripled? since I wrote the Swift SDK for my emlpoyer's API, in the Swift 3-4 era.

I think it is a lot more difficult now, because the scenario wrt the, uh FUCK, WHAT THE— CEASE ALL MOTOR FUNCT—

Re: Swift Static Linux SDK

#194

Post by PaulDavisThe1st »

palata wrote: post #192
PaulDavisThe1st wrote: post #186

Earlier quoted context omitted.

> My feeling is that making it super easy to pull 50 transitive dependencies without realizing it does not help What is it that makes you think that C/C++ does not do this also? [ EDIT: this also has something to do with the typical size and scope of C/C++ libraries ]

> What is it that makes you think that C/C++ does not do this also? My experience. I haven't worked in a single C++ project that had hundreds of dependencies, but I encounter those regularly in Rust/npm.

I would suggest that this caused more by ideas about the appropriate scope and scale of libraries in the 2020s than anything specifically connected to the language in use.

Re: Swift Static Linux SDK

#195

Post by palata »

kibwen wrote: post #187
amszmidt wrote: post #168

Earlier quoted context omitted.

They aren’t being rebuilt with that kind of frequency as you might think. They get rebuilt when a change in the package is made, not when a change in a dependency is made — which is a huge difference. There are plenty of packages that might not get an update for a long time (month, half year, … whatever their release cadence might be). Dynamic linking makes it _easier_ to handle security, including checking if your p…

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

Re: Swift Static Linux SDK

#196

Post by palata »

PaulDavisThe1st wrote: post #194
palata wrote: post #192

Earlier quoted context omitted.

> What is it that makes you think that C/C++ does not do this also? My experience. I haven't worked in a single C++ project that had hundreds of dependencies, but I encounter those regularly in Rust/npm.

I would suggest that this caused more by ideas about the appropriate scope and scale of libraries in the 2020s than anything specifically connected to the language in use.

I don't see that in Kotlin for instance.

Re: Swift Static Linux SDK

#197

Post by amszmidt »

eviks wrote: post #170
amszmidt wrote: post #154

Earlier quoted context omitted.

Debian has about 59000 packages. Even rebuilding 1k of that is a significant pain on build infrastructure, specially in one go, if say a vulnerable library is found. You also now get a huge set of users who will now download these 1k of updated packages. Not to mention the utter fun of trying to understand why your system just requires maybe 100 packages to be updated… Compare to upgrading a single shared library.

Do you know whether someone has made an estimate based on the history of actual vulnerabilities of how much rebuilding would need to be done in a non-shared library approach?

Not to my knowledge. But consider something like crypto, libssl ... which is linked to almost everything, or libxz, zlib, etc. If there is a bug in a shared library, one can replace it with a interm one very easily, and the whole operating system will use it. One can even replace it with a different implementation assuming ABI compatibility, without having to do "much".

Enclaves like Go, Rust, Swift (things that insist on using direct sys calls, and eschewing system libraries) would need to implement their own versions, or use FFI, and then you're SOL anyway if you really insist to use static linking... And who knows what kind of bugs might crop up there that don't match whatever anything anyone else uses.

Shrug :-)

Re: Swift Static Linux SDK

#198

Post by mannuch »

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?

https://github.com/apple/swift-for-wasm-examples?tab=readme-...

Re: Swift Static Linux SDK

#199

Post by msie »

glhaynes wrote: post #159
dzonga wrote: post #91

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

"Swift is too complex now" has seemed to have achieved meme status of late but I don't see it. For the average developer, writing modern Swift is generally not any more difficult than it was several years ago (much more often it's easier), it's just that the language can do a lot more now. But you only need to learn those new parts if you're using them. If you're not writing low-level or special-purpose code, you don…

"But you only need to learn those new parts if you're using them" - people only use a subset of C++.

Re: Swift Static Linux SDK

#200

Post by msie »

beanjuiceII wrote: post #45
jkelleyrtp wrote: post #32

Earlier quoted context omitted.

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.

after using swift extensively i did not find it better of the two, in fact it is a complex keyword ridden language that seems bolted together at very many angles, each swift codebase i enter is like a new mystery to unfold because of its extremely rocky evolution

Yes! Reading Swift code, even tutorial code, can be difficult.
Post reply on HN