Timac

Facebook is the world's largest PHP shop. Does that mean that everyone should use PHP?

As it turns out, moving fast and breaking things isn't all that conducive to quality engineering[1][2]. Facebook has a massive legacy code base maintained by an enormous team that is under pressure to iterate quickly while supporting what is arguably the world's largest user base. They are dealing with extremely specialized constraints that most of us will never encounter. Many of the trade-offs they consider acceptable aren't trade-offs that make sense elsewhere.

And that's exactly what the blog post is getting at. A lot of these emerging technologies are situationally useful in a particular set of scenarios and environments, but developers with cargo cult mentality convince themselves that these things will solve all of their problems if they use them everywhere. When the disappointment sets in and they figure out that isn't the case, yesterday's darling stack becomes the subject of today's "considered harmful" essays and everybody moves on to the next shiny thing.

The point here is that maybe you should make a sober assessment of new technologies and objectively evaluate whether they are actually practical for your usage scenario rather than just blindly jumping on the bandwagon and using something.

The examples from the blog post are totally on point. I previously worked at a company that built a NoSQL database and I have great affinity for the technology, but there's no question…

There is a lot of C++ at Apple. It's of course possible to work there and never touch it, but it's also possible to work there and do almost all your work in C++. Many significant parts of iOS and macOS are written in C++, for example WebKit, the implementations of ObjC and Swift, clang/llvm, dyld, CoreAudio, CoreAnimation, WindowServer, Dock, Finder, etc.

I enjoy this[1] annual series of blog posts on Apple's usage of Swift in iOS. I just did a quick and dirty, but similar analysis of Apple's usage of C++ of the macOS 12.5.1 install on my computer. I extracted my dyld_shared_cache, and then used find and nm to count up binaries containing unstripped C++ symbols. This undercounts the usage of C++, since sometimes it's used only internally in stripped binaries, and I also think the number of binaries metric probably undercounts the importance of C++ because the ones that do use C++ tend to be more significant binaries, but even still it gives some idea of the scope of C++'s use at Apple.

About 25% (559 / 2292) of the libraries in the dyld_shared_cache contain unstripped C++ symbols. About 15% (22 / 154) of executables in /System/Applications (so 1st party apps / helpers that ship with the system) do.

That said, I think you're probably right that things are changing. Probably there are lots of people at Apple thinking of how they can replace C++ with Swift in their code. But on the other hand, I would not be surprised if we can still find significant uses of C++ in…

> Does SwiftUI really count as native on the Mac? My experience is that Apple has not invested enough for that to be true

https://blog.timac.org/2022/1005-state-of-swift-and-swiftui-ios16/

iOS 16.0 included 226 SwiftUI apps. Several highly promoted features (such as complications on the Lock Screen and widgets) are now only possible using SwiftUI.

Some new SwiftUI only frameworks (like Swift Charts) developed directly from internal Apple teams creating new SwiftUI apps, and factoring out useful components.

> Regardless, inconsistencies between AppKit on Mac and SwiftUI on Mac are enough to make it not native, IMO.

SwiftUI is not a wrapper around AppKit controls, although that is/was how some SwiftUI views are authored. Likewise, some recently added AppKit controls are actually wrapped SwiftUI views.

There is an ongoing effort to unify macOS and iPadOS which became much more noticeable at the UX level in macOS 11. It is unfortunately difficult to determine which inconsistencies are deficiencies in SwiftUI and which are the "legacy" behavior of AppKit.

Since SwiftUI is a system framework, we only see its evolution in spurts on an annual schedule.

Given that the person who created LLVM also created Swift, the ability to be used as a systems programming language was always there.

Chris Lattner, the creator of both LLVM and Swift, has referred to Swift as “syntactic sugar for LLVM.” They are deeply tied together.

The amount of Swift code in Apple's operating systems has increased every year.

https://blog.timac.org/2023/1019-state-of-swift-and-swiftui-ios17/

Lattner gave an interview looking at the advantages of reference counting over the sort of garbage collection used in languages like Java, C#, and Go while still avoiding error-prone manual memory management.

> ARC has clear advantages in terms of allowing Swift to scale down to systems that can’t tolerate having a garbage collector, for example, if you want to write firmware in Swift. I think that it does provide a better programming model where programmers think just a little bit about memory.

https://atp.fm/205-chris-lattner-interview-transcript#gc

Yep, same page.

Chrome 76.0.3809.132 (Official Build) (64-bit) (cohort: Stable), Windows 10.

That said, I guess I needed to update Chrome, so I just did to 77.0.3865.90 (Official Build) (64-bit) (cohort: Stable)
, and same error.

Here's a "copy as cURL" for the request, maybe that can help?

curl 'https://blog.timac.org/2019/0926-state-of-swift-ios13/' -H 'authority: blog.timac.org' -H 'cache-control: max-age=0' -H 'upgrade-insecure-requests: 1' -H 'user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36' -H 'sec-fetch-mode: navigate' -H 'sec-fetch-user: ?1' -H 'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3' -H 'sec-fetch-site: cross-site' -H 'accept-encoding: gzip, deflate, br' -H 'accept-language: en-US,en;q=0.9' --compressed

“Apple's privacy is just marketing smoke and mirrors” — an HN commenter, probably

For every privacy feature Apple advertise to consumers about, there are ten they didn't, that still very much raise the bar.

The quiet improvements are so under-marketed that even technically savvy users aren't aware of most of them.

There was a period before MDM matured that certain three letter U.S. Gov agencies forbade iPhones. Not because they were insecure, but because the agency's infosec team couldn't surveil the devices or break in to do a data dump if the employee was under investigation.

Certainly, they still have zero days, and vulns dating back longer than anyone would like. So it's interesting what's happening to iOS use of C: https://blog.timac.org/2023/1019-state-of-swift-and-swiftui-ios17/