I don't think it's controversial or unsurprising at all that a company doesn't want their random sentence generator to spit out 'brand damaging' sentences. You know the field day media would have Apple's new feature summarises a text message as "Jane thinks Anthony Albanese should die".
When the choice is between 1. "avoid tarnishing my own brand" and 2. "doing what the user requested," corporations will always choose option 1. Who is this software supposed to be serving, anyway?
I'm surprised MS Office still allows me to type "Microsoft can go suck a dick" into a document and Apple's Pages app still allows me to type "Apple are hypocritical jerks." I wonder how long until that won't be the case...
But so often these tools are used in a way that the user didn't explicitly request, like summarising notifications, or generating slideshows from your photo library.
In TS you get literals, which is its own dimension of valuable tooling of course.
So inferring as an untagged union is not wrong of course! It's just that if you are always inferring the type of an if expression to A | B, then this will also happen unintentionally a lot.
And so at the end of some code, when you actually use x, then you'll see an error like "expected usize, got usize | bool". In the case that this was a mistake, you're now looking at having to manually figure out why x was inferred this way.
In typescript your "if expression" is a ternary expression. Those are quite rare. In rust they're all over the place. Match statements are the same thing. Imagine having a 10 clause match statement and one of them unintentionally gives a different type. There's even just the classic "semicolon makes the branch into a ()"!
So always inferring a union across branches of an if expression or a match means that your type errors on genuine mistakes are almost never in the right spot.
Of course we can annotate intermediate values to find our way back. Annotating intermediate values in a chained expression is a bit miserable, but it is what it is.
Decent typescript tends to not have this problem because there are few syntactic structures where you need to evaluate multiple branches to figure out the type of an expression. And the one big example (return values)... well you want to be annotating the return value of your functions in general.
Rust is in a similar space for Result types, at least. But I don't think it generalizes at all. If you start inferring union types, and combine that with trait resolution, I _think_ that we'd end up with much less helpful error messages in the case of actual mistakes, because the actual location of the error will be harder to find.
let mut x = if some_condition { 1 } else { false }
// bunch of code
return f(x) // expected usize, got usize | bool
TS gets away with this stuff because JS's object model is simple (TS doesn't need to do any form of trait resolution!) and the opportunities to introduce unions implicitly are relatively few in TS code in general.
And this isn't even really getting into Rust needing to actually implement untagged unions if they had them! Implicit tagging feels off in a language very serious about not having expensive hidden abstractions. But how are you going to guarantee bit layout to allow for the differentiation here?
I'm saying all of this but I'd love it if someone showed up with a good untagged union proposal to Rust, because I _like_ the concept. Just feels intractable
Was this a targeted ad? Apple doesn't openly attack Ads - they are actively hostile to privacy invasive technology, which I don't think this runs foul of.
The problem isn't that Apple has ads, it's that Apple pushed an ad through Wallet. And in the Settings app. And in all the other untasteful places they spam with these ads.
Some people received the ad, while others did not (I did not). I don't think we fully understand what has caused some people to receive the ad versus not; maybe its just simple probability, or maybe its something more personal like usage of the Apple TV app, active TV+ subscription, having movie theater apps installed, or search interest in F1.
Will there actually be any short, mediumm, or long term consequences for Apple? What real, tangible trust has Apple lost that could lead to meaningful harm to them?
The only thing I can come up with is people who hold Apple to some kind of high-minded ideal, that they constantly run foul of for other reasons already.
Threads like this one are a short-term consequence for Apple.
People here, discussing it, a) demonstrate that they find the act to represent a breach of trust, and b) spread that understanding and opinion among those who read it.
That's not, in itself, a direct consequence for Apple, but it is something they need to be, and I genuinely believe are, worried about, because losing trust in them is precisely the kind of thing that will get people to stop buying their products. This is especially true given the way they've positioned themselves as a more trustworthy actor in the privacy field.
Apple does a lot of things that are not allowed by any of the 3p developers. Someone like EU could look at that (for instance in this case a direct to consumer marketing channel that they are using to favor their own properties) and say it violates the DMA.
Google is being forced to take Google Flights links out of Search results, for instance.
Apple’s behind of curve of its third party ecosystem. All of the apps on the App Store send spam notifications, violating Apple’s own guidelines that it has no intention of enforcing.
He’s probably more right than not. But he also has a vested interest in this (just like the other CEOs who say the opposite), being in the business of human-mediated code.
Presumably you're aware that the full name of Microsoft's Copilot AI code authoring tool is "GitHub Copilot", that GitHub developed it, and that he runs GitHub.
reply