HN Reader

> When I upgraded to Sonnet 4.5, it became less often that it gave phantom answers. But it still sometimes wasn’t able to handle some complex problems. We’d go back and forth and I’d try to give it hints. But with Opus 4.5, that happens much less often now.

The real annoying thing about Opus 4.5 is that it's impossible to tell most people "Opus 4.5 is an order of magnitude better than coding LLMs released just months before it" without sounding like a AI hype booster clickbaiting, but it's the counterintuitive truth. To my continual personal frustration.

> Then I thought: how hard is it to write this C++ static analyzer? Conceptually, I think it’s not hard. It requires going through the AST. And since the static analysis is mostly statically scoped, it doesn’t require heavy cross-file analysis.

How do you handle function lifetimes then? Those are generally non-local to infer, and Rust requires annotating functions with informations for that. I tried taking a look at the mako db's refactor but I didn't see any lifetime annotation being added there.

Wrapping every pointer in a smart pointer is very bad style; that suggests you simply have the bad level of abstraction in your code.

That problem seems even more prevalent in Rust, where I see Arc used everywhere, presumably as a cop-out not to have to figure out how to satisfy the borrow checker in smarter ways.

unique_ptr/shared_ptr (and box/arc) still need to handle null states due to how moving works in C++.

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)

That must be some bait post, as we all know, C++ and Rust developers hate AI.

How readable is the code produced by opus, when you try to interact with it manually?

> One thing I used to hope for is better interop between C++ and Rust … But after closely following discussions in the Rust committee, I do not think this is likely to happen soon.

Interesting. I thought C++ interop was one of the top priorities right now.

It’s one of the top items mentioned in recent language progress reports, the Rust foundation received a million dollar grant to work on it, and there was a talk at the most recent RustConf about how Google is doing Rust/C++ interop.

Curious to know what discussions led to that conclusion.

OP here: Ah, thanks for all these comments! Didn't expect so much passion.

Many comments are right this is prototype and there isn't any code guarantee! It is purely test case driven.

But this prototype sort of proves that to have Rust-equivalent memory safety, you don't really need to completely ditch C++, and all those "rewrite in Rust" clones of C++ repos. The time I spent on this project is very limited. I did maybe half of the dev on my phone through Happy. If Microsoft or Google who has lots of C++ code is willing to put some serious resources on this idea, I am sure they can have something a lot more solid. And they don't have to give up C++ (they shouldn't, it is very unclever engineering wise).

To me personally this prototype is a "usable" alternative to Circle C++. It saved me a lot of hard debugging time.

curious what the token costs look like on a real codebase. opus ain't cheap and C++ headers get big fast

1. There are tons of static analyzers for C++. Does none of them support type system augmentation? 2. Is the proposed solution really more practicable than "typescript for c++" [0]?

[0] https://github.com/hsutter/cppfront

Honestly, I found this piece depressing. Life is too short and precious to waste on crappy software.

So often the question ai related pieces ask is "can ai do X?" when by far the more important question is "should ai do X?" As written, the piece reads as though the author has learned helplessness around c++ and their answer is to adopt a technology that leaves them even more helpless, which they indeed lament. I'd challenge the author to actually reflect on why the are so attached to this legacy software and why they cannot abandon it if it is causing this level of angst.

> C++ has a perfect match for Rust’s mutability: const and non-const.

Rust has inherited mutability, while I believe const in C++ is shallow. I don't think it's a perfect match.

Is it just me or this seems like a quick-win for many C++ codebases?

Simple and elegant solution.

Can we see an example of this on a moderately sized codebase?