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.

C# is an odd one. It's surprisingly flexible, but then oddly lacking in other areas. Quite productive, but also quite inconsistent and uncomposable.

Once you've tried a better type system (Rust), it's difficult to go back to C#. People jump through all kinds of hoops to get good performance out of it, and they're mostly able to.

Things I dearly miss from Rust when I'm using C#:

- Associated types in interfaces. (IEnumerable should not be forced to return a type-erased = heap allocated IEnumerator instance.)

- Move-only structs. (Currently, every type with value semantics is trivially copyable, even ref structs.)

Well, me too, and I can confidently tell you I’ve never seen build times in the 10+ minute range (on capable machines).

My money is on the opposite.

I have no idea about the code quality of Codex CLI, but it takes way way less time to build a full game engine (Bevy).

Stories like this make me think something is wrong with your setup. Do you have Windows Defender or similar enabled on the build directory?

That sounds like something is very wrong with your setup.

Consider that your use case is relevant for an infinitesimally small percentage of Apple's user base. It would be an utter waste of time for them to cater to you, and it's a waste of your money to buy their products.

This is the classic doomer take. Beware of dramatic but simple answers. UBI doesn’t really seem like a sustainable way forward, and at the same time there’s so much we don’t know about the limits.

Don’t play half-court tennis. Other people can read and write too, and social shifts are simultaneous slow, but then sudden.

For example, I’m not seeing a lot of trust in AI as a technology for things that are actually important. It takes one wrong diagnosis from an expensive AI doctor to erode all trust and make everyone prefer a human expert.

> It will crash and burn anyway.

It's unclear from your comment whether you think this is good or bad. You certainly seem to think it is inevitable.

I just want to remind you that nothing here is inevitable - someone is making it happen, and it's only possible because we're not enforcing any of the laws we have about it for some reason, such as copyright. Well, the US isn't enforcing it. The EU is scrambling to come up with reasonable regulations. God knows what China is doing.

I agree that AI, like many other things, would have been an unambiguously great invention in a post-capitalist society, but that's not where we are. They are unbelievably powerful, impossible to control, and fully owned by powerful corporations, so the future looks pretty dystopic for humans who love freedom, art, and science.

But I hope you realize that we have the chance to fight back and get this right. But it does require that you do something.

Casting this as “knowledge” betrays a very fundamental lack of knowledge about how LLMs work, or a desire to mislead for whatever reason.

They are not databases of facts. Even if they were, that would still constitute a very serious violation. They aren’t, and they’re not particularly good at serving that function either.

No, LLMs are capable of reproducing things (text, art, other media) based on their training data. Consider being an artist who produced something original that somehow made it into that training set - your chances of actually making a living are now vastly smaller.

The result is the same as if there was no copyright at all: Big companies will just exploit whoever, no art would be produced.

This is a huge issue, and there needs to be a reckoning.

It’s not a future that’s currently in the cards, no.

If you believe that, then why aren't LLMs free to use for every person on Earth?

If you want anybody to keep making anything, including programmers, artists, and writers, you're going to have to pay them somehow.

Anthropic and OpenAI would not have a product at all without the contributions of thousands of non-consenting humans. Yet they somehow have the gall to charge customers a premium.

Has anyone who contributed to producing the wealth of human knowledge, art, code, and literature making up the training data been compensated in any way?

I'm certainly still waiting for my check.

AI in its current form is a commercial product created from stolen labor.

I think there are extremely legitimate reasons to be critical of that part at the very least, and I don't think it's a particularly "radical" stance within Free Software, which is fundamentally conscientious of such questions.

(I don't know whether the Libreboot authors have this particular point in mind.)

G# and Ab are not the same sound.

They are the same pitch in well-tempered tuning, but that’s a small part of the picture. They are not even the same pitch if you’re singing or playing a fretless instrument, like a violin.

The reason is that the pitch changes slightly based on harmonic context, and the notation communicates the context.

G# typically conveys a tension in an ascending movement (assuming the key is Am or one of its neighbors). Ab can convey tension in a descending movement.

I'm willing to bet at least 20 DKK that a significant percentage of Danish boomers use their CPR number as their password for the digital two-factor authentication system MitID.

They do so because they don't want to forget their password.