Live data from Hacker News

Swift at Apple: Migrating the TrueType hinting interpreter

swift.org

41–50 of 139 posts

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#41

As much as I enjoyed Swift, one can only wonder what the world would look like if they had gone with Rust as their default language instead.

One of the genius things about Swift is its interop with Objective C. Made the switch over considerably easier for developers. I’m not sure what that looks like in a Rust world.

Rust is also just a more complex language. I’m not convinced the benefits would have been worth it.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#42
post #38

What's funny is from 2023 (I think), macOS just draws the UI unhinted. You have a 1080p display and you don't want to see the letters in the UI blurred to death? Tough luck, 1080p is incompatible with macOS, everybody needs "retina", and nobody cares that Windows and all Linux DEs look on 1080p just fine. It looks like this hinter will be used only in rendering PDFs, because that's where they test the performance.

My last 1080p monitor was around 20 years ago. I have trouble comprehending people still use them regularly.

A very quick search yielded Dell selling 1080p laptops today:

https://www.dell.com/en-us/shop/dell-laptops/dell-15-laptop/...

It is very, very common. Just not in the Mac world.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#43
post #21

Earlier quoted context omitted.

Modern Swift borrows a lot from Rust! And it also has its own benefits, both ergonomic and also supporting eg generic in dynamic libraries

Does it borrow borrow checker?

I believe Swift tends to use reference counting and copy-on-write strategies. This, like GC, is less for the programmer to think about and doesn't require the semantic checks, but sometimes the performance cost is unacceptable compared to what you'd write in Rust.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#44
post #42
post #38

Earlier quoted context omitted.

My last 1080p monitor was around 20 years ago. I have trouble comprehending people still use them regularly.

A very quick search yielded Dell selling 1080p laptops today: https://www.dell.com/en-us/shop/dell-laptops/dell-15-laptop/... It is very, very common. Just not in the Mac world.

It's also the corporate standard for generic cubicle workstation monitors, though it's unusual to find a Mac in such a place anyway.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#45

What's funny is from 2023 (I think), macOS just draws the UI unhinted. You have a 1080p display and you don't want to see the letters in the UI blurred to death? Tough luck, 1080p is incompatible with macOS, everybody needs "retina", and nobody cares that Windows and all Linux DEs look on 1080p just fine. It looks like this hinter will be used only in rendering PDFs, because that's where they test the performance.

macOS has been drawing unhinted text for an eternity, and for those who can tolerate it on low-DPI screens, it's a great thing: the letter shapes look the same at all sizes, and the spacing between letters is consistent at all sizes.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#46

What's funny is from 2023 (I think), macOS just draws the UI unhinted. You have a 1080p display and you don't want to see the letters in the UI blurred to death? Tough luck, 1080p is incompatible with macOS, everybody needs "retina", and nobody cares that Windows and all Linux DEs look on 1080p just fine. It looks like this hinter will be used only in rendering PDFs, because that's where they test the performance.

I had this problem on the first Apple Silicon Mac Mini in 2020 so it's at least a little older than 2023.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#47
post #2

During the State of Platform keynote, on the subject of Swift adoption across macOS, several examples were given, not only TrueType engine. RIS is happening across all OS levels, if the keynote is to be believed.

They’ve been doing it for years. I don’t remember how we first knew, but I know they’ve been using Swift in kernels for at least some of the other chips like the Secure Enclave or whatever.

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.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#48

Earlier quoted context omitted.

Modern Swift borrows a lot from Rust! And it also has its own benefits, both ergonomic and also supporting eg generic in dynamic libraries

These days I mainly write Rust but I did write a semi complex iOS app and enjoyed Swift. I just didn't love how slow the type checker was and how it got lost. I recall having to break things into smaller bits to help the compiler, and there were some oddities about the language. The gap between the two languages is quite small, it just makes me wish Apple was also all-in on Rust

In the last year they’ve added improvements to the type checker to speed it up, those would have been released now.

They have further and much more significant changes that I think might have recently landed in the development version. That should make an even bigger difference. But it’s not in a released version yet.

And yes, none of us like that one part of Swift. Especially the DRASTIC difference compared to objective-C which really only checked syntax and little else.

It’s still probably my favorite language right now though I don’t get to write in it much.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#49
post #21

Earlier quoted context omitted.

Does it borrow borrow checker?

I believe Swift tends to use reference counting and copy-on-write strategies. This, like GC, is less for the programmer to think about and doesn't require the semantic checks, but sometimes the performance cost is unacceptable compared to what you'd write in Rust.

They have either recently added or talked about a borrow style system in the language as a way to avoid more copies and speed things up/lower memory usage/help with asynchronous programming.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#50
post #21

Earlier quoted context omitted.

Does it borrow borrow checker?

I believe Swift tends to use reference counting and copy-on-write strategies. This, like GC, is less for the programmer to think about and doesn't require the semantic checks, but sometimes the performance cost is unacceptable compared to what you'd write in Rust.

You can choose to use either refcounting or unique ownership for your types. For most use cases, refcounted (+ copy-on-write) is the best choice and is the default, but the truetype interpreter made extensive use of non-refcounted types to achieve this performance.
Post reply on HN