191–200 of 756 posts
2664 "unsafe {", 1835 "unsafe fn". This is completely unsafe. It doesn't look like a rewrite that understands what's actually going on or how the architecture should be redesigned to take advantage of Rust strengths. Instead, it looks like an AI generated transpilation with extensive use of raw pointers.
Why should a developer use this for anything beyond a pet project? Just because it is written in Rust? All these "rewritten in rust" projects only reinforce the idea that a significant part of the rust community consists of software talibans and not of engineers who must deliver something that works and is reliable over time.
How exactly are rewriting something the equivalent of being the taliban?
Why should a developer use this for anything beyond a pet project? Just because it is written in Rust? All these "rewritten in rust" projects only reinforce the idea that a significant part of the rust community consists of software talibans and not of engineers who must deliver something that works and is reliable over time.
> significant part of the rust community consists of software talibans I seriously don't get it though. Rust is a nice language, but so is X. However we don't see X people brigading existing projects with constant bombardment with "rewritten in X". What is that about Rust that prompts this behavior?
I like the AGPL and think it's the best truly free open source license, but I worry if this is compatible. Ie, if this is rewritten from the original source, should the original apply? (Yes.) There has been a trend to rewrite open source software with a more restrictive license (like coretools in Rust). This looks considerably more ethical by choosing the AGPL - I just wonder, safer with no change at all?
[0] https://www.postgresql.org/about/licence/
[1] https://github.com/malisper/pgrust?tab=AGPL-3.0-1-ov-file
Earlier quoted context omitted.
> Is there a correlation between the quality of the manually written code and AI generated code driven by the same dev? If the dev doesn't vet the code, it doesn't matter how good quality a dev they would be if they wrote the code - they didn't. Sure, the dev would probably drive the initial architecture discussion better and some people are using AI in small batches with tests and vetting everything, but some previo…
You must be replying to a different comment. Seems completely unrelated to what I wrote. I never claimed that there wasn't AI slop. My point is that there are different levels of code coming out of AI, both due to the quality of the model and harness, and the quality of the engineer that is driving it. Thus you can't just bucket all AI developed code the same. 100% there is slop created by humans and really solid cod…
> I never claimed that there wasn't AI slop
No, but you implied that a top tier dev doesn't produce slop when using AI.
> If you have a black box that spits out code, and you are unable to distinguish the quality between a top tier dev and an AI inside the black box
My point was that "if" is doing a lot of heavy lifting here and you're coming very close to begging the question.
> bucketing all AI code as the same.
Most people are not "top tier devs" and over time this will probably become more true. Even if I accepted your premise that "top tier devs" only generate solid code bases with AI, the ease of entry and the ease of spitting out thousands of lines of code means the ratio of bad AI to good AI will not go in a good direction unless it becomes too expensive for non "top tier devs" to use. Given this, I think it's fair to assume AI code is low quality until proven otherwise.
> The goal is to make Postgres easier to change from the inside uh-huh, sure. you want to show off "look what the LLM can do / look what I burned a bunch of tokens on"? you want to brag about how your LLM-generated slop is somehow more maintainable than the original because blah blah blah Rust? here [0] is the version history of Postgres. pick a version from the past. let's say 14.x because it's the most current that…
The parser was generated by c2rust. The Postgres parser is generated from yacc/bison itself so I didn't bother making it idiomatic.
What a peculiar kind of rewrite. Rust: https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b... Original: https://github.com/postgres/postgres/blob/df293aed46e3133df3... Usage: https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b... The return type in the rewrite is both some sort of Error tagged union that supports the Try machinery in Rust; but, it also contains a boolean that apparently must be chec…
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 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.
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.
Earlier quoted context omitted.
Sure, but behaviors that never have a bug or regression don't get a test. Software of this kind of complexity has all kinds of behavior that has never been broken, and doesn't have a specific test written for it. Getting an extensive test suite passing is certainly orders of magnitude better than having no test suite at all, but it still doesn't tell you as much as you need to know. I would absolutely never trust an…
> Software of this kind of complexity has all kinds of behavior that has never been broken This space of things is astronomically larger than the space of things expressly covered by any test suite. "Program testing can be used to show the presence of bugs, but never to show their absence." -Edsger W. Dijkstra
Fable's napkin estimate of the effort required to produce a passable reference semantics for Postgres, which would involve novel discoveries in denotational semantics of concurrent transactions and so on, might be in the ballpark of 30–60 years of PhD level work.
So realistically I think the only way to validate a Postgres implementation involves differential testing, fuzzing, acceptance test suites, etc. And still you'll have bugs that need to be hammered out the good old fashioned way.