I really hope wasm-components well, in part because I think rust is such a great "foundation", believe in it as foundational software.
But getting that usable by Node or Deno or Bun programmers continues to require significant artisanal extra. Really hoping for a stronger polyglot future emerged.
This is a great piece, but I'm not convinced that the "iterative deepening" really is true. Sometimes you get the whole language in your face up front, and that causes frustration for many.
It seems like you should be able to 80/20-rule a PL. 80% of devs need 20% of the language, but the specialized library writers and people who want to hand optimize have a complete toolbox.
But in practice, your function type syntax needs every bell and whistle from your declaration syntax :)
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. ↵
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
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).
@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
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.
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.
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.
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.
(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)
I know that lots of programmers seem to shy away from complex stuff like the type system and lifetimes, but for me it's become the very thing that makes me excited about programming. Writing provably correct code with types that literally prevent you from using a library wrong feels very satisfying.
It's true that a lot of stuff in std panics a bit quickly, but I believe the decisions were made there for ease of use. I know that Clippy has lints for stuff like that, such as `clippy::indexing_slicing` to prefer the fallible `get()` over indexing - lower-level libraries etc. should use that.
Same goes for arithmetic operators, it would be quite impractical to strictly require fallible division, but, again, lints exist (`clippy::arithmetic_side_effects`), as do fallible functions that should be preferred in those cases.
It's practicality over strict correctness.
For me, "provable correctness with types" means that the type checker has enough info to omit runtime checks (i.e. "dynamism"), without sacrificing type safety.
This should be doable in the Rust *language*, but the existing standard library doesn't make it easy, to say the least.
I feel like I'll fit very comfortably into foundational system development. I can't really see myself writing end-user-facing stuff too often, but I instead wanna make the tools and libraries for developers, focusing on accessibility, ergonomics, and correctness (and performance).
Comments
But getting that usable by Node or Deno or Bun programmers continues to require significant artisanal extra. Really hoping for a stronger polyglot future emerged.
But in practice, your function type syntax needs every bell and whistle from your declaration syntax :)
As in “I only want Easy Rust” so you’re only allowed nonmutable variables and no pattern matching to solve a small exercise.
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.
https://bsky.app/profile/shriram.bsky.social/post/3lk5es5i7js25
https://bsky.app/profile/shriram.bsky.social/post/3lk4t4vjhbc2p
https://arxiv.org/abs/2110.01098
i agree that it's hard and maybe truly impossible in some circumstances
I'm writing a stdlib for SML in which exceptions and partial functions are forbidden, and it's hard even when you only use linked data structures.
When you use arrays, it's hopeless, unless you have dependent types.
It's practicality over strict correctness.
Fans of other languages have their own ideas on this topic, e.g., "Test pass? Ship it!"
You don't get to advertise "provable correctness" without delivering provable correctness.
This should be doable in the Rust *language*, but the existing standard library doesn't make it easy, to say the least.