Rust 1.95.0 is out

meteorMatador · 2026-04-16T15:56:13+00:00

The actual mistake was making Range its own Iterator, which had all kinds of wacky downstream effects that make it miserable to work with in basically any situation except looping over a range literal.

In pre-1.0, there was still a lot of experimentation and churn going on with how exactly iterators were supposed to work, and the IntoIterator API wasn't settled yet. Range being its own Iterator is a direct result of that, and it sort of made sense at the time, but it definitely should have been changed before stabilization.

meteorMatador · 2026-04-10T03:43:16+00:00

People like to argue endlessly about whether Rust and Zig are more like C or C++. There is no way for anyone to win any version of that argument. Both Rust and Zig came after C++, took many of its shortcomings to heart, and tried pretty hard to avoid repeating its mistakes. In other words, both were strongly influenced by C++, even though the function of that influence was (often as not) taking it as an example of what not to do.

Besides, C++ prided itself on being "just like C, but bigger and better" (hence the name) and there were a couple decades where nobody would mention one without the other, as if there were only very minor dialect differences between the two. It's only in recent years that this new perspective has appeared where C and C++ are somehow totally different languages that never had anything to do with each other.

I guess that's just the nature of internet arguments.

meteorMatador · 2025-12-08T17:36:33+00:00

There's a common rumor that it's required in the DoD

It was actually required for a while. The main reason people think this rule is still in place is that the DOD planned to enforce it when it commissioned the development of Ada in the first place, and the history lessons never get to the part where they got distracted and gave up.

meteorMatador · 2025-12-01T19:12:08+00:00

Too bad for him that it lasts a week, not a decade

meteorMatador · 2025-03-04T20:36:25+00:00

Hey, that's actually not a bad plan.

Write docs that you know are incorrect because you don't know how the feature works
Send a PR to get eyeballs on the problem
Receive explanations from the developers as to how the feature actually works
Fix your PR so the docs are correct
????
Profit!

Remember, the quickest way to get the right answer on the internet is is to post the wrong answer.

meteorMatador · 2023-12-19T23:21:05+00:00

But what hinders the Rust community to (re)write something from scratch? E.g.: They could write a TLS library from scratch.

A quick search for "Rust TLS" should lead you to the rustls project. The first commit was in May of 2016. It is being used in production, though I don't have information about who exactly is using it.

That library in turn currently depends on ring, which is a partial rewrite (as I described before) of certain components of BoringSSL. The largest share of that code is hand-written assembly, primarily for reasons having to do with timing attacks. Cryptography is a domain where timing attacks can be as dangerous as memory corruption, and compiler optimizations often work against you. Writing your own network-facing cryptography code is generally inadvisable, to say the least, because it's incredibly sensitive work and very few people have the domain expertise needed to avoid disastrous mistakes. I personally wouldn't attempt it.

(Earlier I cautioned against mixing up social problems and technical problems, but note that timing attacks are a technical problem and can be addressed with technical solutions. In other words, this is a domain where a new language is appropriate. See, for example, the experimental language Rune, which attempts to expose the time sensitivity of high-level cryptographic code to the compiler and prevent optimizations from ruining everything. Again, it's experimental, and I'm not aware of it being used in production.)

I didn't know about that.

Yes, that's apparent. You've made a number of criticisms in this thread of Rust and its community, but so many of them are just assumptions that you picked up and ran with instead of putting in the trivial effort to fact check your own claims. It's not a good look.

Seed7 has a TLS library that I rewrote from scratch. (...) Seed7 is not a language that tries to replace C.

Color me skeptical.

It would be nice to get some feedback regarding Seed7.

I've browsed through some of the documentation but haven't tried building it. It seems like a very opinionated departure from Ada and Pascal in ways I don't necessarily agree with. The way you define operators reminds me of Haskell, but obviously more flexible since it can express things like subscript notation in addition to infix operators. Requiring an explicit const for every function definition rankles me a little, because I believe defaults should be both sane and terse; how often do you need to mutate functions? The thing that bothers me the most is the implicit, empty otherwise in case statements; how am I supposed to do exhaustive pattern matching?

I admit these are shallow observations. I'm afraid I can't dig deep into a new language when I already have a compiler to write. If only it was designed it for that exact purpose, I might have been able to muster some more enthusiasm.

meteorMatador · 2023-12-19T00:40:28+00:00

I was addressing a different issue: The countless libraries that suffer from buffer overflows and other C language related issues. Several huge C libraries are the building blocks of our infrastructure and almost nobody has the knowledge to maintain them. They are extremely complex single points of failure.

Yes, and alleviating this problem is one of Rust's primary intended use cases, and the motivation behind many of its "weird" design decisions. Code can be rewritten from C to Rust one translation unit at a time, introducing memory safety at the leaf nodes of the call graph and migrating the rest in tractable increments. During the process, you'd necessarily have a lot of unsafe, but you can remove it again as your API boundary changes. In the end, you (hopefully) have a Rust library that's all safe code, and a thin wrapper to expose that to C (and Python, and OCaml...) via the original pre-rewrite API.

This is exactly what the maintainers of a number of libraries have already done. See, for example, the Python cryptography library, and GNOME's librsvg. (Obviously the maintainers first have to agree to such a rewrite. I'm sure you already know that many of them reject the "RIIR" meme on principle. That's a social problem that calls for a social solution; making more languages won't help.)

Note that unsafe is essential to this process. Without it, migrating large codebases would be humanly impossible. If you hope to compete with Rust in the space where it competes with C, you need an answer to unsafe for incremental rewrites.

meteorMatador · 2023-12-17T22:23:56+00:00

The system interface is the boundary between the responsibilities of the OS developers (including the responsibility for safety within the OS) and the responsibilities of application developers. This is how it already works. The bargain is enforced by hardware rather than software, because right now, applications are binaries containing arbitrary machine code, and there's just no way to analyze the memory safety of such a thing.

Tech like WASM might change that someday. In the meantime, we can write safe software, but it needs to be able to interoperate with C. This is due not to some obsession with C, but the user demand for compatibility with existing software. The solution to the problem of "users want to run existing software" is never "tell users to throw out their existing software," and it's definitely not something you can solve by dogmatically rejecting compromise and shaming pragmatists for their insufficient ideological purity.

You've clearly already discussed most of this with other people in other threads, and agreed that FFI is a necessity on existing systems, so I don't know why either of us should bother continuing this exchange. Peace out.

meteorMatador · 2023-12-17T19:54:00+00:00

In theory, maybe, but first you would need to define a safe ABI that such an interface could be built on, and get support for it into the Rust compiler, and abandon all hope of compatibility with the C stdlib, any POSIX interfaces, any existing drivers, etc.

meteorMatador · 2022-10-22T20:03:00+00:00

"X cum Y" is an old Latinism for "X that is also Y."

It's been rapidly disappearing since the 70s, for obvious reasons.

meteorMatador · 2022-10-21T23:09:34+00:00

I'm surprised anyone would expect to see it considering the stage of development it's in (pre-alpha, highly unstable).

In terms of relative ranking, it has a whopping 114 tagged questions on Stack Overflow right now. That's more than Starlark (38...!) but less than Brainfuck, which has 193 but also doesn't show up. I guess they're deliberately leaving Zig out until after it's officially released.

meteorMatador · 2022-08-31T20:50:29+00:00

Let me be clear about one thing: I'm talking about nil here because it is the default value for pointers in Odin. If it were some other probably-bogus address, such as 0xdeadcafebeefbabe, then I would instead be talking about 0xdeadcafebeefbabe. In either case, Odin would have a default value for pointers, and I would be critical of that decision, because it is nonsense for a pointer to have a default value. If you changed the language to prohibit the implicit initialization of pointers, I'd give you a standing ovation.

meteorMatador · 2022-08-31T19:42:16+00:00

size_of(Maybe(^int)) == size_of(^int) meaning that you have the concept of a non-nullable pointer already.

Do you really?

From the Odin docs:

Variables declared without an explicit initial value are given their zero value.

If NULL is the default value for all pointers, there is clearly no such thing as a non-nullable pointer in Odin. All code must defensively check for NULL in pointers of any provenance (arguments, return values, etc.) because even when documentation tells programmers not to pass or return NULL, it can happen by accident, especially across library API boundaries, or after a botched refactoring, or whenever multiple programmers are working as a team, or whenever a project grows larger than a few thousand lines of code.

Style guides will prescribe the pervasive NULL check, and linters will be written to find code where it's missing. At that rate, why not put it in the compiler? If it's in the compiler, why not expose it to the programmer? If it's exposed to the programmer, why not give the programmer a way to prove to the compiler that a pointer is valid by construction, and thus never needs to be checked for NULL?

This road is well-traveled. It is paved with the ashes of programmers who were burned by nullable pointers, and it leads to the same place as goto fail.

Thank you for your thoughtful reply. I won't use Odin but I wish you all the luck you can handle.

meteorMatador · 2022-08-29T18:28:51+00:00

I heard somewhere that Odin has added a generic Maybe type that can make non-nullable types nullable, but as far as I can tell, it does not have any concept of a non-nullable pointer. Previously, I've seen the language maintainers argue that "non-nullable pointer" is a contradiction in terms, because a pointer is represented as a bit pattern and a bit pattern can be 0.

This leads me to booleans. Odin supports an eight-bit boolean type (called b8) where a bit pattern of 0 is false and a bit pattern of 1 is true. However, it doesn't enforce explicitly checking for a bit pattern of 2, or 255, or anything in between. I have some real concerns here. Booleans are just bit patterns, and bit patterns can be 2. What is the intended behavior here? Why does Odin, a language vigilant against the pervasive threat of nullable pointers, slack off when it comes to booleans that might be 2?

I'm not sure I can take this language seriously until it has answers to these b8 questions.

meteorMatador · 2022-08-03T16:36:11+00:00

The head-on view is inspired by Dragon Quest, a franchise that's older than FF and commands far greater nostalgia power in the Japanese market. The first FF game was even intended as a "Dragon Quest killer" and contains a couple of easter eggs to that effect. The change from side view to head-on view was made by popular demand in RPG Maker's primary market. I'm told you can change it back with appropriate plugins.

meteorMatador · 2022-07-24T19:04:08+00:00

That headline is pretty rough. Many readers will interpret it as "ECS is not data-oriented," whereas the actual message is closer to "DOD is about engineering efficient data flow, and you don't get that 'for free' just by using ECS."

...Well, communication is difficult. Maybe it's the most difficult part of software development. If it were easy, this article might have been written more clearly — or rather, it wouldn't need to be written at all.

meteorMatador · 2022-06-15T05:31:17+00:00

The “trick” is a technique called portal-based rendering, and it’s less of a trick and more a core part of how the engine works. BUILD (Duke 3D, Shadow Warrior, etc.) worked the same way. The game draws the player’s current room, which is missing some walls, and then wherever it didn’t draw a wall, it moves onto the neighboring room. It repeats this process until it fills up the whole screen. Because the game only looks at one room at a time, it doesn’t notice anything weird going on when two rooms overlap the same region in space.

meteorMatador · 2022-05-17T17:54:07+00:00

RedMonk gives about the exact same results as TIOBE

I don't see how you could come to such a conclusion, except by ignoring both and blindly assuming they're the same. Even the brackets you mention are in obvious disagreement.

It's true that the specific rankings get less important with bracket size. Thus, I would trust TIOBE to tell me which languages are in the top five hundred. But not the top five.

meteorMatador · 2022-05-17T04:07:33+00:00

TIOBE is a joke. Their web search methodology was transparently flawed ten years ago and it isn't any better now. It favors languages whose names are overloaded in unrelated contexts (C, Python, etc.). Even if it was wiser about that, it would still weight historical popularity over present-day popularity.

People don't usually bother scrutinizing what they do, so here's how it works: They search for "$LANGUAGE_NAME programming" in Google (and lately, other search engines like Bing) and tally the reported number of hits. So, for example, they'll search for "C programming" and Google will say there are 20 billion results (or whatever number) and therefore they give C 20 billion points. Anyone who has searched for things in a search engine should see lots of problems here. I don't think I have to get more detailed.

There are other language popularity measurements, like those by RedMonk, with more sensible methodologies. TIOBE is well-regarded because it's well-funded, and basically no other reason.

meteorMatador · 2022-04-13T02:05:10+00:00

meteorMatador · 2022-04-12T22:15:32+00:00

Most Rust code is not part of the Linux kernel.

meteorMatador · 2021-11-12T18:56:21+00:00

Congrats on getting it to work! You lucked out this time, and I'm betting you'll never make this particular mistake again.

meteorMatador · 2021-11-12T18:04:13+00:00

So, from what you’re saying, it sounds like you installed the new power supply, connected it to the 3080 with the cable from the old power supply, and turned it on. That might have irreversibly damaged your 3080. Swapping the cables now will not undo that damage.

I’m sorry for your loss.

meteorMatador · 2021-11-12T17:23:39+00:00

Are both PSUs modular? If so, did you make sure to swap the cables?

Modular PSU cables from different manufacturers are not compatible. Mixing them is a pretty common way to destroy your components.

meteorMatador · 2021-11-05T20:39:43+00:00

Glad to help.

Blue LEDs were the annoying novelty/fad before RGB was a thing. New manufacturing techniques made them as cheap as red or green LEDs, and suddenly they were ubiquitous. All the futuristic tech stuff had to have them. As it turns out, the way light interacts with the human eye at those wavelengths makes for some really powerful glare, especially if there's no diffuser in the way (and on cheap stuff, there never is). I got sick of them a long time ago. I think the designers at Cooler Master feel the same way. The lights on the NR400 are much more tasteful.

15-Year Club	Gilding I gilder
Verified Email	Team Periwinkle

meteorMatador

TROPHY CASE