> It makes me wonder how they are dealing with memory management when Java objects are being used from Swift
It uses Swift macros to add a `JavaObjectHolder` property to Swift types annotated with `@JavaClass`[0]. `JavaObjectHolder` is a Swift class that takes a global JNI reference to the Java object, and releases it when the holder is destroyed[1].
The result is that a codegen utility emits Swift structs[2] that wrap the JNI values, and the JNI glue code for method invocation is applied at compile-time when the macros are expanded.
> Further, when we exhibited at RailsWorld 2023, there was a definite "blood in the water" vibe regarding Redis and the assumption that you'd automatically need a Redis server running alongside your Rails application.
I've only worked on one production Rails application in my career (and it did use Redis!), so I'm way out of the loop – is the ecosystem turning against Redis from a business perspective (I know there have been some license changes), or is it a YAGNI situation, or something else?
IIRC we used it mainly with Rescue to schedule asynchronous jobs like indexing, transcoding, etc., but it seemed like a neat tool at the time.
It's a little YAGNI - I think the biggest driver of Redis in community was for exactly what you described aysnc jobs and the tool most folks reached for was Sidekiq.
The 2024 Rails community survey just came out and Redis is still listed as the top datastore that people use in their apps.
FWIW - we found that while many folks are _using_ Redis in their apps, they're just using it for things like Sidekiq and not actually taking advantage of it for holding things like real time leaderboards, vector db functions, etc. so it's a little fuzzy the actual usage.
Right now, most rails setups with decent traffic will have frontend boxes, a sql db, a KV store (redis or memcached), and a cache store pointed at the kv store, with, annoyingly, very different usage patterns than typical KV store usage, eg for maintaining api quotas or rate limiting.
Disk performance has gotten fast enough and SQL performance has gotten good enough that there's a movement to drop the KV store and split the usages (for traditional KV use and also backing a cache) to the sql db and disk, respectively. Plus new nvme disks are almost as fast and still much cheaper than ram so you can cache more.
I’ve found it useful in the past as basically very-smart (i.e. stuff like expiration built-in) shared memory. Potentially with clustering (so, shared across multiple machines).
In the era of k8s, and redis-as-a-service, though? It’s gonna be “shared memory” on another VM on another rack. At that point, just read & write a damn file off S3, you’ve already abandoned all hope of efficient use of resources.
There is only 1 license, and it is issued by the WinAmp copyright holders. No additional license is created by hosting a repository on GitHub. The only (extremely theoretical) issue would be between GitHub and the WinAmp folks, if GH believed that WinAmp is violating its TOS.
It wouldn't surprise me if Benno Rice wrote that talk in response to this exact blog post – though there were enough posts in this same genre at the time, and he could have been responding to any/all of them.
Yeah, they contain binaries for Swift itself (the driver interface, the compiler, the repl, the package manager, swift-format, etc.), as well as the toolchain's dependencies (llvm, lldb, clang, the sanitizer runtimes, etc.).
There are other (also large) downloads to enable producing static binaries on Linux, and those contain the required system libraries (musl libc, libicu, libcrypto, libpthread, etc.). Those are about twice as big as they need to be, because they bundle x86 and aarch64 together.
> Apple is not trying to potentially attempt to aim for maybe replacing every other programming language with Swift
Apple's stated goal is to make Swift a viable language up and down the technology stack, which goes way beyond Objective-C. They are actively working on making Swift viable in baremetal environments, firmware, drivers, etc. IIRC they even referred to it as a C++ successor language at WWDC this year.
I agree that they're not trying to "replacing every other programming language," but they're investing in it becoming a viable language choice in most environments.
Which I think that makes sense for them to want it to be viable all over the stack. It also directly benefits them also. I am assuming a lot of the motivation for embedded swift is being able to use it in their own stacks. I think even the presentation for WWDC gave examples of it being used in some pieces of hardware like on the AppleTV?
> they even referred to it as a C++ successor language
Nice!
I'd gently warn against parsing that too closely: having been in the community and the weeds starting in 2014(!).
ex. the cross platform Foundation was announced and open sourced in 2016.
I'm sure a lot of things were upgraded or more consistent and its better etc., but it's a painful to remember what was expected + communicated at the time, and how much later it is.
I think the goal of Swift on the server, or embedded Swift, is mainly to offer Mac and iOS developers a way to write everything in the same language.
Right now, my Mac app depends on a few simple web services that are written in a different language. It would be neat if those services could be written in Swift, so that I could just use the language I already know instead of relearning how to do decode JSON in Python/Ruby/PHP.
Swift on the server doesn't have to become widely used. As long as there is a simple way to write basic web services, it is useful.
> It would be neat if those services could be written in Swift, so that I could just use the language I already know
Then somebody else would have to now learn Swift even thought they write in different language like: Android Developers (Kotlin/Java), React Native devs (JS/TS ), Windows Devs, Linux Devs etc. As long as Apple don't invest more in official cross-platform tooling Swift is not gonna be mainstream (even though I like Swift). They have to bless other competing platforms.
I was more thinking of smaller teams or individual developers that are Apple only.
If you have a bigger team, then it doesn't matter as much, because you have different people who do the iOS app, people who do the website, people who do the back end etc.
Swift on the server doesn't have to go mainstream to be useful. If you just need some basic web service that syncs highscores or verifies in-app purchases then it would be neat if you could write that in the same language as the app itself.
> They are actively working on making Swift viable in baremetal environments, firmware, drivers, etc.
I don’t think Swift has a place in these niches FWIW. Writing low-level Swift code is very verbose and unnatural. Personally I just don’t think it’s practical to have a single language excel across the stack.
I think this conversation has a lot of parallels to their public views on SwiftUI. Are they working on it? Yes. Will it maybe end up being what they consolidate around sometime in the future? Maybe. Does that mean you should believe them when they say it’s the biggest thing you should invest in right now? No.
At the time they thought it would be too slow. In retrospect it would've been fine, I think. IOKit is a pretty strange subset of C++, but at least it doesn't use all those templates.
That was my immediate thought, speed issues. MacOS isn’t exactly an I/O speed king as it is. I suspect if it had made it in it may have been removed by now.
It was in NeXTSTEP. It was taken out because of performance concerns that turned out to be entirely unfounded. Alas, when they figured out that this was the case it was too late.
A similar example is CoreFoundation. It was a C implementation of the OPENSTEP Foundation. To this day, even really smart, capable and knowledgeable engineers believe that CoreFoundation is faster than the pure Objective-C Foundation. It is not. It is significantly slower. Often several times slower.
(It is of course very slightly faster than the "new" Objective-C Foundation that was implemented on top of CoreFoundation).
Another example is Swift. People believe it to be generally faster than Objective-C. Again, this is not the case. Swift code tends to be significantly slower than comparable Objective-C code.
Yes it was. I actually wrote a kernel driver in Objective-C for an EISA board on OPENSTEP.
The runtime support that's required for Objective-C is extremely minimal. In the end you need objc_msgSend() and some runtime structures so that function works.
The methods themselves are just C functions with slightly funky names.
There is code in the kernel to enable treating types like `os_log_t` and Clang blocks as Objective-C objects higher up the stack, but the XNU kernel itself is almost entirely C and C++.
This isn't really my scene so I don't know the details, but I remember reading that the first 10+ million Switches produced have an unpatchable bootloader exploit. I'm sure you're correct that almost nobody actually has a hacked console, but my understanding is that they're readily available for people who want one.
There are competing "safe C++ syntax" projects being advocated by people on WG21 (as well as some members who seem to be opposed to any memory or concurrency safety tools beyond guidelines and linters). It's going to be up an uphill fight for any of them to gain traction, but at least some people are putting in the effort.
I think this one is the first one that actually got a document number assigned though, right? Although still a draft number and it is far from actually having wordings.
They said it's in the process of FDA (and other agency) approval, which likely means the specific model is being validated for use as a medical device. If they only mentioned it for AirPods Pro 2, I wouldn't expect it on other devices.
Once you get one device approved it's easier to get others approved under one of the new fast track programs (or at least that's what my FDA consultant told me a couple of years ago, I'll admit I'm not personally an expert on this).
Not exactly. A novel device has a higher bar to get clearance. If you are developing something that already exists i.e. a hearing aid then you can go the 510k route.
Every model has to go through the same rigor with design controls and get clearance through the 510k process. There is a lot of process and documentation, and as a medical device you can't just update firmware and swap components as they go end of life. And you can't just discontinue a product. When you submit for approval you have to define the lifetime of the product and how you plan to support it through that lifetime.
I imagine Apple will keep the AirPods Pro 2 around for about a decade as their hearing aid device.
It uses Swift macros to add a `JavaObjectHolder` property to Swift types annotated with `@JavaClass`[0]. `JavaObjectHolder` is a Swift class that takes a global JNI reference to the Java object, and releases it when the holder is destroyed[1].
The result is that a codegen utility emits Swift structs[2] that wrap the JNI values, and the JNI glue code for method invocation is applied at compile-time when the macros are expanded.
[0] https://github.com/swiftlang/swift-java/blob/e7d7a217e37d49b...
[1] https://github.com/swiftlang/swift-java/blob/main/Sources/Ja...
[2] https://github.com/swiftlang/swift-java/blob/main/Sources/Ja...
reply