What do you on macOS that isn't available on Windows? Really curious.

The actual issue is this new Microsoft full of half-done projects and trying to reduce engineering costs. They even try to make others write the documentation for their products... MSDN is gone and now docs are a mess.

Ballmer was a mess, but at least he got the devs-first bit right. Nowadays it is devs-last, cloud-first.

The thing is that he originally served it from its domain so people use both interchangeably.

It is still a ton of time, about an order of magnitude more than optimal if the real/sys time split is to be believed.

In fact, in comparison, Go is pretty unstable compared to those two once you take into account the total time they have existed.

It is definitely not unique to Go.

In many countries, it is not even out of warranty!

Yes, some people change phones every year, but that does not mean the device itself is old just because you change it.

I know the Rust contributors are doing their best, and that this blog post is not writing a marketing ploy, but in the end, the result is what matters.

My take on this is that I am fine with compile times as long as some effort is being done to keep it near optimal.

But I really do not want the Rust team to feel pressure to improve the compile times so much that they will end up killing other features or designing the language differently just for that (like Go, for instance). Or even making the compiler so complex that adding new features is harder for them.

I really like Rust as a language that is more complex to write and to compile but in return gives you robustness and performance. Compilation times be damned. I am not writing Rust to compile fast!

Studying everything new is, of course, a much more ambitious goal.

Why would a C++ programmer learn Go? They should learn Rust since it is pretty much a cleaned up, modernized C++.

   auto f = [&](...) { ... };