Predrag Gruevski is a Rust developer who writes about semver checking, undefined behavior, compilers and odd debugging stories.
HN commenters link his posts on Rust semver-checking speedups and undefined behavior, and the Wi-Fi-only-works-when-raining story fits a list of strange bugs.
> Zig does have invariants
Not these in particular. You are again ignoring the context.
> Undefined behavior does not mean a bug can be triggered.
Undefined behavior are bugs by themselves. Let's check if you are holding any of the wrong assumptions:
https://predr.ag/blog/falsehoods-programmers-believe-about-undefined-behavior/
> `unsafe` is grep'able, hence all memory safety bugs are grep'able.
Wrong implicit premise: "all memory safety bugs resides in unsafe functions/blocks".
No. Even assuming everything is done idiomatically, memory safety bugs can still originate from unsafe blocks and all the safe functions in the same module. So we want the module containing unsafe to be small and closed. Otoh with this code base unsafe lives in every module.
Making them encapsulated is the whole point of Rust, in this code nothing is encapsulated so no, they missed the whole point of it.
Aaand it's not like you can just remove the unsafe blocks one by one trivially. It's as hard as rewriting the codebase from ground up without reference (unlike the current migration) as every referenced object in the call graph needs to be reordered. Well partly because the original code sucks I assume.
> Everything I wish I knew when learning C
For me, by far my biggest regret is that the learning materials I was exposed to (web pages, textbooks, lectures, professors, etc.) did not emphasize how insidious undefined behavior is.
Two of the worst C and C++ debugging experiences I had followed this template: Some coworker asked me why their function was crashing, I edit their function and it sometimes crashes or doesn't depending on how I rearrange lines of code, and later I figure out that some statement near the top of the function corrupted the stack and that the crashes had nothing to do with my edits.
Undefined behavior is deceptive because the point at which the program state is corrupted can be arbitrarily far away from the point at which you visibly notice a crash or wrong data. UB can also be non-deterministic depending on OS/compiler/code/moonphase. Moreover, "behaving correctly" is one legal behavior of UB, which can fool you into believing your program is correct when it has a hidden bug.
A related post on the HN front page: https://predr.ag/blog/falsehoods-programmers-believe-about-undefined-behavior/ , https://news.ycombinator.com/item?id=33771922
> More details in my blog post here: https://predr.ag/blog/speeding-up-rust-semver-checking-by-over-2000x/
Tl;Dr implementations of the adapter api can provide hashmap lookups and the query engine will use this when possible before doing a full scan - this is transparent to the query author.
A 3000 word essay takes approximately 10 minutes to read. (Assuming subject familiarity) It is frustrating when the main point is at the end and very little is discussed about the shape of the new api besides the fact that it is experimental.
I spent quite awhile on the site trying to understand the features and benefits of the query language. I left unsatisfied by the long commentless query examples and repeated claims of being able to query anything. It'd be nice to have a discussion of the what the language is, how an adapter should be implemented and how the engine will use my adapter. Maybe that is covered in linked video talks but there are no slides to skim to see if thats worth my time.
OP I appreciate your passion and enthusiasm but as a potential user I can't figure out where to start with the project.
Came across this list in the comments of this discussion, lots of great stories here! https://news.ycombinator.com/item?id=44466030
My personal list of stories of this kind includes:
- Car allergic to vanilla ice cream: https://www.cs.cmu.edu/~wkw/humour/carproblems.txt
- Can't log in when standing up: https://www.reddit.com/r/talesfromtechsupport/comments/3v52pw/i_cant_log_in_when_i_stand_up/
- OpenOffice won't print on Tuesdays: https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161/comments/28
- Wi-Fi only works when it's raining: https://predr.ag/blog/wifi-only-works-when-its-raining/
Nice summary! I'd also add that part of the public interface you're on the hook for is never explicitly written down in the source code, and is instead derived automatically by the compiler based on a set of rules. There are excellent reasons why this is the case, but as you could imagine this doesn't make semver any easier.
For Rust folks, I'm talking about auto traits like Send and Sync.
More info and examples here:
https://predr.ag/blog/toward-fearless-cargo-update/
It's only fair to call out that #[non_exhaustive] only helps you for the very specific case of adding new enum variants or struct fields. It does nothing for the burden of keeping all existing variants and fields compatible with any way they could have been matched.
However it's also only fair to note that the Rust ecosystem does not consider every [potential] breaking change a major one. https://predr.ag/blog/some-rust-breaking-changes-do-not-require-major-version/