Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift at Apple: Migrating the TrueType hinting interpreter

swift.org

Post reply on HN
Print view View original

81–90 of 139 posts

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#81

Post by mschuster91 »

AndriyKunitsyn wrote: post #67
mschuster91 wrote: post #51

Earlier quoted context omitted.

The problem is, as soon as you are not on a Mac but Linux or Windows, you are in for an awful, truly awful lot of pain. HiDPI support is a mess because even in the rare case applications are made with HiDPI in mind they are not tested on HiDPI machines. Other way around, most Mac software is not tested how it behaves on inferior external monitors.

What kind of windows programs are these? HiDPI is more than a decade old. A desktop application, no matter what OS it is, should always be tested with different scaling factors.

Ham radio software, both open-source and commercial, is a big thing, and so is many an in-house development in many businesses.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#82

Post by pjmlp »

ecshafer wrote: post #24
jadengeller wrote: post #17

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

Swift and Rust were developed at similar times. I think of them more as having similar influences than borrowing from each other.

Additionally both have influences from CLU, C++, Object Pascal, Modula-2, Mesa/Cedar, Standard ML, Cyclone.

Many features that get discussed as being Swift/Rust, trace back to one of those languages.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#83

Post by pjmlp »

MBCook wrote: post #47
pjmlp wrote: 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 c…

Some stuff was discussed at Meet with Apple security event a few months ago, and the talks on FoundationDB rewrite, or why Swift Embedded subset came to be.

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

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#84

Post by pjmlp »

airstrike wrote: post #15

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.

Swift takes the right approach in language ergonomics, many of its use cases would be much harder with explicit .clone() all over the place, lack of back references, no standard ABI for binary libraries, interop with Objective-C and C++, no standard concurrency runtime, or error handling types.

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#.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#85

Post by pjmlp »

inkyoto wrote: post #71
afavour wrote: post #41

Earlier quoted context omitted.

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.

Not just interoperability with Objective C but with C (full) and C++ (increasingly better but not full) as well. 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:…

C compatibility comes via Objective-C, because contrary to C++, Objective-C extends C, instead of being based on a C subset.

You missed Java as well.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#86

Post by pjmlp »

tialaramex wrote: post #43
vardump wrote: 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 pick and chose, and memory ownership is getting better in latest versions.

Being more ergonomic is relevant enough for increasing language adoption, that possible improvements are now on Rust roadmap.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#87

Post by [deleted] »

incanus77 wrote: post #79
yjftsjthsd-h wrote: post #75

Earlier quoted context omitted.

Then let me blow your mind:) One of my daily drivers is an ex-Chromebook at 1366x768. Granted, it's also physically smallish so the DPI isn't quite as low as a macbook would be with those pixels, but still. And that's a touch cramped but it's fine.

I'm reading on that resolution right now! MacBook Air 11" running Linux that I use as a quick hacking/reading machine in bed.

[deleted]

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#88

Post by KolmogorovComp »

> Operations like filter and map allocate memory, but that allocation is only necessary if the value escapes. The Swift standard library provides .lazy.map and .lazy.filter, but they don’t work in every case. For logic that only iterates over the filter or map, it’s much more efficient to loop with continue (or use for … in … where) and transform elements into local variables as necessary.

It does feel like a compiler/optimiser failure to have to rewrite those cases.

Re: Swift at Apple: Migrating the TrueType hinting interpreter

#89

Post by LoganDark »

wahnfrieden wrote: post #60
andrekandre wrote: post #57

Earlier quoted context omitted.

thats a shame if true, they really should be dog-fooding that horrible agent ui in xcode to bring it up to a usable state

A lot of devs are tricked into using it because it’s official

I love how it doesn't even support reasoning output or edit tool diffs. (Yes it can show diffs sometimes when using the 100% official flow but not when using ACP)
Post reply on HN