Challenge for this project: need to maintain language-rust

[lachrimae]

Tl;dr: someone needs to start maintaining language-rust for this project to get off the ground, and in my personal opinion, this does not appear to be a side-project-sized task that an individual like myself would want to take on. I think this will require more investment and coordination from one of the institutional stakeholders in this project. See also this thread, which discusses some similar points to the ones I make here.

The C version of this project relies on the packages language-c99 and language-c99-simple. The analogous package for Rust is language-rust, accessible here. As you can see, this package has not been updated since 2019.

I've gone through this package and addressed the deprecations and module name changes since that time. The test suite unfortunately does not pass, indicating that the syntax of the Rust language has diverged since 2019. (The test suite downloads rustc and compares its behaviour against the behaviour of language-rust.)

Would NASA, the National Institute of Aerospace, or Galois Inc. be interested in becoming the maintainers of language-rust? It is hard for me to imagine copilot-rust becoming a project with longevity without a convenient way of representing the Rust AST.

Alternatively, we could write a minimal AST representing just the subset of Rust that copilot-rust needs to use. Looking at the C codegen, we probably don't need all the bells and whistles that Rust offers to represent the core behaviour that Copilot wants to produce. But it's not clear to me that this would be less work than simply taking over and updating language-rust.

From what I can see, there was a great deal of initial excitement about this project, and large drop engagement in the subsequent months. I suspect that's because of two reasons. First, the intersection of people who are proficient enough with Haskell, Rust, C and embedded software is a small pool of potential contributors. Second, a lot of these people are going to be gainfully employed, and in my personal opinion this project is not the size of a side-project as currently scoped.

I think that if the leadership of NASA, the National Aerospace Institute or Galois Inc. want this project to happen, they should allocate a software developer to take the following actions. I think that this will improve the "chunk-ability" of the project, and make it easier for people to participate on a side-project basis.

1. Take over maintenance of the language-rust package. Restore the test suite, which relied on a no-longer-existing rustc -Z ast-json-noexpand option to dump Rust's AST to JSON.
2. Review, update and merge this PR which upgraded language-rust to Rust 1.39. (We are now at version 1.76.) It's likely that this PR is large enough, and out-of-date enough, that it will have to be cannibalized.
3. Coordinate a "bug bash" so the community can pitch in on fixing any issues that arise in the updating of language-rust to Haskell version 9 and Rust version 1.76.

Once these tasks are done, it will be much easier to get community participation on copilot-rust. I've made two small commits to language-rust that make some initial restorations and fixes to its test suite, which we could use as a starting point for the full restoration.

[lachrimae]

On the other hand, perhaps there would be someone who is able and willing to take on the tasks I outlined as a side project. But I personally see this as more than I am willing to do, because I only have so much time in my life for programming projects.

[ivanperez-keera]

Hmm, That's a fair point. Given how many haskellers are excited about rust, I would have expected that we'd enjoy better language libraries.

Let me reach out to a few people, to see what can be done about this.

[lachrimae]

I could be wrong, but it seems to me like parser/AST/pretty-printer libraries are the kind of thing people end up building for industrial reasons, and less so for hobby reasons. I think if you're a hobbyist or doing side-projects, then you're more likely to write your own computer language than bring a library for an existing language up to production grade. (I could be wrong, just my personal perspective.)

It is true in my experience that lots of Haskellers are excited about Rust. I observe this about my own coworkers. (Not just excited about it, we have a few internal dev tools which we've written in Rust.)

[ivanperez-keera]

And thanks a lot for looking into this and exploring what needed to be done in language-rust. Very much appreciated! 😃

[ivanperez-keera]

Galois has a fork of language-rust to which they have applied some fixes: https://github.com/GaloisInc/language-rust. It's not up-to-date with Rust 1.71. (I was just told about its existence by Ryan Scott from Galois; I didn't know this myself.)

My inclination would be to not worry about this for an initial prototype, so long as either the PR you mention or Galois' fork works.

If there's a prototype copilot-rust, even if very minimal, it'll be easier to convince stakeholders that it's worth putting in the effort to maintain language-rust.

[lachrimae]

Good point, that makes sense. I'll see if I can get some minimal stuff to run with the existing library.

[ivanperez-keera]

Note also #2 where there appears to exist a minimal prototype without support for arrays or structs.