Comment by rgovostes | Hacker News Reader

Comment by rgovostes | Hacker News Reader

Parent Full thread

On the other hand, Apple released their 64-bit ARM backend for LLVM[1] in 2014. They announced their intention do so almost immediately after the first ARM64 phone, but the process took several months because it had to be merged with a duplicate backend developed by others.

I think it is likely that support for these instructions will be upstreamed to LLVM, and the teams involved in this monumental transition (which was announced like ~50 days ago) simply didn't put it at the highest priority on the list of things that developers need to know to get their apps working on Day 1.

A fair criticism is that some of the more technical documentation, such as on the Mach-O ABI, have disappeared from Apple's developer site, or been relegated to an unsearchable archive[2], so it's very reasonable to be skeptical of ISA extensions ever being documented there.

The developer site has always sucked though, and it seems to me they've declared bankruptcy and are rebuilding it on machine-generated docs and WWDC content for app developers. Occam's razor.

1: https://www.phoronix.com/scan.php?page=news_item&px=MTY0NzE

2: https://developer.apple.com/library/archive/navigation/

I just started getting into macOS and iOS development and the documentation is HORRENDOUS.

Even the classroom educational material Apple put out is incomplete, outdated, and often completely wrong!

Additionally, It seems to be impossible to compile anything in Xcode other than a hello-world without gettting undocumented warnings and (non fatal) errors logged, which, if you can find a matching thread on their forums, usually results in a “just mark it down as log noise”.

Has it always been this bad?

No it wasn't always this bad. The speed at which Swift has changed has left the documentation behind. I've complained about this numerous times.

Simply put, if you want useful doco don't look at the latest version of the language. They literally stripped the useful notes and examples and it's now a straight API print out.

If you use stackoverflow (sarcasm) be prepared to constantly be using older versions of swift and translating them to the latest. Feel free to submit updates to them.

So it does help to understand what changed in the language versions. I think anything past Swift 3 is similar to today. Xcode does help a little telling you what you pasted makes no sense to a degree.

It's a very sad state of affairs I'm afraid.

Good documentation will come. Apple's current priority right now is converting macOS to a closed OS like iOS. Once this is done, Apple can advertise the fact how "easy" it is to build apps for both ios and macOS with one codebase. Apple will then taut "courage" as they force all Apple developers to switch to Swift if they want to develop on their ecosystem. You will ofcourse have to pay them for this privilege, and that ofcourse is the end goal.

Are you a senior executive at Apple?

Yes. I have recently released my first game in the app store. It is a simple game, and so this is probably the 3rd rewrite of it.

The second rewrite was when I finally had an apple device, so I thought "I will do everything the apple way" - I used Swift and SpriteKit, and tried to do everything exactly how I thought the Apple people would like.

I then dropped that laptop, and was told it would cost more than the price of the laptop to repair, so I decided to do another rewrite - this time, using my linux laptop.

The experience of writing it in plain documented C, and using libSDL2 for most of the IO was far superior. Writing my own physics engine instead of using the SpriteKit one made the actual gameplay better (because it meant I could easily fudge physics a bit to make it more fun).

Only at the very end of the project did I then go through the painful process of making it happy with xcode, happy to build for iOS, and then finally happy with the Apple review process (including hacking my SDL build to remove bluetooth peripheral support so I didn't need to request unwanted permissions).

I now have an M1 Macbook Air, and I've briefly looked again at doing things the "apple way" (e.g. swiftui) and I'm coming to a similar conclusion.

You should use git.

There’s a lot you get for free from things like SwiftUI, such as accessibility, support for right to left locales, portability all the way from the Apple Watch to the TV, etc.

I am also currently writing an app using SDL on Linux, which I have previously written in SwiftUI and it’s a lot of fun, but it’s just not comparable.

My SwiftUI version runs on the watch, the iPhone the TV and even in widgets with barely any modification. (And with much better fonts!)

The Linux version is fun, but it’s just not comparable in terms of the work the platform is doing for me.

I just started working with Swift again after building a couple toy apps when Swift was brand new. I feel your pain with their documentation!

What bothers me most is how their documentation for anything is a massive scrollfest[0], followed by links everywhere, yet the actual documentation still feels sparse enough that I almost exclusively try to just read the source code and make guesses. Rails docs sure aren’t going to win any design awards, but at least I can access everything on a single page![1]

[0] https://developer.apple.com/documentation/swiftui/view

[1] https://api.rubyonrails.org/classes/ActionController/LogSubs...

Why not pretend Swift doesn't exist and just use Objective-C instead? It's stable, it's well-understood, there's a ton of examples and docs everywhere and it hasn't changed much in a decade.

I'm mainly an Android developer, so I've never made anything serious for the Apple ecosystem (only some tiny Mac apps for myself), but I just hate moving targets with burning passion. It's hilarious to look at all the "community" with their Kotlin and support libraries and jetpack and other abstract-the-evil-OS-away stuff changing and breaking everything three times a month while the only changes I see myself are those to the raw underlying system APIs whenever there's a major OS release.

100%. I hate swift.

Why? I loved obj-c, but Swift seems better in almost every way.

You can just program using obj compatible objects in Swift if you like.

What’s so bad about it?

It’s always been bad, but it got worse when they did a major design change to their website.

My point about the docs isn't the day-to-day stuff, but the things that cannot be machine generated - to write a good compiler you need to know the details of how the CPU is put together underneath.

Intel will give you 800 pages on how to optimize for their current ISA (AMD will give you 45, but still)

As I understand it, Intel will also sell you a compiler that can optimize better than GCC because they know internal microarchitecture details. To me, that seems like a more clear-cut by-design conflict of interest between chip designer and user than these undocumented instructions.

Do you think Intel considers their compiler a profit center/growth market? Or are trying to offset the expense of maintaining their own compiler?

Intel's compiler is basically free for plebs but not for datacentres.

LLVM and GCC are good enough (brilliant, even) for general purpose compilation, but for a (say) supercomputer which is guarded by guns having Intel on the phone can be worth it.

You think it is bad that a company provides good documentation on how their product works and how to use it?

This is not an accurate characterization of what I wrote whatsoever. Please don't misquote people in order to start flamewars.

GCC and Clang both generally match ICC’s performance, and in my experience beat it more often than they lose to it. ICC’s only real advantage is MKL and other bundled libraries, which are generally better than what free software has to offer.

Clang and GCC regularly go toe-to-toe with or exceed ICC and have plenty of architectural cost models for modern systems, in part thanks to the extensive documentation and free tools from Intel themselves. ICC does have some gimmick features like GPU offload, and (last I saw) much better auto-vectorization. But as far as run of the mill code goes, you aren't going to get some magical double-digit performance uplift on average scalar code that can only be attained by ICC and/or Intel doing subterfuge.

Beyond that, making a claim of a conflict of interest requires more than just "It seems like these words fit and sound right, to me." Because "Microprocessor company writes well optimized code for their microprocessors and sells it" hardly seems like a conflict of interest at all in this case, it literally seems like a company selling a product that goes with their existing product. Absolutely everybody does this, including AMD, IBM, Nvidia, Apple, etc. It is not a "conflict of interest" for Intel to both design a microprocessor and also sell code that works well on it. What might be a conflict of interest is if they said "We have an obligation to release these specifications, but also we can make lots of money off them if if we keep them private despite that existing obligation, so we'll just keep them private." Which is a much stronger claim. (In fact even the infamous "cripple AMD" legal SNAFU over ICC wasn't a conflict of interest, it was brought as an antitrust suit, AFAIK.) It's not like Twilio has a "conflict of interest" when they implement new features in their product portfolio, build them on Twilio's servers, and integrate them with other Twilio products.

In general, Intel is ahead of almost every other vendor when it comes to publicly-available information regarding performance optimization (first and third party), by a landslide.

AMX was first announced for the A13 [1], so it's been in the wild for over a year now.

1: https://www.anandtech.com/show/14859/apple-announces-new-iph...

And Apple M1 implements AMX2, not the original AMX in the A13.

I'm not sure if Apple plans to ever maintain AMX compatibility across CPU versions...

You've hit on an important point here. As soon as Apple documents one of their CPU extensions, they've put themselves in the position of having to support it long-term. Leaving it undocumented gives them the freedom to make breaking changes from one CPU generation to the next -- hopefully with the end goal of deciding on an implementation and documenting the end result.

Apple must support base LLVM functionality because it is the core of their extend-embrace-extinguish strategy. This says nothing that they will extend that offer to their undocumented secret sauce, as you imply.

Don't be absurd. LLVM was a research project until Apple hired Chris Lattner and poured money into it to make a viable alternative to GCC. They've been among the project's top contributors (financially and in terms of code) for 15 years. That's quite the long con.

Apple creates plenty of proprietary technologies but I can't think of a time they've been credibly accused of crushing an open technology that already existed.

They did that, in part, because they were subject of one of the first GPL enforcement actions, originally being unwilling to open source their objc GCC frontend. They being Nextstep at the time, but there's not a huge distinction these days.

Their investment in LLVM is very much an attempt to keep reproprietization on the table.

I absolutely believe that the investment in LLVM was justified to executives as a way to avoid GPL-licensed software, which Apple has long been allergic to.

But it should be noted that the GPL violation you refer to was in 1989. Put in context, that was ~16 years before they started investing in LLVM, and they have done so continuously for the past ~15 years.

Ultimately what the executives think is the reason is the real reason, as we saw from Oravle reproprietizing Solaris.

And yes, it was a while back that literally lawyers had to get involved in their blatant GPL violation in the compiler space. We absolutely get to judge a company on it's past actions.

> We absolutely get to judge a company on it's past actions.

I wholeheartedly agree with that statement, but you are judging a company based on the actions of another company it acquired 7 years later.

I'd argue that Apple of today is closer to Nextstep than Apple of the same time frame. Like, it was literally Steve Jobs making that decision at the time to violate the GPL. The joke for the longest time was that Nextstep bought Apple for negative dollars because of how much senior leadership was carried over from nextstep.

It's not like it was some random startup they acquihired for a couple engineers.

It should also be noted that GCC was not suited technically, by design, for what Apple wanted out of a compiler at the time.

The JIT stuff they were doing with image filters for Core Image and Core Video and the IDE integration they were doing in Xcode could not be done in GCC at the time regardless of licensing without making massive changes, which would not have been accepted upstream.

GCC at the time was intentionally designed and implemented to make it hard to use parts of it independently, such as just using the parser to make a syntax tree for your IDE to use for highlighting or suggestions, or using the code generator in a JIT.

There had been suggestions and patches to make GCC more modular and separable, but they were rejected because being more modular would make it easier for proprietary software to interact with GCC components.

It was only after LLVM and clang started getting widespread use that GCC became more open to the idea of it becoming more flexible like LLVM.

The way you put it non copyleft licenses are just there for bait and switch. I don’t know any case where that happened where there was outside contributions.

Oracle reproprietized all of Solaris, including the outside contributions up to that point.

And I assume that Apple has support for these instructions this whole thread is about in their toolchains, so if that's the same version that's in xcode, reproprietization is already happening.

Leaving reproprietization on the table is the whole point of non-copyleft open source.

Solaris was released under a copyleft license (CDDL). How did they do that. When I google it I find your comment as the first result.

They required a copyright assignment as well. They then re licensed everything as proprietary.

https://www.youtube.com/watch?v=-zRN7XLCRhc&t=2281s

CUPS is the closest where you could accuse Apple of doing that I guess.

... and in the CUPS case I could see it more of a situation where they wanted good printing support, saw that unix printing was a horrible mess, but that CUPS had promise, decided to bring it in-house in order to make it work well on macOS, and then after that was done, stopped really caring about it all that much.

Because printing is just so unsexy in general, and tends to get neglected everywhere.

Put another way: "Apple pays project leader Bay Area salary + pre-iPhone AAPL stock to support open source development for more than a decade." (There are certainly more projects Apple relies on that deserve this!)

Most of Apple's extinguished open source projects are ones they started themselves and then abandoned.

it's is a long as OSX. So it perfectly matches the 'long con' time frame. Just don't know why you go about calling amoral business strategies designed to benefit from opensource without giving anything substantial back as a "con".

There were alternatives to LLVM and patches to gcc that achieved the same. Apple option to bring llvm up by investing heavily in it has more to do with the licensing than technical aspects.

Reply on news.ycombinator.com