I don't think that's very useful. What would be useful is a Rust with GC, turn off lifetimes and such, and let people build real systems, then show how to turn them back on. There's a variant on gradual typing, multi-lingual programming, etc., that is embedded in all this. ↵ - ThreadSky

shriram.bsky.social • 99 days ago

I don't think that's very useful. What would be useful is a Rust with GC, turn off lifetimes and such, and let people build real systems, then show how to turn them back on. There's a variant on gradual typing, multi-lingual programming, etc., that is embedded in all this. ↵

Comments

fridgeseal.xyz•99 days ago

Arguably, the borrow-checker, getting to grips with lifetimes etc is kind of core to a Rust.

Remove those and you end up with a markedly different language.

+ people are already building real systems w/ these enabled.

I don’t mind a “mini Rust, but it should arguably be its own language.

shriram.bsky.social•98 days ago

Indeed, as I said elsewhere in that tree:
https://bsky.app/profile/shriram.bsky.social/post/3lk5es5i7js25

mvsamuel.bsky.social•99 days ago

Isn't that exactly what you did with Racket so that you could turn on features for students as they progress through exercises? Or am I high?

shriram.bsky.social•99 days ago

Two responses. 1. Depends on your goal (teaching vs production). 2. The goal in turn depends on your audience. Since I think most people who will use Rust are not novices, the bar for what you should be able to build is much, much higher. ↵
https://bsky.app/profile/shriram.bsky.social/post/3lk4t4vjhbc2p

shriram.bsky.social•99 days ago

In the Rust case it's more about removing features than adding them as you go along. That's a somewhat different dynamic. In Racket, a program in a lower language will always work in an upper language. If you go the other direction, this will no longer be true (eg, if you take away GC).

mvsamuel.bsky.social•99 days ago

Yeah. I mean you can to some degree reify that.

A Rust lifetime could correspond to the lifetime of an object that fronts allocation via a GCed arena, but I guess syntax for explicitly allocating into an arena is the exact kind of embiggening you'd want to avoid.

mvsamuel.bsky.social•99 days ago

I think the problem browsers had to solve was: GCed arenas have to be aware of one another.

Iirc, the whole process separation of JS object graphs for different origins led to a lot of research on collecting cross-GC-arena.

Yeah: https://dl.acm.org/doi/abs/10.1145/2866576

shriram.bsky.social•99 days ago

@mcoblenz.bsky.social and others have argued that GC makes Rust easier to use. Not to dock the work (which I like), but that's not too surprising (but still good to confirm!). The problem is building a full-fledged ecosystem around that, working out the interop, etc.
https://arxiv.org/abs/2110.01098

ltratt.bsky.social•99 days ago

IMHO this work and its conclusions need to be treated with caution, as it undermines Rust's type system -- you can write 3 or 4 line reasonable-looking programs in it that have UB & segfault. Personally, I think GC for Rust could help beginners (and others!), but to evaluate that we need a sound GC.

shriram.bsky.social•98 days ago

Didn't they patch the GC to be sound? The paper says so.

ltratt.bsky.social•98 days ago

The students used the unsound `deref` version, which is *much* easier to use. [There is a second source of unsoundness w.r.t. LLVM stackmaps, but that's much nerdier, and I don't think impacts the conclusions. I also don't think the system is exactly thread safe, though I haven't fully checked.]

ltratt.bsky.social•98 days ago

[Also, when I Iast checked, I believe the version-without-deref wasn't merged in, so if you ran the system yourself, you still got the very unsound version. Warning: I might be wrong about this.]

shriram.bsky.social•98 days ago

Yes, I think that's what @mcoblenz.bsky.social is saying here too. Maybe he can address the other part as well.
https://bsky.app/profile/mcoblenz.bsky.social/post/3lk5d2uksic2f

shriram.bsky.social•99 days ago

I'm trying very hard to not get nerdsniped into working on this (-:. But I think we have a clear way forward in the PL world. It would require a lot of engineering. And also some clear sense of definition: is this a *teaching* tool or *production* tool? A very large space once you work out details.

yminsky.bsky.social•99 days ago

It's not quite a language level approach, but the work we're doing inno camel to provide rust-like features is gradual in flavor. It very much tries to provide a pay-as-you-go experience.

yminsky.bsky.social•99 days ago

And in particular, you can both use the GC, and write convenient, allocation free applications.

shriram.bsky.social•99 days ago

Yeah, I'm a big fan of this!

yminsky.bsky.social•99 days ago

Ugh. "Inno camel". Serves me right for dictating my texts. "In OCaml", obviously

shriram.bsky.social•99 days ago

I honestly thought you folks had created a new dialect. "Don't ask what Inno is and sound stupid, it'll look like you don't read Jane Street blog posts."

steveklabnik.com•99 days ago

this GC is not sound :(

shriram.bsky.social•99 days ago

Pretty sure they found and fixed the soundness bug, and it became sound?

steveklabnik.com•99 days ago

Ah! I didn’t hear about that, that’s good. I’ll make a note to go check it out…

The only reason I even cared is like, you want to make sure the API as presented is possible.

mcoblenz.bsky.social•99 days ago

Sorry I should have read the whole thread before replying! Still getting used to the Bluesky UI.

steveklabnik.com•99 days ago

You’re all good!

mcoblenz.bsky.social•99 days ago

Can you be more specific? We did fix some soundness problems post-experiment. And the implementation is a partial proof of concept and not a working GC.

mcoblenz.bsky.social•99 days ago

The implementation would definitely need a from-scratch redo for real work.

steveklabnik.com•99 days ago

Is there a good spot to check out those fixes? Just for my own curiosity :)

IIRC the issue was like, aliasing &mut Ts.

mcoblenz.bsky.social•99 days ago

I think this is the relevant commit. Note it’s on a branch: I never got around to merging. Criticism is welcome. https://github.com/mcoblenz/Bronze/commit/34c1538c8047535c87cf9771a014696d4a2e53c9

steveklabnik.com•99 days ago

🙏❤️

steveklabnik.com•99 days ago

(that said, it's an interesting area to research, and i'd love to see more of it. in particular, i also wonder if like... is this true for people who just have a lot of GC experience, and no non-GC experience? etc etc)

samth.bsky.social•99 days ago

I think given that Rust's approach is quite different from any other non-GC language people might have used, basically everyone will find GC Rust easier to learn.

steveklabnik.com•99 days ago

Maybe! There’s also questions of how much learning GC-rust translates into actually doing regular rust. The borrow checker is design pressure. And you have to learn that to really learn rust

shriram.bsky.social•99 days ago

This is my point about subtraction vs addition in response to the question about the comparison to Racket. I think the additive model works quite well for Racket language levels. The subtractive model (take away GC) is unlikely to work as well, that too for such a big delta.

samth.bsky.social•99 days ago

I think learning how to program with sum types, parametric polymorphism, type classes, and higher order functions takes significant effort, and those are all things that are important for learning rust.

steveklabnik.com•99 days ago

i've got some Thoughts around this whole area. not enough time to pursue every interesting thing :(

Comments

Posting Rules

Reply