Measter

Yeah, there's no visible flicker at 70Hz or higher.

No, I mean the screen noticeably flickers when displaying a static image at 60Hz progressive.

You don't want to simulate the god-awful flicker my CRT has at 60Hz.

A project I've just started is to follow the Roguelikedev tutorial on a 32-year-old PC, using the period dev tools. I'm going to have to write everything myself, and I'm currently researching how to poke the graphics adaptor.

Why bother doing that when it would be vastly easier on a modern computer?

Yup, definitely the Rust users who are toxic. Totally not the people going into every thread about Rust to tell everyone about how toxic Rust users are. Nope.

In terms of "finished" projects, I wrote a program that generated new, empty, histories for Crusader Kings II. It could create new cultures, religions, and titles, and did a simple simulation of them spreading over the map.

I also wrote a server-side plugin for Assetto Corsa that monitored track limits, and could integrate into the program the league I was in used to find the pace of drivers for when we needed multiple servers.

In terms of "finished" meaning "I stopped working on it", I did write a compiler for a static concatinative language.

They're a long-time anti-Rust zealot. This is the sort of nonsense they've been coming out with for years.

Which is probably a case of the human prompting the AI only being able to see the decoy message, so they think the AI was able to read it because it matches what they can see.

There's also the element of actual humans being unable to read the intended message, and only seeing the decoy text.

It's a pretty crappy system if a portion of your intended audience can't even read it.

Complete and utter nonsense. Every Windows tool I remember using has handled LF-only endings perfectly fine, meanwhile Linux tools regularly fail to handle CRLF endings.

The only times I can remember having line-ending issues is using GNU's tools on Linux. Every Windows tool I can remember using accepts both CRLF and LF.

Microsoft's PowerToys did add that in (I think) the last version. Alt + Left click moves, alt + right click resizes.

That's not really that surprising when you think about it. Standard library-provided things are implemented on a basis of working OK for as many scenarios as possible, not on one of being the best possible implementation for every possible scenario.

Hilariously, I had the exact opposite. I use Fira Code, which I eliminated in the first round.

> It's as if someone asked you how many 1s there are in the binary representation of this text.

I'm actually kinda pleased with how close I guessed! I estimated 4 set bits per character, which with 491 characters in your post (including spaces) comes to 1964.

Then I ran your message through a program to get the actual number, and turns out it has 1800 exactly.

No, it isn't. Because that distinction is significant if you are using the language in an environment where those libraries are not available or suitable, such as the Linux project which uses a custom fork of Alloc which provides collections for different allocators.

The Rust language has exactly that level of control. Rust's Alloc and STD implementations do not yet provide it.

Memory allocations in Rust are also always done explicitly, but Rust's library types don't have APIs that allow you to get it wrong.

Another issue we have to consider here for the measurements taken then is that it was miscompiling, which, to me, calls into question how much we can trust that performance change.

Additionally, it was 10 years ago and LLVM has changed. It could be that LLVM does better now, or it could do worse. I would actually be interested in seeing some benchmarks with modern rustc.

> On the other hand, signed integer overflow being UB would count for C/C++

C and C++ don't actually have an advantage here because this is only limited to signed integers unless you use compiler-specific intrinsics. Rust's standard library allows you to make overflow on any specific arithmetic operation UB on both signed and unsigned integers.

> In debug mode, rust programs also crash on unsigned integer overflow.

All integer overflow, not just unsigned. Similarly, in release mode (by default) all integer overflow is fully defined as two's complement wrap.

And, by default, panicking in Rust also doesn't crash, it begins a stack unwind which can be caught on any layer above it with catch_unwind.

Fun fact: that's what an unwrap does. It panics, which causes the error to be logged and the thread ended.

Back in 2015 when the Rust project first had to disable use of LLVM's `noalias` they found that performance dropped by up to 5% (depending on the program). The big caveat here is that it was miscompiling, so some of that apparent performance could have been incorrect.

Of course, that was also 10 years ago, so things may be different now. There'll have been interest from the Rust project for improving the optimisations `noalias` performs, as well as improvements from Clang to improve optimisations under C and C++'s aliasing model.

It's interesting that I've also heard the same from people involved in Rust. Expecting more interest from C++ programmers and being surprised by the numbers of Ruby/Python programmers interested.

I wonder if it's that Ruby/Python programmers were interested in using these kinds of languages but were being pushed away by C/C++.

For Rust vs C++, I'd say it'll be much easier to have a complete understanding of Rust. C++ is an immensely complex language, with a lot of feature interactions.

C# is actually fairly complex. I'm not sure if it's quite at the same level as Rust, but I wouldn't say it's that far behind in difficulty for complete understanding.

So in Rust an unsafe block and an unsafe function mean two different things. An unsafe block allows you to do things that are unsafe, such as dereference raw pointers, access union fields, calling unsafe functions, etc.

Unsafe functions mark that the caller is responsible for upholding the invariants necessary to avoid UB. In the 2021 and earlier editions, they also implicitly created an unsafe block in the body, but don't in 2024.

Or, in a more pithy tone: an unsafe block is the "hold my beer" block, while an unsafe function is a "put down your beer" function.

A segfault is not the program performing a runtime check and doing a controlled shutdown. A segfault is the OS detecting the program doing something it's not allowed to and killing it.

Only if that memory page is unmapped, and only if the optimizer doesn't detect that it's a null pointer and start deleting verification code because derefing null is UB, and UB is assumed to never happen.

> Take Herb Sutter for example, who argues that "memory safety" as defined in this article is an extreme goal and we should instead focus on a more achievable 95% safety instead to spend the remaining effort on other types of safety.

One thing I've noticed when people make these arguments is that they tend to ignore the fact that most (all?) of these other safeties they're talking about depend on being able to reason about the behaviour of the program. But when you violate memory safety a common outcome is undefined behaviour, which has unpredictable effects on program behaviour.

These other safeties have a hard dependency on memory safety. If you don't have memory safety, you cannot guarantee these other safeties because you can no longer reason about the behaviour of the program.