I am concerned about the quality. Even a cursory skim of the code makes the code appear asinine. Unless the genius aspects of the code elude me.

https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...

https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...

This is a (slightly more typesafe) transliteration of the C code.

https://github.com/postgres/postgres/blob/2e6578292a9184dcaa...

Yeah same. The structure makes no real sense and when digging into the code it reads like I'm the first human to look at it.

That's how Ai generated code is. I am almost convinced that Models are intentionally taught to write obtuse code because AI companies don't want us to write code at all

I'm too young but I imagine assembly programmers were feeling the same when automatic code generation by compilers took over. Very weird.

More that I got confused by the C function returning bool, not as an error value, but as a result, which is my fault for skimming it quickly.

I have taken a closer look at the code, and it seems superficially a somewhat faithful rewrite, not quite idiomatic Rust, but closer than I anticipated at first. I know there are non-LLM rewriting tools for C to Rust, and with a test suite to help, a rewrite to Rust might be greatly helped. The new Rust code does have some drawbacks in some ways, and there are topics I am curious about.

Wow, I would love to read an interview series based on this!!

I guess there also were macro-assemblers before C, so it was a bit more natural.

I'm not sure what you mean? The rust code you're showing mimics the Postgres code: https://github.com/postgres/postgres/blob/2e6578292a9184dcaa...

The boolean being returned is the return value of the function. It's not used to return an error.

Now that I have taken a closer look, the code looks significantly better than it seemed at first glance, though there are still peculiarities, and some drawbacks.

An unfortunate aspect is that the code has become a bit more bloated in some regards due to usage of Result, instead of an implicit elog() macro and similar. Passing Result around, in some ways as an alternative to an unwinding exception, is cleaner in some ways, but it also bloats the code somewhat.

The rewrite also could have simpler code in some cases, like

https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...

could perhaps just be

match syscache_seams::search_pg_class_full_form::call(ctx.mcx(), relationId)? {

        Some(form) => Ok(form.relhassubclass),

        None => {

            Err(ereport(ERROR)
                .errmsg(format!("cache lookup failed for relation {relationId}"))
                .into_error())

        }

    }

but that is a smaller thing.

I see a lot of MemoryContext. I am not sure how much that bloats the code (though the C code is bloated due to C's issues and problems, like re-using collections and such). Does it incur an overhead?

> The rewrite also could have simpler code in some cases

The Rust code is a literal translation of the Postgres code which returns the value at the end instead of an early return.

> I see a lot of MemoryContext

MemoryContext in C is used for multiple reasons: 1) performance 2) keeping track of how much memory has been allocated and where and 3) preventing memory leaks.

Reasons 1 and 2 are still relevant for Rust. The challenge is in C memory contexts are stored in a global variable. Global variables don't work well with the rust borrow checker so I opted for passing memory contexts as function arguments instead.

Sorry, I wrongly assumed in the C code when I skimmed it that the boolean was for error handling, not the result value. The elog() macro is used for error handling.

I make no claim as to whether the change makes sense given that I didn't look at the callers of this function, but Result<bool> is an entirely reasonable pattern in Rust. If you want the callers to be able to distinguish between "has the subclass", "doesn't have the subclass", and "something went wrong" this is idiomatic Rust.

I wrongly guessed that the boolean in the original C code was for error handling when I skimmed it, but instead it is just a result value, while elog() and related macros/functions are used for general error handling in the C version. I agree that it makes sense in Rust and other languages with tagged unions.

Though often when applicable, a simple tagged union is used instead when that would document the intention better. Like, the Rust version of search_pg_class_full_form::call() returns a Some for cache hit and None for cache miss as far as I can skim, and that group of methods returning that could arguably have returned a basic enum instead with CacheHit(value) and CacheMiss. Though this is a nitpick on my part.

Yes, but the original boolean seems to have been used for error handling, and the tagged union is also used for error handling. Why have both simultaneously in the same function instead of just one of the two?

Edit: Looking at the code again, perhaps I was mistaken, since the boolean might not have been for error handling, just the result of the function, and C's limitations regarding error handling led it to using something like elog(), apparently a macro defined in https://github.com/postgres/postgres/blob/master/src/include... .

Didn't the initial rewrite of Bun into Rust have an ocean of "unsafe" in it, and wasn't it entirely dysfunctional?

There's still no release of rust-bun so then it might just not exist (until it proves itself).

Yesterday we learned that it’s been shipping with Claude Code since mid June, so it has a lot of active users already.

Also, the unsafe footprint seems reasonable — the bulk of it in FFI wrappers.

Yes, that was the point. It made unsafe behaviour visible in a way that could be addressed. I hadn't heard any reports of it being dysfunctional.

I have read up on it again, and while it was entirely dysfunctional at the very early stages, it quickly came up to par or beyond, with the LLM especially helped by the huge test suite written in Typescript, different from both Zig and Rust.

However, Jarred still describes a lot of unsafe, and usage of Miri in continuous integration.

Funnily enough, RAII is cited as a major benefit of rewriting from Zig to Rust, while C++ already has RAII. I wonder if C++ and Rust are more suited to larger programs than Zig, unless the architecture in Zig is handled carefully.

The LLMs may have seen larger codebases in Rust, helping them to cope better.