tomnipotent

and I believe it was premeditated

So in other words you're just vibing conspiracy theories and will believe whatever makes you feel better.

The only example of thin skin I see is the character assassination attempts and petty attacks by the Zig team.

There's literally nothing in that post of substance, other than the fact the Zig community is obsessed with trying to "prove him wrong" or some other such nonsense. Jarred's responses have been composed and civil, while the Zig team has been petty and vindictive.

perpetually offended snowflakes

This attitude is so precious to me - "Sorry guys, you can't criticize my criticism."

What Bun did here is basically a sabotage of Zig's reputation

If Zig's reputation was so fragile that Bun migrating to Rust caused this kerfuffle, then Bun isn't the issue.

It this a joke? Your example of Jarred starting fights in public is announcing fork then pointing to a thread where he didn't even participate but rather where members of the Zig community are slinging mud?

unrequested fork

No such thing exists.

have public fights with the language maintainers

Can you point to even one such example?

Andrew decided to attack the person rather than ideas and positions. It's not a reflexive revulsion, it's an appropriately sized reaction to a blog post in poor taste.

not having any morals

You don't agree with someone so you claim they have no morals. I don't have words for how stupid this is that anyone can so casually dehumanize someone over something so trivial.

What points? All I'm reading is just a collection of emotional ad-hominems.

No they haven't. It's been said time and time again that their teams were struggling with large JS code bases for Bing Maps and O365 web apps.

You really should just not assume things

And yet you follow this up by making assumptions about the motivations behind TS. Anders has mentioned that TS was purely motivated by internal MS teams struggling with huge JS codebases, nothing to do with C# but clearly his work on other languages would have influenced how he approached designing the language.

You seem to lack a basic understanding of what a market is in the context of a monopoly, and you can't argue your way around a bad foundation.

our argument is basically "the law says so".

That's the only argument that matters, because monopoly is a legal matter.

Of course not, but most folks poking at Microsoft are just borrowing their opinion from other people and regurgitating it for karma. I'm happy to crap on MS for bad decisions, but the constant "herp derp EEE" gets tired fast.

The Supreme Court ruled once on what they consider an aftermarket monopoly against Kodak in the 1990s, but the aftermarket angle on monopolies has been basically abandoned from a legal perspective because it was shaky at best.

Both iOS and Android both generate more in gaming revenue than Sony. The PC gaming market is only slightly smaller than the entirety of the console market. It's going to be very difficult to make an argument that customers don't have reasonable choice, and the recent case against Apple set precedent that owning the single channel of distribution to a product and platform you own isn't monopolistic unless you do shady things like Google did.

Sony's exclusive rights to distributing games on its owned platform and console will not give it pricing power (won't pass SNNIP) or exclude competition.

Sony can be called a dick for what they're doing without it also having to be monopolistic. People are right to be angry and calling them a monopoly over it is being cathartic.

they now have total command of supply

They've always had control by licensing who can publish games on their platform. Now that contract with publishers has changed who can distribute. Publishers are still free to distribute on other platforms in whatever formats those platforms allow.

that market being Playstation games

This is arbitrarily narrowing the definition of market as far as possible while ignoring reasonable (legal) thresholds. Case in point how Apple's App Store was not ruled a monopoly while Google's Play Store was - there are reasonable tests to pass, and Sony's case will land closer to Apple than Google. And a monopoly is not the only form of anti-competitive abuse.

Might as well claim Domino's has a monopoly on Domino's pizza.

None of your examples pass any of the checks for a monopoly unless you twist the definition of "market" to be the narrowest possible. Situational exclusivity is not the same as a monopoly, and these examples don't pass the hypothetical monopolist test or the cellophane fallacy.

There is no legal, economic, or dictionary definition of monopoly that supports your position. The closest example is "aftermarket" (what you call vertical) following the 90's Kodak SC case, which has long since fizzled out. Monopoly might as well not mean anything if you can define it however narrowly you want.

It's amazing how many people throw around the word monopoly without remotely understanding what it means.

Those prices don't need to bake in the training cost, since it was eaten by someone else (whomever trained the open source models). Anthropic et al. need to price in the whole lifecycle.

A web form assumes the input is or can be made structured, or that you have a user that is willing to fill in a form (vs. writing an email). An LLM is great at taking free-form/unstructured content and mapping it nicely to a structured surface area.

More than two decades, folks were grumbling about this in the SOA days.

Not to mention it can query across heterogeneous sources, so the same query can use a duckdb table, sqlite, csv, and parquet (including predicate pushdown).

It doesn't matter what Google makes money from, it matters what they pay Mozilla for. And they pay Mozilla exclusively rev share on ads, nothing else.

Without the ads, there would be no payments to Mozilla. It's absolutely 100% unequivocably ad money.

Apparently you don't understand what bankruptcy means. A company can run out of funds and not be able to meet payroll without declaring bankruptcy, they're different things. But by all means keep talking out of your ass.

MySQL has advocated for decades spinning up a replica with the upgraded version, waiting for it to catch up to master before promoting it to the new master. You can do the same thing with Postgres.

No one said anything about bankruptcy, you seem to have made that up for your "argument" or whatever this is. The company didn't have a viable business model and was running out of cash. MSFT right-sized the team for the project they wanted it to be, rather than the business model the prior company was trying to be.

The company raised $10M, did two rounds of layoffs totaling a quarter of the company, and was then acquired not long after. Early stage companies like that don't do layoffs unless it's to extend cash runway, but run wild with whatever unfounded fantasy you have about it all.

Right, the very public two rounds of layoffs the company did right before being "acquired" had nothing to do with them running out of money.

It's literally a Google search away. If you had the time to write this comment, you had more than enough time to do the search.

they fired many staff engineers

Would you rather the company went under after it ran out of money and had to fire everyone instead? Not to mention a quarter of the company was laid off the year before the acquisition.

database engine sets up the join

Every major database uses nested loop, hash, or sort-merge joins. If the data is small enough to fetch in a second query, I don't see any scenario where it would make a query spill to disk when it otherwise wouldn't have (except those pesky OR's).

Most JOIN issues can be resolved by composing using sub-queries/CTE's to defer a join to a smaller intermediary result, and the only time this generally can't be done is if you need a predicate on the joined table.

you've asked the database engine to sort things

I've only found this to be true when there's an OR condition where the single query ends up doing a bitmap against every row, in which case a UNION will be faster since it's just appending two already-index-ordered streams.

Same with UNION vs IN

A union is almost always going to be worse - most query planners cannot optimize across queries in a UNION, so each query is going to have separate ops vs. a single op with the IN. The only case I've seen this be true is for multi-column predicates with an OR clause against a composite index. I just tested the former in both Postgres and MSSQL and the UNION query cost was 2x the IN clause.

maybe it decides to do an index scan which takes longer

This has not been my experience unless the table statistics are bad.