Live data from Hacker News

Viewing profile — endospore

endospore

HN member
Joined
Tue, Mar 10, 2026, 8:15 AM UTC
HN karma
73
Public activity
37 items

About endospore

No profile information was provided.

Recent public activity

  1. comment
    Comment #48979426

    > 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 …

  2. comment
    Comment #48976700

    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 …

  3. comment
    Comment #48976590

    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 oth…

  4. comment
    Comment #48975433

    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 h…

  5. comment
    Comment #48972860

    > 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…

  6. comment
    Comment #48972807

    > 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 …

  7. comment
    Comment #48970239

    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 adverti…

  8. comment
    Comment #48969125

    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 …

  9. comment
    Comment #48969043

    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…

  10. comment
    Comment #48968772

    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 ov…

  11. comment
  12. comment
    Comment #48968737

    > 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 viol…

  13. comment
    Comment #48968642

    > 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.

  14. comment
    Comment #48968590

    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 …

  15. comment
    Comment #48968562

    "Preserving semantics" by casting pointers to aliasing refs in Rust, ignoring lints and errors in the process. Can't help laughing at this point.

  16. comment
    Comment #48903000

    > 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 ig…

  17. comment
  18. comment
    Comment #48900901

    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 …

  19. comment
    Comment #48881277

    > 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…

  20. comment
    Comment #48870401

    > 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 th…

  21. comment
    Comment #48859319

    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 adde…

  22. comment
    Comment #48858363

    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 th…

  23. comment
    Comment #48855181

    Instead of "possible" undefined behaviors, potential bugs, the samples I've randomly picked are all actual undefined behaviors, real bugs. Hence statistically. > pointer aliasing i…

  24. comment
    Comment #48854429

    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 bug…

  25. comment
    Comment #48850737

    > 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 do…