endospore

6 ms·

1.
by endospore 2mo ago
> In the rewrite blog post They can't mention what they don't know. And that's the exact reason I'm against this: doing a port without being able to tell what is correct is asking for a disaster, obviously. I've
2.
by endospore 2mo ago
Aw I feel quite sorry for using the word "demonstrable" while not intending to demonstrate anything, in order to avoid any contributions to the project. I apologize for that. That being said I've found a case that doesn'
3.
by endospore 2mo ago
https://github.com/oven-sh/bun/issues/30719#issuecomment-446... Personally I chose not to disclose my findings in public to avoid this kind of outcome. Having a good laugh with others is not as important as k
4.
by endospore 2mo ago
Sorry, I did. And I did an internal sharing with respect to the blog post, on topics of how to (and not to) do software migration, how (not) to deal with unknown unknowns etc. We have several ongoing software (automated) migration projects
5.
by endospore 2mo ago
> nobody has really pointed to a single actual issue I personally know 3 categories of newly introduced issues spanning the code base with 200+ occurrences, that leads to undefined behavior and memory issues. Not doing any contributions
6.
by endospore 2mo ago
> Good engineers can work in any language Given that they are investing their time into actually learning the language before diving into this mess. No, unsafe Rust isn't supposed to be something you can handle without prior knowl
7.
by endospore 2mo ago
That's a stated goal, so nope. But releasing it before any cleanups is another story. I'd also like to inform you that - the current success metrics solely consist of their advertisement, my eyes looking at the code strongly sugge
8.
by endospore 2mo ago
My conclusion was formed in my two months long tracking of the repo activities. They have done absolutely nothing in that front. (Well, to be precise they tried to fix exactly one thing that was pointed out but that's it) > must int
9.
by endospore 2mo ago
The Zig one uses raw pointers. These are bad and get out of hand quickly but at least don't have constraints like "you must never have two &mut on the same value". You may refer to c2rust to see how "semantics preser
10.
by endospore 2mo ago
Their (public) project management is horrible, you can find fixed issues unclosed and unfixed issues closed. Not really surprising when that part of the work is completely taken over by LLM agents though.
11.
by endospore 2mo ago
> The original code was one giant unsafe block True. > has fewer bugs Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them. > every potential memory iss
12.
by endospore 2mo ago
> next step is to make it idiomatic rust You can tell what will happen when they release it before sorting out all the new bugs introduced by the not-exactly-line-by-line port.
13.
by endospore 2mo ago
Reviewing is meaningless while they are still keeping the 10433 (sorry it has become 10503 since last week) unsafe blocks, most unsound and none encapsulated. Any review would get to the simple conclusion that this should not be released be
14.
by endospore 2mo ago
"Preserving semantics" by casting pointers to aliasing refs in Rust, ignoring lints and errors in the process. Can't help laughing at this point.
15.
by endospore 2mo ago
> ignoring the fact that it was an intermediate step. They are going to release the "intermediate step" with all its issues as v1.4. I think that says a lot about which party is ignoring facts. (hint: not me, not you, not Andre
16.
by endospore 2mo ago
Yes, they have introduced (at least) several times more memory safety issues by violating the rust specific rules. Check how most of their unsafe blocks are unsound and worse, how many are straight up incorrect with a total bs //
17.
by endospore 2mo ago
> increasingly dumb That's untrue. It has already been maximally dumb since your first comment with the various logical fallacies you managed to carry out in a single sentence. The only reason I'm still making my replies is tha
18.
by endospore 2mo ago
> 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 t
19.
by endospore 2mo ago
Oh it's so nice of you when I've spent the bottom half of my comment explaining how you cannot grep for most of them in this BAD codebase. Please READ . Including the one I've added at slightly higher layers of replies.
20.
by endospore 2mo ago
There wasn't a reply button on your latest reply so I'm posting here instead. Also because I now have more time to clarify what's exactly wrong about the claims. > who says that the same invariants weren't broken on t
21.
by endospore 2mo ago
Instead of "possible" undefined behaviors, potential bugs, the samples I've randomly picked are all actual undefined behaviors, real bugs. Hence statistically. > pointer aliasing is undefined behavior in both languages Tha
22.
by endospore 2mo ago
Yes you are. Either that or you are too distracted to read or you wouldn't be repeating > ~2X potential at this point. That's what I've found in 10 minutes. And they are actual bugs that I've take extra time to (sta
23.
by endospore 2mo ago
> made grep'able That's not the correct understanding. These are specifically the ones that were not bugs in Zig. They are forbidden in Rust because of reference invariants that don't even exist in Zig, so correct code are
24.
by endospore 2mo ago
Can't assume good faith in you at this point but I'll explain it. - They've written two articles, one by claude doing the migration another by the human behind it, neither acknowledge these problems. Nor does the incorrect SA
25.
by endospore 2mo ago
Measurably yes. They claim that 128 problems from the zig version was fixed, so I grepped for two known categories of UBs and unsoundness unique to unsafe Rust and found 237.
26.
by endospore 2mo ago
Look a few more till you find absolutely bs SAFETY comments marked on immediate UBs. They are everywhere.
27.
by endospore 2mo ago
Well the rewrite has newly introduced many immediate and critical safety (as in Rust sense) problems. It's clear and obvious if you read the code knowing the basic rules of unsafe Rust. And don't be surprised if it doesn't ap
28.
by endospore 2mo ago
Ha. You'll be surprised when you find out how much new problems were created in the code base precisely because the author's (not sure if it's still the right word here, they barely involved) lack of knowledge of Rust. And no
29.
by endospore 4mo ago
No. They introduced quite a few aliasing issues that result in immediate UB in Rust but are allowed in Zig. I skimmed over the unsafe blocks with rg for ten minutes and spotted like 3 cases and these wouldn't exist in the original code
30.
by endospore 4mo ago
Calling it as working is a bit of an exaggeration. Looked at the code for a few minutes I'd expect it to crash and burn if they ever dare to turn the optimization on.

More ›