My perspective is biased by the fact that such communities are an important part of my life. I don't want to see my years-long collaborations and friendships made obsolete by someone looking for an afternoon of nostalgia. And maybe everything will be fine, and the AI-users and the community-builders will go their separate ways and leave each other alone. But communities which exist today are having to ask how we should relate to AI, and my conclusion is that it's best kept out of hobbyist spaces if we want those spaces to continue to exist.

Yes: https://patrickjohnston.org/bank/index.html

To what end? The biggest benefit of tinkering with 40-year-old hardware is the experience of doing so. The knowledge and intuition you learn about how computers really work; the friendships you develop through collaboration with others, through asking for help with your projects and helping others with theirs; and the relaxing Saturday afternoons spent investigating and debugging and experimenting. The "benefit" of having a game that's been recompiled to a native executable for your PC or whatever is marginal compared to the benefit of the process to get to that point. That end goal is just a lighthouse to keep you on track, and when you get there maybe you'll play the recompiled game once to celebrate a job well done before moving on to another project.

If writing software is a means to an end, then there's value in anything that reduces the effort to get to that end. But as I see it, retro gaming projects are mostly an end to a means.

> Seems pretty egoistical when nobody's forcing you to use AI in any way, it provides an objective benefit to other people.

I have three fundamental claims:

- There is little to no positive benefit to using AI for hobby projects whose completion provides little to no intrinsic value.

- Choosing to do so has a negative impact on you, as it bypasses an incredibly valuable learning experience.

- Choosing to do so has a negative impact on others, as it takes away someone else's project opportunity (there are a finite amount of popular retro games, and many people prefer to work on novel projects rather than recreating something that has already been done).

I'm not sure what's "egoistical" about that, and I'd love if you could elaborate on that because I'm still wrestling with the ethics and implications of all this myself. The way I see it, it's better if I choose to forgo the use of AI on my projects, and I think others should choose the same.

---

Many years back, one retro gaming community I'm a part of had a prolific contributor who was extremely knowledgeable about the game, but also incredibly abrasive. He was the most knowledgeable person in the community at the time, and held this over others; discrediting their achievements, discouraging their attempts to learn, constantly starting fights and driving many good people out of the community. Yet he was allowed to remain in the community for many years, because everyone thought we needed his expertise.

Eventually the community came to the realization that it's just a video game and we don't "need" anything at all. None of the long-term community members are really here for the game anymore; we're here for the experience and the camaraderie. So we should make decisions (like kicking out this member) that are technically suboptimal for the game (at least in the short term), but better for fostering the community.

In a similar vein, using AI within these sorts of hobby spaces may allow faster progress on such projects, but it takes away the value of completing the projects in the first place, to the detriment of both the individual and the community.

So having Claude one-shot a NES emulator is almost pointless to me. You're using and looking at source code for an emulator you didn't write -- and you can learn from that, but it's not the same thing and doesn't require you to really understand a CPU the way you would by, say, observing a deviation in game behavior and staring at trace logs to figure out the exact instruction you emulated incorrectly.

It's not all bad -- AI is a great research tool and can automate some of the tedious parts (writing out an instruction decoder by hand is miserable). But using it to just...skip over the effort of doing a project defeats the whole purpose of doing those projects in the first place.

I don't want to be gatekeepy or curmudgeonly or "back in my day..." about it. But for me, my entire career path is due to skills and knowledge I learned spending several years of my life as a teenager figuring out how to write an NES emulator as a relative beginner to programming. And so I feel like using AI for this is depriving the next generation of that learning process. In addition, there are only so many retro games, and fewer popular ones. There's only so much unexplored territory to discover, and doing it with AI deprives another person of that experience and deprives that game's community of someone who might have been able to find a "home" working on projects related to that game.

Pangram claims a 1 in 10,000 false positive rate (rate at which human-authored texts are incorrectly classified as AI-generated). 1 in 200 sounds like the false negative rate (rate at which AI-generated texts are classified as human-authored), or perhaps a rate for a specific category of text.

The only Wikia sites that had anything worthwhile were the ones that started as independent communities and got bought out, like Memory Alpha or the Minecraft wiki.

Comments URL: https://news.ycombinator.com/item?id=49451282

Points: 4

# Comments: 0

> Sign in with Apple addresses, previously issued on privaterelay.appleid.com, will be issued on private.icloud.com.

> iCloud+ Hide My Email addresses will remain on icloud.com.

> If something goes wrong in this process—the overwhelmingly most likely one is that the payer doesn’t have the funds to cover the check (NSF, or “insufficient funds”), but the check being fraudulent or unauthorized is also possible—that wrongness may not be discovered before money “moves” to your bank. And so that payment can be recalled from your bank to the bank the check is drawn on. This will likely result in the bank attempting to recall the money from your account.

> And so by presenting your check, which you think is substantially terminating a transaction, you are actually creating a new credit extension with your bank. They are extremely aware that you just asked them to advance you money, even if you are not aware that you did that. They already partially underwrote this extension of credit; that is why you were not shooed out of the building when you originally asked for a checking account.

Then I saw an actual performance of the play recently, and it all clicked. It was just as understandable as any contemporary film, and easily one of the most fun and entertaining stories I've seen.

Bellard hasn't worked on FFMpeg since 2003.

This comment spawned two subthreads. One of them was focused on the differences between Rust and Zig's compilation model, which is directly relevant to the article and illuminating regarding the engineering tradeoffs.

In the other subthread, pron posted paragraphs and paragraphs arguing about what memory safety really means and whether or not Steve is right to have his opinion that Rust is "safe". This tangent had essentially nothing to do with the content of Steve's comment; it (and not Steve's initial comment) was the point where the thread was derailed from the topic of Zig's incremental compilation model. Steve responded politely in this thread to comments and questions directed at him, but did not fan the flames or take the thread further into off-topicness. If the moderators collapsed pron's comment or detached it and pinned it to the bottom of the page, this comment thread would be much better and much more respectful to the Zig project.

I think the RESF trope is just about dead now; it's given way to the Rust Detractor Strike Force showing up to turn unrelated threads into tangential arguments about why Rust is bad.

The downside is that functions which are called from multiple dependent crates will need to be codegen'd in each of their dependents, so this can increase compile times if the crate is not "mostly unused."

So it's not quite as powerful as full demand-driven compilation, because of how Rust separates the compilation process into separate crates.

Things are slowly getting better here! '&raw'/'&raw mut' reference operators were stabilized a couple years ago.

Another ergonomic improvement in the pipeline is a better way to access fields behind pointers, something like C's -> operator. This is taking some time to design because there are things other than raw pointers that would benefit from a generalized field projection mechanism, like Pin, NonNull, and (potentially user-defined) smart pointer types.

There are roughly two categories of Rust user:

1. People who are using Rust for application development. Most of these users write zero unsafe blocks in their careers. For these users, "memory safety" was probably not a strong reason to pick Rust, because there are a wealth of other memory-safe application development languages out there.

2. People who are using Rust for systems programming (i.e. programming under resource or environment constraints). These users may write unsafe for performance reasons, or to do things like hardware MMIO; and they're using Rust over C/C++ either for security or just because the tooling is nicer.

The first category of user is unlikely to consider C for application development in this decade; they're going to be comparing Rust against Go or Java or Node.js. Fil-C solves the security problem of memory safety, but it does not free the developer from the difficulty of having to manually write memory-safe C code; their program will just crash if they get it wrong.

The second category of user cannot use Fil-C because of its performance overhead, runtime requirements and/or lack of escape hatches for MMIO/FFI.

Where Fil-C does shine is for legacy application software written in C. Here, it's a free lunch: a way to harden the massive amount of existing software without an expensive rewrite. I would love to see distros shipping pizlonated coreutils, ffmpeg, systemd, curl, sudo, postgres, etc., anything that has a big attack surface, but does not need to be memory-unsafe.

This is a problem I care about a lot, and your work here is truly a monumental advancement in the field. Comparisons to Rust sell it short by inviting endless debate on problems largely tangential to Fil-C.