231–240 of 274 posts
Earlier quoted context omitted.
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.
> Cons of static linking: Not listed is that ASLR either doesn't work at all or you get just one object (the PIE's) randomized. For a memory safe language this may not be a con at all. Also, when many executables can share common objects then there can be a reduction in I/O (reads) needed to load those the next time that one of those executables runs. In 2004 when the Solaris 10 (then a work in progress) unified proc…
Earlier quoted context omitted.
> - 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 tr…
Not really no. Look at go, D, nim, or any ahead of time compiled language.
> ARC is key in providing Swift its ability to maintain its low memory footprint compared to, say, Java
Again not really. Java has other issues. Like lack of value types, conservative escape analysis, needing extra memory for profiling and the jit, and HotSpot’s GCs are focused on server applications and are designed not to release memory until they’re about to run out.
Even if this were true ARC trades memory for execution speed. I can’t find the exact paper right now but the ixy implementations showed that you end up spending an unhealthy amount of time just counting references when you stay in pure swift code. I think it was somewhere > 30%.
What might a cross-platform GUI app look like with Swift? I'm assuming SwiftUI can't be used? Regardless, I'll definitely be reaching for Swift for one-off scripts. I've enjoyed the times I needed to use Swift for a React Native extension.
After exploring most of these for my use case (something that needs to run on an "embedded" RPi CM4 as well as iOS), I wrote a Swift bridge/runner for Flutter [7] which is working well. That enables me to write the UI in Dart and the business logic in Swift. I looked at all the other options below (that's how I know about them, indeed [3] I wrote as part of my research), in the end I felt that none of them were at the time of investigating sufficiently mature to base a product around.
[1] https://github.com/rhx/SwiftGtk
[2] https://github.com/Longhanks/qlift
[3] https://github.com/PADL/LVGLSwift
[4] https://github.com/TokamakUI/Tokamak
[5] https://github.com/stackotter/swift-cross-ui
Earlier quoted context omitted.
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.
> I just don't want you to force me. Rust supports dynamic linking, and has since well before 1.0.
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…
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.
That would imply either:
1. Bare-metal Linux AI OS runs on Apple Silicon. Apple could contribute Apple Silicon firmware/hardware support to Asahi and mainline Linux.
2. Virtualized Linux AI OS runs on Apple Silicon Hypervisor. Apple could contribute mainline Linux guest support for Apple Hypervisor. They could also support Linux VMs on MacOS and iPadOS which run on Apple Hypervisor, for M2+ devices with hardware support for nested virtualization.