Apple hiring compiler developers for improving Swift / C++ interoperability
jobs.apple.com
jobs.apple.com
If you're want to have access to everything, Objective-C++ is easier.
Where C++ reigns in Metal is being the shading language.
Metal on Windows would not help much because the GPU hardware is what's different.
A metal compatibility layer would encourage developers to start using it for games etc. Doesn't really matter if it performs a little worse - it just has to work.
Apple shipped Intel Macs with Intel/AMD GPUs until quite recently, so hardware might not matter significantly.
Even Microsoft efforts with .NET are half hearted, with the goal to sell Azure, Windows and Visual Studio licences.
Using .NET outside Windows means leaving behind several frameworks that will never be ported, a VSCode subpar experience vs VS (unless you buy Rider instead), relying on the community for GUI frameworks,...
So they get better libraries (from more dev usage) and more native software on macos.
The knock against .NET is strange. Does Google need to make a cross platform GUI framework in Go for Go to not be half-hearted?
Go did not start as a Linux only product for 15 years, and then only got ported half the ecosystem to other platforms, while keeping the key IDE, the one with experience to rule them all, Linux only.
Rather Microsoft's upper management, see the hot code reload attempt removal from dotnet watch, the new .NET plugins for VSCode with the same VS license, or the recent killing of VS4Mac.
Microsoft's management is also on the record in a couple of places, that VS Code will never have feature parity with VS, or that the best dev experience is VS/Windows.
I get a headache even thinking about projects that affect, like, three different teams within my own company. I can’t imagine the kind of migraine I’d get from trying to push a completely new standard out to multiple CPU architectures, operating systems, and GPU vendors across multiple companies.
If anything, Mantle inspired Apple.
As Long Peaks experience has shown, had not been for AMD, and Khronos would still be wondering how OpenGL vNext was supposed to look like.
This is why Apple has issues with Khronos, they didn't like what happened to OpenCL after giving it to Khronos.
I think of the timeline like this: Mantle comes out and it shows that you can deliver performance improvements with a new API that more closely reflects the hardware. Microsoft goes off and starts working on DirectX 12, to bring those benefits to DirectX. OpenGL starts working on a new version of OpenGL, to bring those benefits to OpenGL, but the progress is somewhat slower. Apple works on Metal internally, so it doesn’t have to wait for a new OpenGL and doesn’t have to deal with committees. Khronos sees that they’re being left behind, and kicks off OpenGL Next.
Rough timeline:
2013: AMD makes Mantle (no GA).
2014: OpenGL AZDO talks. Apple delivers Metal 1.0. Khronos kicks off the Vulkan project, then named OpenGL Next.
2015: OpenGL Next renamed as Vulkan. Microsoft delivers DirectX 12.
2016: Vulkan 1.0.
If the audience at Goose Con thinks your talk about Hedgehogs is great, that's not the wrong talk for Goose Con. Maybe it means "Wildlife Con" is a better name, but, maybe that talk, on that subject, at that time, was perfect and there's no wider lesson.
From Apple's point of view C++17 is good enough for their purposes.
Metal uses a C++14 dialect, and LLVM requires C++17 currently.
That is how you end with COM stuff, C++ only SDKs, and .NET dev community having to implementing bindings ourselves.
It's amazing how Apple never toyed with any managed runtimes this whole time.
Being ahead of time compiled doesn't mean a language isn't managed.
Rather automatic resources management, reflection, infrastructure for dynamic loading of plugins,...
ChatGPT says: Is objective-c a managed language?...Objective-C is not typically considered a "managed language" in the sense that languages like Java or C# are."
C++ is not used for the majority of platform APIs because of all the problems, difficulties, and costs of ensuring ABI stability. C++ ABIs are notoriously fragile, which is a problem objc does not have, and swift was designed specifically to reduce ABI issues (that’s part of the reason generics are implemented as they are)
I understand your clarification but gp (jb1991) is just using a different meaning of "first class" than you and gp (bluetomcat).
For some people, a "first class language status" would also include examples such as:
- C++ would be a menu dropdown choice in Xcode project options. In Xcode's "choose options for your new project", the only language options for "Storyboard"/"XIB" are "Swift" and "Objective-C".
- C++ would be the programming language and API for Apple's VR headset ARKit. Instead, it requires Swift and SwiftUI.
- C++ language would be prominently featured as the code examples in Apple WWDC developer conferences and presentations. E.g. go to WWDC sessions page and compare Ctrl+F search hits count for "C++" vs "Swift": https://developer.apple.com/wwdc23/sessions/
Apple documentation has the sentence: "Swift is intended as a replacement for C-based languages (C, C++, and Objective-C)." -- from https://github.com/apple/swift/blob/main/docs/tools/swift.po....
Understandable that some don't include the above bullets but just pointing out that's what "1st class language" means to others. Maybe it's a sign that the term "first class" is too ambiguous and just invites disagreements.
But Xcode does not care about exactly what your project is, and those are just starting templates. Most projects I have ever worked on are combination C++ and (UI language).
To me, you're using a very weird definition of what 1st class language support is. C++ is extremely heavily used, developed, and in invested in by Apple, and Xcode has extremely good and maintained support for it. It is not the language used for UI toolkits because C++ has proven to be bad at that task. Not applying the "everything is a nail" mentality to the C++ hammer is not "not a 1st class language" it's acknowledging one of the major deficiencies in the language.
Your final 'Apple documentation has the sentence: "Swift is intended as a replacement for C-based languages (C, C++, and Objective-C)."' comment is certainly reflective of what I think some people want, but the fact that the article itself is on the topic of Apple working on interop between C++ and Swift should be a pretty good indication that C++ support is such high priority that swift is the only language working towards full interop with native C++. rust, go, etc all just say "write a C bridge", the MS story is managed C++, etc.
Maybe in the future C++ won't be first class on the platform (probably good from safety PoV for all platforms), but that's not any time in the near future.
Interesting statement, considering how there are many popular and highly influential user interface frameworks in C++.
There’s nothing false about whether you can write an app entirely in C++ or not. The only languages you can do this with are Swift and ObjC. You cannot get a window up, access platform features, interact with the frameworks with C++.
You can't use the UI toolkits, because time has shown again and again that C++ is particularly bad at UI toolkits, but also as my other longer answer said, idiomatic Cocoa and UIKit programming has significant subclassing of ui components, and even the most robustly and carefully designed C++ frameworks can't manage ABI stability well (if at all) in that case.
It is pretty standard on apple platforms to have a ton of C++ doing things C++ is good at interacting with things in ObjC and Swift, and the fact the Apple is working to improve the c++/swift interop when every other new language has the response of "who cares about C++ interop? they can just write c interposition layers until they can replace an entire subset of the library all at once" demonstrates how important and well supported C++ is on the platform.
Long term who knows. Despite the questionable equivocation about safety from Herb&Bjarne modern C++ is not safe, and new features that introduce lack of safety keep getting added while long term failings like the over reliance on UB for definable behaviour[1], and as long as that attitude remains my hopes for actually getting C++ to a place it can be used safely if it can ever be exposed to attacker control data remain low, and so the future would eventually see C and C++ being dropped everywhere. Looking forward to safe languages in the kernel: swift, rust, and the most popular safe language in the world: javascript!!!! :D
[1] C++ has "unspecified behavior" and "implementation dependent behavior" that allow for different behaviour that people claim UB is needed for, without the "compiler can pretend this doesn't happen" nonsense
https://github.com/apple/swift-evolution/blob/main/proposals...
At runtime, it’s functionally close(ish) to malloc/free and doesn’t carry much overhead.
ARC certainly helps ARC be more performant than ARC without ARC due to the elided traffic on the count. (lol)
Also, internally the stdlib uses objc arc types nsarray nsstring etc only on Darwin platforms for zero overhead objc interop. This isn't the case on Linux and windows. For some embedded or Micro-swift variant for low level os work there could be a similar stdlib toggle for Darwin I think.
Citation needed on the performance loss. So far only a handful of SIL optimizer passes have been rewritten in Swift.
FWIW there’s been plenty of C++ in macOS since the start, eg. Security.framework.
I never understood why the "Champagne" issue was so obviously silly to Americans.
Champagne is an actual place, that's where the name of the wine made there comes from.
Could you name something "Napa Valley wine" if it's not from Napa Valley?
Champagne is not about a recipe or concept, the grapes are grown and made to wine in the actual place.
In actual language usage, in the US, many people use champagne to mean any white sparkling wine (possibly any sparkling wine).
In the southern US 'coke' can be used to mean soda. Any soda. Even Pepsi. It doesn't matter that Coca-Cola has the trademark for Coke or that a Pepsi isn't a Coke.
No, the location does affect the taste of the wine (soil composition, sun exposure, type of vines, local traditions in how things are done…).
Dictionaries aren't static and have to be updated constantly.
The rules are different for official product names though. I think "sparking wine" is explicit enough for any of these drinks to not have to strip the Champagne region of its name.
Your argument about "official product names" seems inconsistently applied.
In your first paragraph, Nintendo® and Lego® are registered trademarks with the government and therefore, "official product names":
>I agree people should be allowed to colloquially call it whatever they want. Nobody will be there to stop parents from call their kids' PS5 a nintendo or calling mega blocks legos.
If people can colloquially re-use "Nintendo" to label any game console from Sony/Microsoft/Sega, why is colloquially using "champagne" to describe sparkling wine that's not from France a different scenario?
EDIT to reply: >The point makeitdouble is making is that it’s fine for people to use the term generically, but products shouldn’t use the name generically.[...], but Sony can’t call their next console a “Nintendo”.
The isolated subthread with grandparents (saagarjha, Brybry) that makeitdouble and you are replying in is talking about language usage and not corporations' product branding:
- saagarjha --> "It’s mostly genericized at this point." : https://news.ycombinator.com/item?id=38979031
- Brybry --> "That only matters legally. In actual language usage, [...]" : https://news.ycombinator.com/item?id=38979180
Brybry is actually already agreeing with your Sony example and that comment gets downvoted? Both saagarjha and Brybry have stated correct facts about how language is used in the wild so what exactly are people downvoting? I'm truly confused.
Again, the context of the subthread is language usage and not about breaking France & EU legal rules around "Champagne".
Not just soda. My parents moved to Texas, I visited a bit, and had people ask me if this Coke thing was true. I had no idea... we generally didn't eat out, so I didn't hear what the locals did.
When I was back for Christmas, we were at a restaurant, and I heard the waiter as the table beside ours asking about drinks, so I listened...
Customer: "Can I get a Coke?" Waiter: "What kind of Coke?" (as this point I'm thinking they want clarity on Regular, Diet, Cherry, etc...) Customer: "A lemonade".
That was just weird to me. A Coke is literally ANY drink in Texas.
It's like saying you can't call them brazil nuts unless they were grown in Brazil.
Correct, because red wines produced in Champagne are called something else.
To get to your point though, red wines from Bourgogne are most certainly referred to as "burgundy" and depending on whom you ask, it's always pinot noir (but some will argue Gamay is included). I've noticed that many chefs refer to any good Pinot as a burgundy when dunking it in their stews, and while that's probably okay most of the time when cooking, that generalization is discarding more than just a little nuance for drinkin' wine. A pinot noir grape grown in Oregon can be vastly different than one from France and I will usual skip on the former.
> It's like saying you can't call them brazil nuts unless they were grown in Brazil.
You're attempting to compare an entire culture, craft, and industry of wine to nuts that fall off trees. With things like wine, cheese, and cured meats, there are certainly regional characteristics and traditional techniques that make a product distinct. This designation is to protect consumers and businesses and hurts no one except imposters?
Since that's all too high brow, another more pertinent example may be how everyone from Kentucky knows the limestone in the water makes its whiskey the best in the would. While the US has some laws defining qualities of whiskey, it unfortunately doesn't lay down rules on "terroir". Corn mash isn't quite as expressive as wine grapes, so I can understand the skepticism but many folks swear that the old barns where bourbon whiskey is aged add their own touch.... not so sure about that one.
https://blog.heavenhilldistillery.com/detail.php?post_name=e... https://www.law.cornell.edu/cfr/text/27/5.143
A randomly selected hamburger, frankfurter, or wiener, probably isn't made in Hamburg, Frankfurt, or Vienna.
And sometimes it can get even weirder: Stilton cheese is named after where it was historically sold, but it's made elsewhere and you're not allowed to call a cheese "stilton" if you actually make it in Stilton. (Edit: I originally got Stilton and Cheddar mixed up).
As I'm a British national, I don't know if this is the full reason, or if this is in combination with the natural human tendency to care more about nearby things and that the Atlantic is so big that all of the USA is closer to one of the places called "Champagne" within the USA than to the original in France.
There's no reason that only corporations should get to enjoy trademark protection.
“No one’s gonna tell me that the 1.5 litre bottle of Baby Duck that I drink with my Pizza Hut delivery while watching infomercials isn’t shampane!”
There is a kind of onion called a "Vidalia onion," grown in the town of Vidalia, Georgia. They're a sweeter onion, which is unusual, which is why it grew into a brand.
However, because of this, a lot of people's first exposure with a sweet onion is a Vidalia. But not all sweet onions are Vidalia onions. Yet sometimes people still use "Vidalia" to mean "sweet onion" in a generic sense.
I suspect it's very similar, honestly: I don't think your average American knows that Champagne is a place. Their only exposure to the word is via that style of wine. And so they associate it with the style rather than the brand/region.
(Vidalia onions are also protected legally in the same way that Champagne is; a lot of people in this thread saying that that's just some silly French thing don't realize how common this is. In the onions' case, this has been true since 1989.)
"West Country Farmhouse Cheddar" is protected, but that's quite a mouthful so few people care, and that still only requires you made it in roughly the correct way (you need to use local milk) and in roughly the correct part of the UK (maybe an hour or two drive from Cheddar).
The simple explanation is that nobody in the US really cares about the point of origin — even wine labels are considered more a brand than a location. There is no sense that « terroir » might have any consequence.
Sometimes you encounter food labeled with the state where it was grown or produced — that’s mainly a “buy local” claim, nothing more.
And this where your ununderstanding starts. It is a place name for you. For literally billions of people it's some word describing a type alc. drink first.
So really, congrats to Champagne for making a brand so well known that Wayne’s World can make fun of it and be sure that basically the whole audience will get the joke. I mean that sincerely.
You have to know a little bit about wine to know about Napa Valley. I think “it’s from NaPa Valllleeyyy” in a sort of silly voice is something that somebody might say. It just doesn’t have the reach.
I would think of this as not really making fun of Champagne. We’re making fun of being the kind of person that cares about Champagne.
So I think its less that we think French cuisine is fancy or British food is bad, and more that we don't even really think about British food because a British Christmas dinner is basically the same as an American one (and I've got no clue what a French person would eat for Christmas dinner, so it is exotic and expensive sounding in that respect).
Of course all of this mostly applies to everyone in any anglosphere country. I don't think an Australian would be any more uncomfortable eating a home cooked American meal than an American would be eating a British one.
Which showcases the real issue - it's ok when americans approriate non-american names for things, but not when others do it.
While you are indeed free not to work for Apple (that is what I do!), policies in FAANG companies have significant influence on smaller companies who tend to cargo cult them without much thinking. That is how we end up with leetcode-style interviews, now I'm afraid we all might end up back in office, only even worse one than before where you don't even have assigned table in the open-space.
"If you don't like it, leave!"
Following this advice bolsters bad policies & practices by removing opposition from institutions.
It's noble to stay aboard to fight the good fight. I'm envious of engineers able to take on the risk.
One thing that has always puzzled me is the low quality of a lot of Apple software. Here are some things that tend to happen over and over:
- Desktop applications that block the UI thread and present spinning ball of fail
- OS daemons that consume far more CPU than they should and often get stuck in a state where they consume lots of CPU
- Slow downloads and ultra slow "checking for update" type scenarios
It wouldn't hurt Apple to focus on quality for a couple of years. Both to rewrite a lot of software that doesn't quite perform as it should, as well as laying down some plan for long term quality enhancement.
The stuff that is written in C/C++ and possibly Objective-C today should perhaps be written in Rust. Rust is a pain in the ass to program in, but I do think it is worth it for system software just because it affects so many people when stuff fails. And I suspect a lot of Objective-C code could also be replaced with Swift.
What are you referring to, for specific example? I haven’t had any of the symptoms you list.
https://mjtsai.com/blog/2015/05/27/mac-os-x-10-10-4-replaces...
I reported it to Apple and never heard anything back, as expected.
If you google, you will find others reporting the same misbehavior.
Perhaps there's some protocol mismatch between contactsd and external ldap or whatever they use servers.
I thought of this not because of a cpu core craziness, but a strange symptom i had for many months.
On one of my macs i could see known people only as their phone numbers, and on another mac i saw their names: i had contact syncing settings toggled on/off differently between the two macs, wrt Gmail and Outlook servers (and i didn't realize i'd put any contacts on those servers...thought they were all in MacOS contacts).
At one point, I backed up my ~8,000 contacts and deleted them all. Everything was fine until I restored them.
I found that ObjC made it easy to write spaghetti code if you don't understand the motivations behind ObjC and its SmallTalk-like OO approach, and if you didn't have good rules to follow, and really think hard about the best way to do things.
I feel like too many people came into ObjC trying to just use it like Java or Python.
The dynamic-ness of it can quickly get out of control, event handling was verbose and tangled.
I feel like ObjC was missing a proper SmallTalk environment to tame it.
I think ObjC caused a lot of this bad software. Race conditions, state management bugs, logic bugs, etc.
But on the flip-side the compiled nature of it allowed things to be fast when they needed to be.
Swift Playground was a good sign of Apple drawing on its SmallTalk roots, but at the same time entirely abandoning the SmallTalk OO approach.
I find Swift a bit of a boring language. It's just a new compiled language with some fun and quirky syntax choices. There doesn't seem to be any brave new philosophy or new ideas behind it.
Apple software quality has declined significantly from the Objective-C era to the Swift era; but that actually has nothing to do with the programming language and everything to do with the forced march yearly release schedule and the lack of caring about quality by current Apple leadership.
No.
> Remember how bad iTunes was?
Yes, but I would kill to get iTunes back now, because it was much better than Music app, which is absolute garbage.
> Finder is still prone to spinning ball of fail - it used to be worse.
I find Finder to be worse now, and slower. I'm not talking about the spinning beachball, I'm talking about normal operations such as sorting folders, copying and moving files, emptying the trash, etc. This is despite the fact that the hardware is faster than ever!
I wanted to move my default library file from one drive to another and I waited 3 days for it to never finish. Seems like it had to update every single file in the database. It doesn't make sense that it needed to do anything at all really.
In iTunes if I clicked on a file that no longer existed, it would lock up and come back after a minute each time with a dialog saying it doesn't exist.
The first IDE vendors for Java, were doing Smalltalk.
So the Java critic is kind of ironic.
And Java interfaces were taken from ObjC protocols.
I think its sad though that this entire lineage while being inspired by SmallTalk, seemed to miss the whole point of SmallTalk. The always-running virtual machine was an essential part of it. And a good IDE and tooling is needed to help deal with such a dynamic language. But I think a lot of people just ended up treating it like C with a quirky syntax.
https://cs.gmu.edu/~sean/stuff/java-objc.html
https://en.m.wikipedia.org/wiki/Distributed_Objects_Everywhe...
You see a bit of Smalltalk image heritage of Eclipse workspaces, basically a way to turn files into a virtual image. Eclipse still has the Smalltalk code navigation from its Visual Age for Smalltalk roots.
The way JMX, Java agents and dynamic code reloading works, as well.
.NET also inherited many of this due to the way it came to be.
If someone found a rust binary somewhere on a macOS install I’d be super interested.
I'm pretty sure if Jetbrains somehow gets acquired by Google, Kotlin will reach greater heights than Swift.
I personally think Jetbrains getting acquired would be a nightmare. JB is very responsive and accessible when you have an issue with their libraries (Of which I've found many). Google is an impenetrable super-corp and they already endorse Kotlin heavily for Android development.
What's more in typical Google fashion, this would inevitably spell the death of Compose Multiplatform UI or Flutter when a higher-up learned they were paying for two competing solutions. Flutter has more users, so Compose would join the graveyard.
Best I can tell no one really uses Swift for anything other than desktop/ios apps. Kotlin is only gaining traction in industry on the backend. I don't really know how relevant Tiobe indices are, but I would expect Kotlin to overtake Swift in a year or two.
I would love if more folks would ship Swift backends, but JVM folks moving from Java to Kotlin is a natural progression and I don't see Swift closing that gap
1. Google has multiple in house languages already. They somehow haven’t made them work well together.
2. Google already tried their hand at Swift when Lattner was there. It was really cool, but died on the vine.
3. Google is very easily distracted and will kill off things that aren’t critical or bringing in enough new customers.
I like my Jetbrains IDEs to want a company as poorly managed as Google take it over. Their offerings would quickly be killed off in the name of “unifying them” and then suddenly that one solution will die as well for anything except for Android Java.
The fact that you can log an issue on their public tracker for any product, and some human is triaging this instantly.
That said, I don't disagree that if Google backed it properly (seems unlikely now, considering they just fired the guy who led Guava/Guice, for example), it would do really well.
But can’t swing Cupertino :(
Another problem is C++ template. Oh boy that thing is semi-decidable on its own.
Besides that, you have small things like ADL [1] and SFINAE plus the new C++ concepts...
That's why after learning C++17, I decided to give up and switch to Rust.
I'm not sure why is everybody so after C++. I don't care about sunk cost, and I just want the best of the best. Easy to implement the parser, easily make a compiler for it. I like those languages.
[1]: https://en.wikipedia.org/wiki/Argument-dependent_name_lookup
That is somebody else's headache, namely compiler developers. As a user I am totally happy with C++. It lets me do what I want to do without much fuzz and has enough features to be ergonomic. Sure I would never know it completely but who says I need it? It absolutely does not preclude me from being productive.
Not everybody; those who have tons and tons of existing C/C++ code, want to move away from it, and realize the only way to do that is gradually.
Swift’s C++ interop makes it possible to add a Swift class to an existing C++ code base and have code from either language call into the other, mostly without having to copy or convert function arguments.
You can write Swift functions that work with C++ std::string today, for example, gradually replace all code using it by Swift code, and then change the type of the value to Swift’s string. Easy? No, but easier than a ‘big bang’ rewrite.
A somewhat more playful approach might be to complete the 2019 edition of Advent of Code [2], where you'll learn some preliminaries while implementing the Intcode interpreter.
[1] https://online.stanford.edu/courses/soe-ycscs1-compilers
Then you should get a copy of Modern Compiler implementation in ML. I love the Crafting Interpreters book, and also the Writing A Compiler In Go book; but they will not satisfy any person with undergraduate CS education.
From memory (because I left my copy of the Dragon book in another country) the book describes very well the first stages of compiler construction, describing the fundamentals of what Lex/Flex and Yacc/Bison do.
Right now for a compiler I'm writing I have used the Crafting Interpreters book and find it very useful. It's basic but can carry you through a project, and a decent reference for someone who took a Compiler Construction course about 20 years ago.
All of the front-end parsing stuff is good, but heavily biased toward LALR parsing, which is rarely used in production compilers these days because it’s really hard to get good error messaging. There’s also a lot of tooling that can help these days.
But where it really falls down is the backend part. Parsing is just not where you’ll spend most of your time. Once you parse you usually need to translate the parse tree (often an AST but not always) into some other representation.
I found the Appel books (Modern Compiler Implementation in <language>) to be much better at that part. I still own a Dragon book (an older one), but tend to refer to my Appel book a lot more when working on compiler-y things.
# Learning Resources
## Theory
Take a look at these two books:
- Crafting Interpreters[2]. Compilers and interpreters have a lot in common and the book is exceptionally beginner-friendly. Basically, this is the perfect one to get started with.
- Introduction to Compilers and Language Design[3]. Doesn’t assume any preexisting compilers knowledge, and teaches all the basics necessary to build a compiler using a hands-down approach. The examples are in C.
Ignore the classics textbooks like the Dragon Book or "Modern Compiler Implementation" for the time. You can always come back to them later if you want to.
## Source code
Explore the sources of
- 8cc[4]. A compiler for the C programming language. It's intended to support all C11 language features while keeping the code as small and simple as possible.
- chibicc[5]. The successor of 8cc from the same author.
If you want a bit of background on these two compilers, check out the author's blog post "How I wrote a self-hosting C compiler in 40 days"[6]. Personally, I find it to be quite a fascinating read.
# Input language
Don’t try to come up with your own language just yet. Go with an existing educational language instead, and focus on learning about compilers. ChocoPy[7] is specifically designed for classroom use in compiler courses and by extension is great for a hobby compiler project.
# Target language
Many educational compilers emit MIPS assembly. Although it's possible to run it using an emulator, running a native executable produced by your own compiler feels much more rewarding. So I'd suggest your compiler emits x86-64 assembly.
For educational purposes, I'd avoid targeting languages such as LLVM IR or C. Emitting assembly helps understand many important concepts better:
- Managing a function's stack frame
- Calling conventions
- Finding the memory address of an identifier
- Converting expressions into assembly
- And so on and so forth.
[1]: https://mykolam.net/posts/toy-compiler-of-scala-subset/2-loo...
[2]: https://craftinginterpreters.com/contents.html
[3]: https://www3.nd.edu/~dthain/compilerbook/
[4]: https://github.com/rui314/8cc
[5]: https://github.com/rui314/chibicc
[6]: https://www.sigbus.info/how-i-wrote-a-self-hosting-c-compile...
[7]: https://chocopy.org/
The base does have a quite wide range, I assume that's the range for a few different levels. Still, you are roughly looking at a TC starting from $230k all the way up to $400k and more.
"Niche space and serious talent" doesn't necessarily translate to higher levels or salary in a company. It all comes down to how much resource an organization has. (I wish my employer actually understood how "valuable" I am and that I achieved things very few in my company could do, but I am not betting on that or the company.)
All other comments here are useless and a waste of your time.
If the talent is too niche, however, the buyer might lowball the seller because they predict the seller will not be able to find a better offer.
(EDIT: Removed a lot of extra verbiage explaining TC vs. base pay, which — thanks to the comment below — I'm realizing everyone probably already knows.)
I was asking about TC in this particular instance given the following:
1. I have never worked for Apple (but I interviewed at big US companies for remote roles, and got to the TC negotiating round with a couple of big techs).
2. THis is a very niche role and requires very niche expertise and lots of experience.
3. The current state of the industry and how it has impacted comp at big tech like Apple.
I was hoping for a better insigh given all the above, not how TC works at big tech.
If you ever watch talks from folks like Dave A. Who wrote the stdlib, he says he only ever uses arc types as a mechanism to enforce COW for the stdlib types and containers.
I think Apple’s always cared about ease of development over the possibility of bare metal optimization - after all, Objective-C was built on dynamic dispatch, and libraries as important Cocoa/AppKit and Apple’s compositors aren’t going to ditch that soon.
And, because of C++’s scars and warts, I don’t see Apple ever valuing stable codebases over Apple’s ruthless deprecation habits when it comes to change and development.
Instead, I’m convinced it’s really to help people trying to port games to macOS; it’s unusual for Apple to ever invest in an ecosystem of porting from different platforms, but here we are.
It’s binary compatibility that Apple doesn’t care about.
I would disagree.
Apple avoided managed runtimes this whole time and made people think about memory safety a lot compared with Java/C#. Programming was not as easy as it could have been.
It has also always been trivial to fallback to C/C++, and the interop story with ObjC code is a lot cleaner.
I think the driver for this was because they highly valued a buttery smooth UI, and this requires a lot of bare metal optimization.
The ObjC runtime is just a library that is linked in. It's much easier to drop down to the metal when you need to.
> automatic resource management
ARC is not runtime-based.
ARC is definitely runtime based, go read the easily available machine code doing retain / release message calls, when the compiler isn't able to ellide them.
You also forgot the remaining capabilities of Objective-C runtime regarding plugins, and metaclasses.
This is not relevant to system programming. It's actually anti-relevant, as your #1 job is to be small and stay out of the way of the app code. And your #0 job is to not crash or have security holes.
what's the point :o
> The average Cupertino home value is $2,663,389
I'm sorry wtf?
I don’t think that’s much of a thing any more, not just in the Bay Area.
Who would accept this role??
Now you know how us European devs feel like in ragrds to wage/housing prices.
Come to Austria and see. Same in Germany I think. A mate from Stuggarts has no idea how house prices are justified there looking at his wage.
>Northern Europe salary is more than enough to afford local housing.
Where exactly in Northern Europe? I heard the Finnish countryside is very affordable. If you can stomach the weather and isolation.
This probably also means it's not a great investment to buy property there.
There is also the option to live near Vienna and commute by trains.
Rent controlled public housing are only for Vienese or long term resisdents of Vienna. I am neither.
>you can rent a place for like 500€ monthly
Hahah, no you can't, not even close on the private market, in 2024. Maybe during the pandemic you could when travel was frozen and the rental market crashed.
>This probably also means it's not a great investment to buy property there.
It is. That's why prices are kept so high, so those who own stay wealthy. I don't want a house for an investment tho, just a place to live.
https://housinganywhere.com/room/ut902932/at/Vienna/marktgas...
Not in the UK.
Still tight though.
In short, parent comment got it wrong, tech in London doesn’t pay you £300-400K/year.
and once you’ve taken public holidays and leave into account, it’s closer to 200k
Obviously the range I gave goes all the way from junior engineer to CTO, is in USD, and reflects pay at top institutions.
With Swift language bindings it would be quite smooth to work towards.
Key Qualifications: Ability to write safe and high performing code with C/C++
The entire reason swift exists? Because safe and fast code code in C or C++ is not a thing.
I'm curious whether their swift compiler is written in swift yet. It seems like that would be a good idea but in direct tension with C++ interop which would be very tempting to do by hacking on clang (which is not written in swift).
I wouldn't generally mention that (it's in the "sky is blue" class of interest). That a swift compiler role had this in the prereq struck me as hilarious.