It looks like this hinter will be used only in rendering PDFs, because that's where they test the performance.
https://www.dell.com/en-us/shop/dell-laptops/dell-15-laptop/...
It is very, very common. Just not in the Mac world.
To me, it's more about what I'm used to. I have a perfectly fine several years-old monitor, so why should I throw it away?
Other way around, most Mac software is not tested how it behaves on inferior external monitors.
If you work with text and fine UI elements, do yourself a favour and get proper tools for the job. Get an ergonomic mouse and a good keyboard while you're at it. In every other field professionals use high quality tools to do their jobs, IT shouldn't be any different.
A plumber has equipment worth tens of thousands of dollars, while IT professionals think it's outrageous to pay a few hundred for equipment which is undeniably an improvement.
RIS is happening across all OS levels, if the keynote is to be believed.
I’m not sure exactly which. I assume it’s some of the code and not all. But it’s not new in the abstract.
That said I don’t think I’ve heard of it in the kernel of MacOS on the main processor. That may be new.
Either way this is certainly the most concrete announcement I remember them ever giving on this stuff.
Edit: This is the guy: https://rustcurious.com/course/
However I miss them actually having had one of those 15 - 30m WWDC sessions, where they could have gone a bit deeper into the keynote examples
In any case I would have liked to have more info during the deep dive sessions.
As it is, Meet with Apple on security (a 5h long event) had much more information.
https://blog.timac.org/categories/reverse-engineering/
And frequently discussed on Hacker News:
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
https://faultlore.com/blah/swift-abi/ (written by a core Rust developer)
[1] apart from the basic/universal C one, which prevents exposing any useful Rust semantics over the interface
Rust is also just a more complex language. I’m not convinced the benefits would have been worth it.
Swift is also interoperable with different versions of itself courtesy of the Swift stable ABI (Application Binary Interface)[0], which they invested a significant amount of time into at the expense of adding other new features to the language, which have come along later.
Rust offers a different approach: recompile everything and static linking.
The gap between the two languages is quite small, it just makes me wish Apple was also all-in on Rust
Rust 2026 roadmap has language ergonomics on it for a reason.
That said, outside Apple ecosystem you probably better with Rust, or if one has no GC issues, OCaml, Haskell, F#, Scala, C#.
Knowledge of Swift not required. If you know your way around OS software, can reason about the security of the code you write, and are excited about writing exhaustively tested software, we’d love to talk to you.
We’re hiring for roles in kernel/systems and userspace. Like the Platforms SOTU mentioned, we’re using Swift at all layers of the software stack now. https://www.youtube.com/live/yl2jsIoMfDU
I had the pleasure of leading the effort to ship Swift in the Secure Enclave back in 2022. Now I have multiple teams working on accelerating the transition to memory safe languages. We’re showing that with good planning and a relentless focus on testing, we can improve security, performance, and functionality. And we get to have a ton of fun working with some amazing colleagues. It’s the most enjoyable and impactful work I’ve ever done in my career.
I may be wrong about this, but I don't think Apple bans you from applying to multiple positions within the same year the way some companies do.
There also seems to be a decent pipeline for new graduates (though I think highlighting relevant academic, research, and open source projects can still help.) Internships can also be a path if you are currently in school.
I don't know if Apple recruits on linkedin, but that might also be an option.
Of course connecting right here on HN seems like a great idea as well.
Of course in an alternate universe where macOS (and iOS etc.) was based on Multics rather than Unix, it would have had essentially zero buffer overflows - which are hard to create in PL/I but hard to avoid in C. Even Apple's Pascal compilers from the 1980s had range checking...
But legacy C code can/should absolutely use things like clang's -fbounds-safety (has been in clang on macOS for years) etc. Fil-C is another option.
It worries me. I hope Codex adoption picks up there.
Vello has been a big inspiration and source of knowledge for my own webgpu text renderer, thank you for that!
Just strings or rendering strings?
If the latter, who are the other members of the club?
There's also, very relevantly, the DWriteCore work from Microsoft. My understanding is that there's been some talk of open sourcing that, but it's still proprietary.
There are other things that count as high performance text in memory safe languages, for example implementations in Go, but in general those are not a good candidate to replace C and C++ in environments like operating systems and browsers.
It does feel like a compiler/optimiser failure to have to rewrite those cases.
Though, it probably wouldn't work if user code modified the Array prototype.
That said, I’m looking forward to using Swift lifetimes once they actually work!
Did they need a fuzzer for that? They could've render them all and see what's exercised?
I'm not sure what became of it and if it ever shipped. If anyone knows I'd be curious.
But I personally reviewed every line that shipped and was absolutely insufferable about testing.
This is the most interesting bit to me. Engineers consistently underestimate the amount of effort that testing demands for projects that need truly high quality, it’s nice to see this shared.
