simonask

As far as I understand it, the idea is that the IO interface is "magic" in the sense that it affects which version of a function gets called: either the synchronous, linear version, or the asynchronous, stackless, suspensible state machine version.

This has a lot of implications, especially for function pointers and other forms of dynamic dispatch.

My personal take is that async code is fundamentally different from sync code, because the weights of various tradeoffs change dramatically. In my view, "colorless" functions are not really a worthwhile goal in the first place. But I've been wrong before, so it may turn out to be great, we'll see.

Just to let you know, `std::process::exit(...)` in Rust does not call any destructors. C++ also has `std::quick_exit(...)`. Applications exiting slowly is a problem caused by app developers.

(There are cases where it also takes time because the OS does have to flush all open files during process teardown, etc., but this shouldn't generally be user-visible.)

It's also built for people who need a reasonable desktop computer but don't want their living room to look like a 14 year old's bedroom, or a corporate office space.

I'm not one of them, but I think many of us have had to convince partners that the big clunky monstrosity of a setup is actually cool...

I have not in 20 years encountered a single company producing software, be it their primary product or a supporting role, that didn't use version control.

This was a thing in the early 2000s, but very certainly hasn't been the norm for a very long time now, at least in my part of the world.

If it's different where you are, you need to take immediate action and inform your company leadership of this extreme liability.

For all the shortcomings of C++ templates, they are vastly preferable to preprocessor macros. At least they allow for a modicum of type safety.

Modern C++ is characterized by relying on templates for generics and reusability, as well as static dispatch.

“Traditional” C++ looks a lot more like Java, and often like C.

Much of the compile time of both Rust and C++ comes from monomorphization and linking, both of which do a lot of work to support the zero-cost high-level abstractions favored by both languages.

Yup, I’m a happy user of it. Writing generic code with these enumerators is extremely verbose, because the language lacks associated types.

This is a common misunderstanding. Rust’s type system and borrow checker are not significant reasons for its compile times, and Rust compile times aren’t really worse than equivalent modern C++ code.

Large game engines consist of many medium to large software libraries stitched together. What you're likely to see is that each such library is gradually either rewritten or replaced by Rust code, with an FFI compatibility layer matching the existing ABI where possible.

There's no reason to think that current game engines will have their fundamental APIs around scene management, serialization, entity composition, and so on, ported directly to Rust, because these things are typically designed around available language features. For example, an engine written in C++ might have its own version of `dynamic_cast` and RTTI, and that's going to be an extremely awkward design in any other language.

I think 15 years is too high, but I agree that it will be a while, because a triple-A game engine is a huge investment.

I keep seeing this take, but oddly only on Hacker News, never anywhere else. It's still utterly delusional.

The smallest amount of memory you can request from the OS is a page (typically 4K, sometimes 16K), and there’s a lot of additional stuff that goes on in malloc().

Serious people in all of those industries are thinking about whether and how Rust is a fit for their needs.

Like, I agree that C++ will be around for a long while, but the writing is on the wall.

Optimizations like that is not a sound basis for an architecture, though.

Like, I get that it’s “fine” for a lot of things, but it’s very not fine in situations where you really need to guarantee that a particular operation doesn’t, say, trigger GC, like in a video game.

I’m aware. I would consider the fact that LINQ has caveats a failure of language design - it’s so convenient, but you just can’t use it for performance-sensitive stuff.

Meanwhile, iterators in Rust frequently outperform manual loops.

> Europe is economically uncompetitive, the rest of the world makes circles around it performance and money-wise, ...

Don't buy the propaganda. You're talking about the second-richest part of Earth, with undeniably the world's highest average quality of life. It's also a big place with massive differences.

You have to understand that when Germans are being dramatic over the economic state of their country, they are describing issues that the vast majority of countries would absolutely love to have. Economic growth of only 0.9% is very bad if you have a lot of catching up to do, but Germany doesn't, so it just amounts to being slightly behind other rich countries.

"Deteriorating Europe" is a Russo-American psyop. Luckily we have better memory - we've heard this song for at least 100 years by now, and yet here we are. That's not to say that there aren't issues, but Europeans are largely unbothered by things like the GDP growth difference between the Eurozone and the US, because it's quite clearly driven by a runaway stock market and unfathomable inequality. You can't eat GDP figures.