Almost five years ago, Saoirse “boats” wrote “Notes on a smaller Rust”, and a year after that, revisited the idea.

The basic idea is a language that is highly inspired by Rust but doesn’t have the strict constraint of being a “systems” language in the vein of C and C++; in particular, it can have a nontrivial (or “thick”) runtime and doesn’t need to limit itself to “zero-cost” abstractions.

What languages are being designed that fit this description? I’ve seen a few scripting languages written in Rust on GitHub, but none of them have been very active. I also recently learned about Hylo, which does have some ideas that I think are promising, but it seems too syntactically alien to really be a “smaller Rust.”

Edit to add: I think Graydon Hoare’s post about language design choices he would have preferred for Rust also sheds some light on the kind of things a hypothetical “Rust-like but not Rust” language could do differently: https://graydon2.dreamwidth.org/307291.html

  • BatmanAoD@programming.devOP
    5·
    9 months ago

    I feel like you may have missed the point, then? Or at least interpreted the article very differently? Rust isn’t “strictly” a systems language, but neither is C or C++; people use them for application development all the time. But all three languages have very specific limitations (most obviously, that adding a garbage collector would be an unwelcome change) imposed by the need to fulfill the “systems” niche.

    Compare Golang: it can’t replace C++ for every use-case, because it has a garbage collector, and because you need cgo to use FFI. But it’s otherwise a very flexible language that can be used for most types of software.

    What I would like to see is something that shares these advantages with Go:

    • quick to build
    • easier to teach & learn than Rust
    • easier to quickly prototype with than Rust (though of course it’s debatable how well Go does at this one)

    …but I don’t like the actual language design of Go, and I think it’s possible to design a language that’s more Rusty but still simpler than actual Rust.

    For instance, error handling in Rust is both more ergonomic and more rigorous than in Go. That’s huge! A language like Go but with sum types, Result, and the question-mark operator would be leaps and bounds nicer than Go itself.

    To be clear, I don’t imagine that a “smaller Rust” would replace Rust. But I also don’t think we’ve reached optimal language design when the language I’d pick to write an OS is also the language I’d pick to write a small CLI app.

    • crispy_kilt@feddit.de
      1·
      9 months ago

      The designers of Go actually discussed civilised error handling (like Rust and others), but in order to make it useful they’d have to include other features like ADTs and something like an Either monad (Result type), which they felt would make Go too difficult to learn for the developers they envisioned Go to be used by.

      One of the most important reasons for the popularity of Go is exactly that it is extremely limited, and can be picked up by any developer in a few hours. It takes no time to learn because there is nothing there that would need to be learned. This isn’t a limitation, it’s a feature (opinion of Go designers, not mine).

      The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

      • Rob Pike