[judofyr]

Very cool project! Always happy to see more work around static analysis.

However, looking at the recent commits it doesn't quite look like the most solid foundation: https://github.com/shuaimu/rusty-cpp/commit/480491121ef9efec...

    fn is_interior_mutability_type(type_name: &str) -> bool {
        type_name.starts_with("rusty::Cell<") ||
        type_name.starts_with("Cell<") ||
        type_name.starts_with("rusty::RefCell<") ||
        type_name.starts_with("RefCell<") ||
        // Also check for std::atomic which has interior mutability
        type_name.starts_with("std::atomic<") ||
        type_name.starts_with("atomic<")
    }

… which then 30 minutes later is being removed again because it turns out to be completely dead code: https://github.com/shuaimu/rusty-cpp/commit/84aae5eff72bb450...

There's also quite a lot of dead code. All of these warnings are around unused variable, functions, structs, fields:

    warning: `rusty-cpp` (bin "rusty-cpp-checker") generated 90 warnings (44 duplicates)

[usefulposter]

    Generated with [Claude Code](https://claude.ai/code)
    via [Happy](https://happy.engineering)

    Co-Authored-By: Claude <[e-mail]>
    Co-Authored-By: Happy <[e-mail]>

This isn't just vibe code. It's mobile vibe code.

No logic, no coherence———just inconsistency.

---

Note: This is an experimental shitpost. Fork it. Share it. Use it. [EMOJI ROCKET]

[yadaeno]

This whole thing feels like clever marketing. Why would the mobile app be credited?

[SkiFire13]

https://github.com/shuaimu/rusty-cpp/blob/3707c09f5ff42bc5f6...

It also looks like it's skipping some lifetime checks in some sketchy way

[mgaunard]

Just looking at the code excerpt makes it clear the code must be quite low quality

[UncleEntity]

> …which then 30 minutes later is being removed again because it turns out to be completely dead code

I'm not sure if it's a good or bad thing people expect the robots to produce proper code on the first attempt?

[lifetimerubyist]

> made with AI

[hu3]

Yours an other similar comments are disproportionally rude given that the author was very upfront about their methodology.

And I don't think it's constructive to cherrypick commits in this context.

> I even started trying out the fully autonomous coding: instead of examining its every action, I just write a TODO list with many tasks, and ask it to finish the tasks one by one.

> I never had to fully understand the code. What I had to do is: I asked it to give me a plan of changes before implementation, it gave me a few options, and then I chose the option that seemed most reasonable to me. Remember, I’m not an expert on this. I think most of the time, anybody who has taken some undergraduate compiler class would probably make the right choice.

The idea has merits. Take it as a PoC.

[wavemode]

I don't see anything that is the slightest bit "rude" in the comment you're replying to. It actually begins with enthusiastic praise of the project and its goals.

I don't understand why you feel it's not "constructive" to review the quality of code of a project. Are people supposed to just blindly believe in the functionality without peeking under the hood?

[hu3]

Let's agree to disagree then.

Initial praising doe not preclude rudeness. And complaining about a commit that was undone 30 minutes later is not only pointless in the presented context, it's a cheap attempt at insulting.

> Are people supposed to just blindly believe in the functionality without peeking under the hood

False dichotomy. No one said that. And we both know this is not the way regardless of the codebase.

I think the idea has merits and given the honesty of the post, it's rather more productive to comment on it instead.

[UncleMeat]

> The idea has merits. Take it as a PoC.

Does it? There have been a gazillion such static analyzers. They all do one of two things: ignore the hard parts of tackle the hard parts. If you ignore the hard parts then your tool is useless. If you tackle the hard parts then your tool is orders of magnitude more complex and it still struggles to work well for real world projects. This is in the former category.

The article says "And since the static analysis is mostly statically scoped, it doesn’t require heavy cross-file analysis."

Oops. Suddenly you either handle aliasing soundly and your tool is plagued with zillions of false positives or you handle aliasing unsoundly and... you aren't getting what makes rust different. Separate compilation has been a problem for C++ analyzers for ages. Just declaring it to not actually be a big deal is a huge red flag.

Heck, even just approaching this as an AST-level analysis is going to struggle when you encounter basic things like templates.

The article says this: "Everybody tries to fix the language, but nobody tries to just analyze it." This is just flagrantly false. What's bizarre is that there are people at Stony Brook who have done this. Also, introducing new syntax (even if they are annotations) is more-or-less the same thing as "fixing the language" except that there is almost no chance that your dependencies (including the standard library) are annotated in the way you need.