Repository navigation
Unofficial Rust port of libasdf #255
Replies: 8 comments 1 reply
|
A couple of comments:
|
|
I haven't looked into the WCS support for that plugin yet. I don't think "vibe coded" is the right way to describe this and it makes it sound like I just said "copy asdf and don't make any mistakes". Yes LLM coded most of it however it was constrained heavily by the existing implementations, specification and the test suite. Very happy for to take input on this, and let me know if the WCS should be implemented too, I'll need to understand how to test that part. Re: test coverage, good point, I'll add some coverage metrics to the crates to see how it's looking. |
|
Please don't get hung up on the term "vibe coded"--it's still ill-defined anyways. I used it because to me "re-implement this library and pass the test suite" is no much different from "don't make any mistakes" but I understand the distinction you're making. If the term bothers you I withdraw it from my characterization because that's not really the point, more that it's just all LLM generated and I don't know how much of it was written, reviewed, or guided by expert input. I hope I conveyed though that I still think it's useful, interesting, and appreciated work, and I'm looking forward to taking a closer look myself. I want this to be a collaborative effort. The RiiR approach is interesting too because it forces some rethinking about choices along the library's development history, some of which may not have been completely consistent (I tend to "vibe code" too, in a way, implementing features in a way that feels right to me at one time, and months later implementing other features in a different way, leading to inconsistencies). I'd like to take a stab at the libasdf-sys approach for starters and see how that goes. All I'm asking for now is is a polite request to not claim names like libasdf-rs on official distribution channels like crates.io -- can't really stop you either, but I just want to coordinate that because having an "official" Rust ASDF implementation would be really great and I'm not really worried about who works on it or how much of it is machine coded as long as it's correct and well-designed. |
|
Please read the document I pointed at above. I found that the LLM made some bad assumptions with heuristics until it got locked down by vast numbers of tests. I used an LLM to create a bunch of tests for the original library and then made sure I used identical tests in the rust port. Also, don't worry about WCS given that if you want rust native WCS handling I'm already writing that Rust code. |
|
Very interesting article. From my observations, the test cases and choice of model are the two most important factors. I've tried these types of ports many times over the past 2 years and only since Opus 4.8 have they become reasonable. Another important factor is the initial prompt and planning phases. I found that asking the LLM to spend a significant amount of time planning and researching helped, and specifically instructing me to "ask me questions, don't make assumptions". Having said that, even without test cases, LLMs are very powerful. I hand re-wrote almost all (except parser logic) of CFITSIO into Rust (I think about 200k lines) and without test cases, just instructing an LLM to "read the specification, design tests and find bugs in my port that don't exist in the C golden source" found a huge number of bugs in both my Rust re-write as well as many in the C version. On a side note, I have a significant number of tokens available so if there is anything you'd like me to have a go at, happy to try. |
|
Other Rust FITS readers that I know about: I definitely found lots of C bugs by doing the Rust port since it really forces an investigation when you are trying for maximal code coverage. |
|
I deployed libasdf-rs to crates a few days ago. I left libasdf and libasdf-sys available.
…________________________________
From: E. M. Bray ***@***.***>
Sent: Wednesday, 09 September 2026 19:33:09
To: asdf-format/libasdf ***@***.***>
Cc: Cruzzil_Code ***@***.***>; Mention ***@***.***>
Subject: Re: [asdf-format/libasdf] Unofficial Rust port of libasdf (Discussion #255)
Please don't get hung up on the term "vibe coded"--it's still ill-defined anyways. I used it because to me "re-implement this library and pass the test suite" is no much different from "don't make any mistakes" but I understand the distinction you're making. If the term bothers you I withdraw it from my characterization because that's not really the point, more that it's just all LLM generated and I don't know how much of it was written, reviewed, or guided by expert input.
I hope I conveyed though that I still think it's useful, interesting, and appreciated work, and I'm looking forward to taking a closer look myself. I want this to be a collaborative effort.
The RiiR approach is interesting too because it forces some rethinking about choices along the library's development history, some of which may not have been completely consistent (I tend to "vibe code" too, in a way, implementing features in a way that feels right to me at one time, and months later implementing other features in a different way, leading to inconsistencies).
I'd like to take a stab at the libasdf-sys approach for starters and see how that goes.
All I'm asking for now is is a polite request to not claim names like libasdf-rs on official distribution channels like crates.io -- can't really stop you either, but I just want to coordinate that because having an "official" Rust ASDF implementation would be really great and I'm not really worried about who works on it or how much of it is machine coded as long as it's correct and well-designed.
—
Reply to this email directly, view it on GitHub<#255?email_source=notifications&email_token=AAK6FRND3TQUX3H7767LVUT5OE5XLA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBTGY3TENZVUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-18367275>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAK6FRJSU7NUZSRQ3S7SLB35OE5XLAVCNFSNUABIKJSXA33TNF2G64TZHM4TOMBXG4ZTSMJXHNCGS43DOVZXG2LPNY5TCMBXG42DCNJTUF3AE>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
FYI I didn’t do the -sys initially because my interest is astrophotography and Rust, not C. I have been re-writing my entire processing chain in Rust. Fortunately projects which I’ve been working years on have now become days or weeks because of LLMs and allowed me to explore things like ASDF and XISF integration. I have to say, the ASDF specification is really good and well laid out, definitely helped the process immensely.
…________________________________
From: Peter McNulty ***@***.***>
Sent: Wednesday, 09 September 2026 21:39:58
To: asdf-format/libasdf ***@***.***>; asdf-format/libasdf ***@***.***>
Cc: Mention ***@***.***>
Subject: Re: [asdf-format/libasdf] Unofficial Rust port of libasdf (Discussion #255)
I deployed libasdf-rs to crates a few days ago. I left libasdf and libasdf-sys available.
________________________________
From: E. M. Bray ***@***.***>
Sent: Wednesday, 09 September 2026 19:33:09
To: asdf-format/libasdf ***@***.***>
Cc: Cruzzil_Code ***@***.***>; Mention ***@***.***>
Subject: Re: [asdf-format/libasdf] Unofficial Rust port of libasdf (Discussion #255)
Please don't get hung up on the term "vibe coded"--it's still ill-defined anyways. I used it because to me "re-implement this library and pass the test suite" is no much different from "don't make any mistakes" but I understand the distinction you're making. If the term bothers you I withdraw it from my characterization because that's not really the point, more that it's just all LLM generated and I don't know how much of it was written, reviewed, or guided by expert input.
I hope I conveyed though that I still think it's useful, interesting, and appreciated work, and I'm looking forward to taking a closer look myself. I want this to be a collaborative effort.
The RiiR approach is interesting too because it forces some rethinking about choices along the library's development history, some of which may not have been completely consistent (I tend to "vibe code" too, in a way, implementing features in a way that feels right to me at one time, and months later implementing other features in a different way, leading to inconsistencies).
I'd like to take a stab at the libasdf-sys approach for starters and see how that goes.
All I'm asking for now is is a polite request to not claim names like libasdf-rs on official distribution channels like crates.io -- can't really stop you either, but I just want to coordinate that because having an "official" Rust ASDF implementation would be really great and I'm not really worried about who works on it or how much of it is machine coded as long as it's correct and well-designed.
—
Reply to this email directly, view it on GitHub<#255?email_source=notifications&email_token=AAK6FRND3TQUX3H7767LVUT5OE5XLA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBTGY3TENZVUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-18367275>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAK6FRJSU7NUZSRQ3S7SLB35OE5XLAVCNFSNUABIKJSXA33TNF2G64TZHM4TOMBXG4ZTSMJXHNCGS43DOVZXG2LPNY5TCMBXG42DCNJTUF3AE>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
I'd be really interested to see if libasdf-gwcs "just works" with libadf-rs. I may try to set up a little test bench for that later. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
User @cruzzil has already produced a Rust port of libasdf: https://github.com/cruzzil/asdf
This seems to be the motivator behind PRs #252 and #253
At the outset it looks quite promising and is a valuable contribution to the community worth keeping an eye on.
I do have a couple issues with the approach:
In fact publishing an official Rust wrapper for libasdf was on the horizon for me (albeit not an immediate priority for the Roman mission office).
All this is to say, I applaud the work and appreciate the donation of tokens to the effort and I hope we can work together around a consensus, especially before any “libasdf-rs” crates are published to crates.io.
@timj might also be interested to lend his opinion here, since he’s been doing a lot of experimentation with LLM-led ports of C to Rust for scientific libraries.
All reactions