I think they mean tokio::spawn’s signature forces libraries that want to be easy to use with it to expose send+sync APIs (and thus use Arc+Mutex internally)
> Async ruined Rust for me, even though I write exactly the kind of highly concurrent servers to which it's supposed to be perfectly suited. It degrades API
It refers to async in Rust, and everyone else is responding as if it is talking about async in Rust. That's a mischaracterization. You don't have to use the Tokio executor.
It's a bit like saying, "Graphics in Rust are ruined. I need to use Vulkan to make my game."
No, you don't. If your use case is unique enough, use something else. There are bindings for OpenGL, DirectX, etc.
> Rust has green threads in the early days and abandoned them in favour of async / await. Granted the original green thread implementation needed a bit of refinement - making every low level choose between event driven and blocking on every invocation was a mistake.
That's a mischaraterization. They were abandoned because having green threads introduces non-trivial runtime. It means Rust can't run on egzotic architectures.
> It sounds like Zig with its pluggable I/O interface finally got it right
That remains to be seen. It looks good, with emphasis on looks. Who knows what interesting design constraints and limitation that entails.
Looking at comptime, which is touted as Zig's mega feature, it does come at expense of a more strictly typed system.
This depends on what you mean by low level. Commonly it means, how much you need to take care about minute, low-level issues. In that way C, Rust, and Zig are about the same.
Dependencies have nothing to do with low-level vs. high-level but just package management, how well the language composes, and how rich the standard library is. Are assumptions in package A able to affect package B. In C that's almost impossible to avoid, because different people have different ideas about how long their objects live.
Having a rich standard library isn't just a pure positive. More code means more maintenance.
I agree with you that package management has nothing to do with how low-level a language is.
That being said Rust is definitely a much higher level language than either C or Zig. The availability of `Arc` and `Box`, the existence and reliance on `drop`, and all of `async` are things that just wouldn't exist in Zig and allow Rust programmers to think at higher levels of abstraction when it comes to memory management.
> Having a rich standard library isn't just a pure positive. More code means more maintenance.
I would argue it's much worse to rely on packages that are not in the standard library since its harder to gain trust on maintenance and quality of the code you rely on. I do agree that more code is almost always just more of a burden though.
> That being said Rust is definitely a much higher level language than either C or Zig. The availability of `Arc` and `Box`, the existence and reliance on `drop`
I mean, C++ have RAII and stuff like unique pointer, does that make it higher level than Zig?
And what if you don't use Arc or Box? Is your program now lower level than baseline Rust?
As I said, depends a lot about what you mean by low level.
It depends on the facilities the language offers to you by default right?
C++ offers much higher level primitives out of the box compared to Zig, so I'd say its a higher level language. Of course you can ignore all the features of C++ and just write C, but that's not why people are picking the language.
IMO "level" roughly corresponds to the amount of runtime control flow hidden by abstractions. Zig is famous for having almost no hidden runtime control flow, this appears pretty "low level" to many. OTOH, Zig can have highly non-trivial hidden compile time control flow thanks to comptime reflection, but hardly anyone identifies Zig as a "high level" metaprogramming language.
I'd say so. Zig is aiming to be a bit smarter than C while staying at roughly the same level. C++ more sought/seeks to support C but offer higher level things with it.
And in practice the maintenance just doesn't get done. That's why Python's "rich standard library" with batteries included not only periodically has to throw out "dead batteries" because parts of its stdlib are now obsolete, but also has an ecosystem where good Python programmers don't use parts of the stdlib "everybody knows" just aren't good enough.
You see that in C++ too. The provided hash tables aren't good enough so "everybody knows" to use replacements, the provided regular expression features aren't good enough, there's the 1970s linear algebra library that somebody decided must be part of your stdlib, here's somebody's "my first optimized string buffer" type named string...
For now Zig is young enough that all the bitrot can be excused as "Don't worry, we'll tidy that up before 1.0" but don't rely on that becoming a reality.
How dare you insult the forty gazillion company! Stand back ma'am I'll protect you from this handsome hacker ruffian!
Jokes aside, I have started to see Microslop as the lesser of two evils (two evils being MSFT and AAPL, Google being its own parallel universe abomination). Their commitment to backward compatibility really paved the way to cheap PCs for the masses. That said, every day Macroslop is working diligently to prove me wrong.
Do they no longer charge annual licenses for Windows Server?
On that topic, it’s always surprised me just how little Apple invest into their enterprise / business backend services. Everything about the way they integrate Macs into businesses is awkward. Apple could make so much money there if they wanted to. It’s a real missed opportunity.
>On that topic, it’s always surprised me just how little Apple invest into their enterprise / business backend services. Everything about the way they integrate Macs into businesses is awkward. Apple could make so much money there if they wanted to. It’s a real missed opportunity.
Agreed! My $DAYJOB is an Apple shop and the Apple "Business" offerings are horrible. No support for a proper business developer account is annoying. A single human is responsible for this and when that human moves to a different company or role then you have to reassign the account to a different human. Configuring SSO is another trap. You have to capture a domain to add SSO but after you do that your users can't access the Apple App Store (for some reason).
There are so many places that Apple could improve their "Business" business, but they seem hell bent on not doing that. Maybe Mr. Ternus will address this issue.
The issue is that nobody (relatively speaking) uses Windows Server.
I don’t even think Microsoft is all that adamant that their customers use it.
It’s just not competitive with Linux and that ship has sailed. Linux is better and costs $0. Microsoft lets you run .NET applications on Linux and they’re better there.
I think the same thing happened with SQL Server. Nobody’s choosing it for new projects, its niche is basically legacy software.
I agree that Apple is missing an opportunity with business and enterprise but I think the issue is that they’re so far behind that catching up would be a massive investment that might never pay off.
This is similar to saying that Microsoft missed an opportunity with smartphone ecosystems. They could spend billions on getting a smartphone back on the market and it would arrive and everyone would ask the question “why am I buying this when my iPhone has X million apps on its store and is a nearly perfect device?”
If Apple Enterprise Cloud was available today who is switching and why? Apple would have to undercut established players to convince businesses to switch via a massive migration effort.
I work with fortune 500 clients, and all of them use Windows server for something. Usually a lot of somethings. For example: Active Directory.
If we look at Microsoft's revenue I think it's pretty clear that they do in fact care an awful lot about Windows Server - or at least should.
In fiscal year 2025, Microsoft Corporation's revenue by segment:
Devices: $17.31 B
Dynamics Products And Cloud Services: $7.83 B
Enterprise Services: $7.76 B
Gaming: $23.46 B
Linked In Corporation: $17.81 B
Microsoft Three Six Five Commercial Products And Cloud Services: $87.77 B
Microsoft Three Six Five Consumer Products and Cloud Services: $7.40 B
Other Products And Services: $72.00 M
Search Advertising: $13.88 B
Search And News Advertising: $13.88 B
Server Products And Cloud Services: $98.44 B
Server Products And Tools: $98.44 B
Windows: $17.31 B
I don’t think this is clear at all because the segments are lumped together and highly unclear.
What’s the difference between “server products and cloud services” and “server products and tools?”
I assume the former is Azure and the latter is on-premise.
In that case if we lump 365 in with server products and cloud tools then it shows that 2/3 of the enterprise revenue is going to cloud and 1/3 is on-premise (and I assume that 1/3 is declining over time)
You only need a couple of Active Directory and Exchange servers here and there. But who's using IIS or SQL Server these days? Sharepoint also seems to be on a downturn.
You’re talking about LAMP-type set ups and I’m talking about Windows Desktop integration services. Smaller orgs will use cloud services but many larger organisations, colleges, and the like will likely have a fleet of Windows servers running in VMs (traditionally VMWare but that might have changed since Broadcom bought them).
However if you do want to talk about services outside of fleet management, then there are plenty of niches where Windows Server has a surprising foothold. Though typically they’re domains which haven’t been disrupted by “tech bros”, which is why you don’t read about it much on HN.
> This is similar to saying that Microsoft missed an opportunity with smartphone ecosystems.
They did. But we are talking specifically about fleet management and not any random tech-adjacent industry.
> If Apple Enterprise Cloud was available today who is switching and why? Apple would have to undercut established players to convince businesses to switch via a massive migration effort.
The existing players only exist because Apples default offering is basically non-existent. Apple wouldn’t need to undercut them, just be comparably priced. The reason being that if you already have a business account with Apple then you don’t need to go through the pan of getting a new supplier approved by the board (etc).
As for existing businesses, if they’re already large enough that fleet management is a concern then they’re large enough to have people on payroll who manage that fleet. And thus to perform that migration. It might even be part of their laptop refresh program.
And if Apple had an enterprise fleet management service then they’d be able to offer tools that are locked to their fleet management (eg remote wipe). Which would heavily incentivise businesses not to go with 3rd parties.
Maybe they could find another way to market it, e.g. Windows is free but with ads, and there is a subscription which makes ads go away. Or something else. Some creativity is needed.
I don't disagree. A big reason 2026 is the Year of the Desktop Linux is that MSFT lost any interest in the Desktop PC platform. Outside selling more of my data and filling it with AI Slop.
But if, say, AAPL had won the PC wars, we'd be staring at a much more locked-down, much more expensive OS experience.
Well, before Apple, most phones were appliances with fixed software; there was no openness to speak of. That said, I wish they hadn't continued this trend and instead took inspiration from Windows Mobile.
But then came Java and Wap. You could, in theory, download a jar from a site and try to run it. God knows if it would run. But it wasn't a locked-down app store that bypassing would land you in hot water.
Before iphone mobile phones were running Java applets, which were sometimes even compatible across different phone manufacturers and users even could exchange them over infrared. In contrast first iPhone initially had no support for third party software, only web apps.
> Before iphone mobile phones were running Java applets, which were sometimes even compatible across different phone manufacturers and users even could exchange them over infrared.
"Sometimes" doing a lot of heavy lifting.
Nokia had an app store, and before you could see the available apps you have to first choose your phone: because even with-in Nokia's own product range there was so much variation in screens, keyboards, and general capabilities that they had to pre-apply a filter to show you what would actually work.
Excuse me while I get permission from sixteen levels of managers inside Cingular, U.S. Cellular, Cincinnati Bell, PrimeCo, and the fifty different regional carriers calling themselves "Cellular One" to offer my app on their networks.
I'm not claiming that iPhones are open to the extent that HN griefers want it to be, but you must have been freshly hatched in the years before the iPhone to think the ecosystem was open.
I say this as someone who developed some of the first mobile phone weather apps. (Before "app" was even a word.)
I may be guilty of the same thing you're mentioning (I'm in the USA), but my Nokia 6210 came with a carrier lock and I wasn't even able to visit websites via the WAP browser unless my carrier approved of them because WAP acted like a sort of mandatory vendor operated proxy that allowed them to see and filter everything the phone did. They would, for example, filter out websites about ringtones to try and force you to buy theirs for $0.99/piece.
My experience with a Nokia 6210 was very much the opposite of what you describe.
It was exactly like the GP described in the UK too. All-powerful carriers at a time when Apple was almost bankrupt, before Google was a verb and before Microsoft made phones that would crash just sitting waiting for a call.
> Apple basically spearheaded the war on general computation. Before them, phones used to be more or less open, Apple cracked down on that very quickly.
reply