I love how Apple has somewhat come full circle on C++. There was a time they somewhat shunned the language publicly and highly discouraged anyone from using it in apps. A lot changed a few years ago when they started dedicating WWDC sessions to new C++ language features. Really triggered my geek zone. That they are working hard to bridge these two languages is really good news and benefits everyone.
They definitely have opened some things up, like a full C++ interface to Metal. I think the idea with this current effort is kind of the opposite though - not to encourage more use of C++, but to start writing new features of C++ projects in Swift (the presenter at the C++ Now 2023 talk [1] goes into this). I expect WebKit is a big target for them, I think they eventually want to replace all their C++ with Swift gradually (instead of trying to do ground-up rewrites, where you dedicate a team to doing that for years and you have a replacement at the end with fewer features than the old project).
> 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.
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,...
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.
My impression is that Metal was a massive that succeeded because it was limited in scope to Apple platforms. It then put a bunch of pressure on Kronos to push out Vulkan. Prior to Metal, we thought that the future of OpenGL was newer versions of OpenGL.
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.
Yes, Mantle is older. But after Mantle came out, my impression is that the OpenGL committee intended to deliver a new version of OpenGL, rather than rewrite it.
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.
As an aside, I do find it funny to think about presenting “successor languages” in a con that’s meant to showcase the vitality of the current languages. Call it CppNotForever, maybe.
Ultimately all of these conferences are for people. Languages don't attend conferences.
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.
Since switching to Clang more than 10 years ago, Objective-C, C++ and Swift are first-class citizens in the Apple development environment. You can mix Objective-C and C++ in mm files and it's a smooth experience in general. The actual language becomes less relevant when you have the same backend.
Interesting how they started to do the same as Microsoft did back then - use the API from every language that matters and what Microsoft wanted to matter more.
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 first class on Apple platforms. The main APIs are only in Swift or ObjC. You can use C++ in your app, but you will need an actual first-class language to interact with the OS and UI.
Well that’s a completely false statement. C++ is a first class language, and all C++ APIs and ABIs are stable. It is used extensively across macOS and iOS, and has large amounts of support through out the apple provided dev tools. Significant improvements to the C++ UX were part of the motivation for clang.
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)
>Well that’s a completely false statement. C++ is a first class language,
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/
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.
Yes, it's not a first class language, but the parent explained why it can't be. If you tried to implement a dynamic library with a C++ interface, you can't add virtual functions to later versions of the library without breaking any clients that derive from those classes. You'd have to recompile all apps any time you made a change to the OS.
You can create new projects in C++, you can't create new projects using UI Cocoa, UIKit, or SwiftUI in C++ because those APIs are not in C++, because C++ is generally bad as a language for APIs where ABI stability is important, but also seems to be particularly bad as a language for UI programming in general. The specific combination you get in Cocoa and UIKit is dynamic binding (requiring reflection) and developer subclassing of UI objects (causing aforementioned brittle ABI problems).
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.
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 write plenty of Mac and iOS programs - and much of the OS, and even XNU are - in 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
It is annoying that apple-clang is so behind the curve on C++. I like to use C++20 features and even some C++23 features but either have to avoid them or use conditional compilation for apple-clang compiles.
It still is shunned. The only reason to use it is for compatability with existing code. Any new code written in C++ is already deprecated and will be an attack vector.
No surprise. Apple likely wants to run LLMs on their devices and provide developers with the possibility to create iOS apps using that. C++ is essential in that sense.
I wouldn’t be surprised if it was for other drivers, actually, especially since Apple’s really pushing cross-OS user space drivers, and why not use the opportunity to do 2 tech refreshes? If Apple’s trying to push iPadOS drivers to make the iPad a “real computer”, why not lower the barrier to entry?
Article says "The base pay range for this role is between $138,900 and $256,500, and your base pay will depend on your skills, qualifications, experience, and location."
Thanks, but I wasn't asking about base pay, that's pretty much fixed depending on which level you end up hired at. I was asking about Total Comp given this is a very niche space and serious talent with experience usually commands significant TC and I was wondering how far Apple goes to attract such talent (especially given the current state of the industry, with layoffs and all).
I doubt they’re offering any more for this position than other software engineering positions at a similar level. You can roughly double the base salary number to get TC including stock and bonus. If Chris Lattner decides he wants to return to Apple they might make an exception though.
I hired compiler engineers among others during my career at multiple companies in Silicon Valley. I usually managed to get extra compensation but not always. It's a small pool of developers. Eventually, we hired mostly in other countries.
Go to levels.fyi, search Apple, then look for salary that is for a similar position and has a similar base. That's a starting point.
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.
Huge amount of resource can also mean they can wait for talent for right price. They'd rather have 20 engineers for right price than 4 superstars demanding 40% increase every year else threatening to leave.
It is niche skills with niche demand and only niche companies have jobs for it. For people really looking to make money maybe moving to Salesforce CRM consulting can pay more.
It’s mostly genericized at this point. You can get a Philly cheesesteak all over the US, for example. Maybe it’s not as authentic as something from Pennsylvania but being pedantic about it is a little snobby.
Philly cheesesteak has never been about Philly grown meat and Philly grown cheese though. French also won't be fighting to have "Paris-Brest" region protected for instance.
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.
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.
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.
>The rules are different for official product names though.
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:
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".
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. So a parent might call a PS5 a “Nintendo”, but Sony can’t call their next console a “Nintendo”. The same applies to champagne. People can call sparkling white wine “champagne”, but companies producing sparkling white wine should be able to call their products “champagne” unless it is actually from Champagne.
> 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.
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.
In English, champagne isn't wine from a specific location, it's a specific type of wine. People aren't going to call red wine grown from the place champagne.
It's like saying you can't call them brazil nuts unless they were grown in Brazil.
> People aren't going to call red wine grown from the place champagne.
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.
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.
It's quite common in the EU. Names such as cognac, port, and parmesan are protected, and you can only use them for products made using the traditional process in the traditional region.
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.)
Cheddar isn't a Protected Designation. So, if you want to make Cheddar in Swansea? No problem. Edinburgh? No problem. Dublin? Pretoria? Atlanta? Christchurch? All fine.
"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).
Perspective: live in the USA, from Australia (where the “locale” mentality is the same as USA), lived for years in France. So I understand both sides.
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.
We generally mock wine-snobbery. There’s some element of stereotyping French things as pretentious. But mostly it is because that’s the brand of wine that is known by everybody to be fancy. (Hey, stereotyping is bad, but on the other hand we don’t mistake any British food for fancy, so at least there’s some begrudging respect built into the stereotype).
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.
The British food thing is I think less about respect or fanciness and more familiarity. American staples tend to have similar ratios of various nutrient groups, often without even as much as a substitute. American "home-style" cooking is almost identical in a lot of respects, if we ignore regional variations in both countries.
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.
I think the issue with Champagne is that in the USA we used the word as a generic term for sparkling wine for MANY decades before it became a Designated Appellation. Bottles were sold here using the word champagne only to indicate it was sparkling wine.
Because that's Apple. Just like how they forces everyone to come in office three days a week. Not every company does that -- some big companies are still quite flexible with full remote work. But this is Apple.
It's confusing that folks are upset about this. If it doesn't work for you, don't work for Apple. It's like complaining about the neighbor who bakes great apple pies also happens to not let their children play video games. The children may be upset by why would you be?
> It's confusing that folks are upset about this. If it doesn't work for you, don't work for Apple.
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.
Not everyone wants to work on a distributed team. I happen to and it works for me, but I have been much happier in the past when my entire team was colocated in the same office. There is no right or wrong choice here, simply different choices made for different teams/companies. Find the one that works for you and ignore the rest.
Apple have compiler engineers who aren't at that site. Maybe they're currently only hiring for that one area, more likely it's divergence between what HR wrote down and reality.
>The position is based onsite at Apple's campus in Cupertino, California. International candidates are welcome to apply but will need to relocate; the company will sponsor a visa.
Rule of thumb for home affordability would still price the person out of that home, even at 400k/yr. Meanwhile, the median home price in the country as a whole is 350-400k these days. SV has priced out even their senior engineers, which does seem like an issue for hiring.
Mean average home price in the city of Cupertino is not a useful statistic to determine if someone is priced out of a job located in Cupertino. There are lower priced areas that are within commuting distances acceptable to sufficient people, plus dual income couples.
The median home price for the SF Bay Area is roughly $1.4M -- that means this sort of role is the bottom of who could afford a home alone. Making half as much money somewhere else is likely going to provide a higher quality of life than barely being able to break into the Bay Area housing market and potentially needing a long commute to your "desirable" job. This was not the case for the previous generations of engineers moving to the Bay Area.
Incorrect, as common sense would dictate lots of people who work at Apple live close by the office (homes aren’t the only option, there is a thing called renting)
I recently got approved for a mortgage with a mainstream lender where they took unvested stock into account for the pre-approval. Thankfully I'm not reliant on that stock vesting to pay the mortgage. As I understand there are quite a few lenders that will do this.
“Total compensation” usually refers to base salary together with your yearly bonus and vested stock. Mortgage lenders will typically look at your W2 income which includes the bonus and stock.
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.
Plus another 500€ monthly for gas and electricity written in the fine print, when I only pay 100€, bringing your monthly rent to 1100€, which is closer to the private market value of such a property.
The higher end is always the highest you are currently being offered. No point in fantasizing over fictional numbers that you're 99% unlikely to get in order to be unrealistically optimistic with yourself and your financial planning. It's why average/median pay is important.
10x-15x gross income to house price ratio seems pretty much spot on. A dev will earn 50-80k here (taxes are going to be ~40% or so) and a SFH in the area will cost 600-1000k.
£1000/day is still “just” around £250K/year, and at this daily rate you won’t have it easy as a contractor. Highly paid gigs are not as plentiful, are normally shorter, and require very active search and sales work. You always need to find your next similar consulting gig quickly once your current one is over — every day of downtime or non-billable work between gigs costs you £1000!
In short, parent comment got it wrong, tech in London doesn’t pay you £300-400K/year.
I wonder how can people throw around such fantasy numbers with a straight face as if anyone can easy get them with a bit of work and elbow grease. I don't doubt he's making that kind of money but it would be nice to not push cases of obvious survivorship bias as being the norm.
Reality? Reality needs some proof or sources mate. Can you provide any of those for your claims? Because otherwise online everyone is the crown prince of Arabia, over 6ft tall and 12 inches uncut.
You wouldn’t have a job ad link would you? Give me a generic description of any 300K+ position you know of? I will understand whether it’s real. Something like “Business-side director level position on a trading floor in a multinational investment bank” (those people don’t make 300K, this is just an example).
Not as a base salary, no. They would have a performance bonus (you’ll keep a percentage of your trading income done via firm), but even then making £300-400K/year is… challenging
Interesting that it looks like just a regular "Senior Engineer" type job from the numbers; that looks like the pay band they'd put up for any ol' software-engineering job, regardless of specialization.
(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.)
This is common knowledge. I'm one of the comments asking about TC, but I'm aware of all you've outlined, most people on HN have gone through negotiations before.
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.
Some really smart people working on Swift, and the C++ interop is a dark art (although was missing some critical features like virtual message dispatch and support for std::function from blocks last time I looked).
FWIW there’s been plenty of C++ in macOS since the start, eg. Security.framework.
C++ makes people disgusted, from iostreams to meta-templates
that slow-down compilation to a crawl. Its natural they wanted
to replace C++ with something, but turns out the big bad C++
optimizes to better code and Swift isn't that great.
Perhaps instead of inventing C/C++ replacement language,
its better to invest in improving C/C++ standards/libraries and
APIs. Forcing developers to adopt Swift/Dart/.NET and framework
of the month doesn't magically create an ecosystem of new software,
it only appears when developers are maintaining something long-term
that doesn't rely on whims of company or the current trend.
Swift is a beautified and pythonified Objective-C without the dynamic dispatch. It uses the same ARC memory model. C++ doesn't lock you to a particular memory management scheme. You can program with raw pointers like it's 1998, or entirely use post-C++11 value-semantic objects without touching new and delete.
This is only partly correct. It’s generally encouraged to use value types (or the up coming move only types) unless you actually want the reference semantics or you are interoping with objc apis on Darwin.
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.
Can I provide an alternative interpretation? I don’t think caring about fast fast fast performance, or legacy codebases, is really in Apple’s DNA
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.
To add to this, getting an abandoned mid-00s Mac app project compiling and running usually isn’t too bad, actually. Yeah you’ll have deprecation warnings left and right but it’ll run fine anyway, at which point fixing the deprecations can be done at one’s leisure.
It’s binary compatibility that Apple doesn’t care about.
> I think Apple’s always cared about ease of development over the possibility of bare metal optimization
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.
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.
Thinking that C++ "optimizes to better code" or that compiling to faster bigger code is even the right thing to do is the mark of an app developer.
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.
On maybe slightly off topic point. I really want to learn more about compiler engineering, what people would suggest for someone with some background in programming but main background is physics (if that matters at all)?
The field is called "compiler design". Consider taking a course [1] or buying a book?
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.
For a start you should, you should buy the latest version of the Dragon Book and then put it on the shelf.
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.
For a contrary point of view, I don’t think the Dragon book actually holds up that well.
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.
I work on a reimplementation of MLIR in Python called xDSL, and ported a part of MLIR's Toy tutorial, you can try it interactively online at xdsl.dev/notebooks, or by cloning the github repo and running them locally github.com/xdslproject/xdsl
- 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:
Given the various claims set forth in the discussion, one thing that would be very useful would be a map of what's written in what language. From what languages are used in Apple's desptop apps, iOS, watchOS apps etc to what is used in those pesky macOS daemons. You know, the one where a new daemon decides to blow up every release and consume enormous amounts of CPU.
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.
Not those exact symptoms, but Apple replaced mDNSResponder with discoveryd then gave up and went back to mDNSResponder because they couldn’t get discoveryd stable:
It’s pretty wild, considering that I haven’t had any of those issues and I’m on Apple stuff continually all the way back to next step days. I guess I’ve just had good luck in comparison.
I am certain that it is because I have a large address book and one or more cards exposed a bug. I expect that people with simpler address books (almost all users) never saw this.
I reported it to Apple and never heard anything back, as expected.
If you google, you will find others reporting the same misbehavior.
Have you tried turning off syncing of contacts with Gmail accounts/Outlook/Exchange servers, just as an experiment?
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).
I was not synchronizing with anything but iCloud. Before the recent update that fixed it, I was in the habit of disabling WiFi when on battery so that my laptop would not drain my battery. contactsd definitely was doing something dumb around synchronization.
At one point, I backed up my ~8,000 contacts and deleted them all. Everything was fine until I restored them.
Three examples are powerd, bluetoothd, and more recently CalendarAgent. CalendarAgent spending 100% CPU syncing a calendar that has almost no entries is...astonishing. For powerd and bluetoothd I eventually wrote a program to keep an eye on them and terminate them if they use close to 100% CPU for more than a minute or so.
Thanks for the examples. It’s very interesting that it happens to someone that others and I haven’t had that happen to me, but I believe you. It would be really interesting to know, once the issue is fixed, in some future release, what triggered it for some people and not others.
I agree that Apple has a lot of low-quality software.
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.
> I think ObjC caused a lot of this bad software. Race conditions, state management bugs, logic bugs, etc.
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.
I'm not entirely sure. Remember the frequent spinning ball of fail that you'd get from any apple software? Remember how bad iTunes was? And while Finder is still prone to spinning ball of fail - it used to be worse.
> Remember the frequent spinning ball of fail that you'd get from any apple software?
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.
Java was inspired by Objective-C experience at Sun, many of its features are inspired in Objective-C, and Java EE was originally a Objective-C framework, Distributed Objects Everywhere.
The first IDE vendors for Java, were doing Smalltalk.
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.
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.
I don't know that Rust would solve the issues you mentioned. It's great for fixing memory errors, and making it hard to make logical mistakes where you forget to handle a particular case. But it doesn't do much to stop deadlocks, quadratic algorithms, or 'scheduling' type mistakes where a thread gets into an asynchronously reptitive loop.
So how would you like to represent a vtable in Swift today? I mean down to the specific compiler implementation details. In GCC, Clang, MSVC they all both have different behaviors with different situations, such as virtual destructors, multiple inheritance and POD paddings.
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.
>"Easy to implement the parser, easily make a compiler for it."
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.
Since a lot of people are discussing Apple’s plans to replace C/C++ in performance critical areas, I’m curious to discuss it. How do they plan to make Swift actually match those languages in speed? Last I checked, classes, along with fundamental struct types like Array and String, use atomic reference counting. Do they plan to ban all those types in these systems? Are there any highly performance sensitive and C/C++ Apple systems (not just libraries) that have been rewritten in Swift without a drop in speed? The rewrite of the Swift compiler from C++ to Swift is an example of where rewriting is occurring but where there’s a non trivial performance loss as a result.
A lot of work is going into move only types for swift to avoid the need of ARC in fundamental types like you mentioned. Classes aren’t going away but Apple is trying to evolve the language to cater to various performance needs.
I think you mean automatic reference counting (ARC) — and ARC happens at compile time as part of a static analysis pass. (The compiler is basically adding retain/release code for you.)
At runtime, it’s functionally close(ish) to malloc/free and doesn’t carry much overhead.
In my understanding, it’s both: you’re right about Automatic Reference Counting (ARC) being a compile time pass. But the reference counts that they use for said retain/release are atomic reference counted (ARC).
ARC certainly helps ARC be more performant than ARC without ARC due to the elided traffic on the count. (lol)
So, the buildin stdlib types afaict use arc only to figure out if the instance has a single unique reference. Internally it is a value type. If a variable on one of these types is modified then the existence of more than one reference is used to do a deep copy of the internal value type.
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.
> The rewrite of the Swift compiler from C++ to Swift is an example of where rewriting is occurring but where there’s a non trivial performance loss as a result.
Citation needed on the performance loss. So far only a handful of SIL optimizer passes have been rewritten in Swift.
It's surprising that Jetbrains/Kotlin which neither owns a platform, nor is in the mainstream runtime business like Oracle - managed to build an "extremely" multiplatform language with excellent interoperability with other languages (Java/ C++/ JS/ Swift)!
I'm pretty sure if Jetbrains somehow gets acquired by Google, Kotlin will reach greater heights than Swift.
I agree it's awesome. There was a strangle loop talk on the economics of creating a programming language; Kotlin is really the first of its kind being supported by an editor licensing program.
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.
Swift Vapor is really nice but Kotlin is way better supported, the DSL available for writing HTML using Ktor is much nicer than those available for Swift, for example.
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.
I like both Kotlin and Swift but much prefer Swift as a language.
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.
That "if" is doing a lot of heavy lifting, when a company like Google is in context. They are an efficient pipeline for sending cool technologies to the graveyard if there ever was one.
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).
Just because a compiler cannot prove whether or not a given set of C/C++ is safe, doesn’t mean that an expert in the language can’t write safe C++ and prove that it is actually safe.
Counterexample: All C++ in production. See also, existence of rust, swift, zig - literally all the "fast but not as crazy unsafe as C++" design space.
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.
246 comments
[ 3.0 ms ] story [ 254 ms ] thread1. https://www.youtube.com/watch?v=lgivCGdmFrw
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://youtu.be/ZQc9-seU-5k?si=t8Ohv7M51UNuDqgx
With Swift language bindings it would be quite smooth to work towards.
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.
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.
“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.
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.
(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.
FWIW there’s been plenty of C++ in macOS since the start, eg. Security.framework.
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.
https://youtu.be/lgivCGdmFrw
https://www.youtube.com/watch?v=ZQc9-seU-5k
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
[2] https://adventofcode.com/2019
https://craftinginterpreters.com/
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.
[0]: https://llvm.org/docs/tutorial/
# 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/
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.
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.
1. https://youtu.be/tzt36EGKEZo?si=N_dm8K_d852t6wY6
https://dlang.org/spec/cpp_interface.html
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.
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.
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.
But can’t swing Cupertino :(