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
I guess we’re coming at this with different opinions on what is convenient. Python is extremely easy and quick to write - but then writing more code for tests than the actual program itself because the compiler catches next to nothing and still dealing with the occasional runtime error is highly inconvenient to me. I look at the “ease of use” - or painlessness if you will - of a programming language over the whole lifecycle of the program, not just initially writing it.
Initial development is like 2% of the total effort over the whole lifecycle of a program, at most. The vast majority of time is refactoring, troubleshooting, changing, testing, building, deploying, monitoring… and so on. With Rusts strong type system, I will probably spend 30% more time developing than with an easier language like Python/Go/Kotlin, but I will save 300% of time debugging, troubleshooting, deploying. Moreover, writing code is something I enjoy, while debugging is something I’d rather avoid. Any language that enables me to spend less time teoubleshooting runtime errors and debugging edge cases is a desirable language for me.
What would you consider a convenient language, and why?
I completely agree with almost everything you wrote (though from my limited experience of Kotlin it seems much less prone to the types of bugs you’re describing than Python and Go). That’s why, of the languages I know, I prefer Rust for pretty much every task (except shell scripting, for which I honestly don’t like any of the available options).
But I think Boats is right that there’s room in the language design space for a language that does make some sacrifices in favor of convenience, while still maintaining most of the correctness benefits of Rust.
Consider the case of
async: Rust’s design was constrained by the need to not have an execution runtime built into the language, and a desire to be able to use async code in embedded environments without an allocator. The result is honestly an engineering marvel, and amazingly ergonomic given those constraints. But it’s full of rough edges and tricky corner-cases: on the language user side, execution engines have fractured the ecosystem, and on the implementation side, it’s a slow and arduous process to make all the other Rust language features play nicely with async (as evidenced by the fact that we only just recently got support for async in traits, and it’s still very limited).Those difficult requirements are not due to Rust’s goal of being highly reliable and maintainable; they’re due to the separate goal of Rust being usable anywhere C or C++ is usable. So what would a language look like that values maintainability strongly (maybe not quite as strongly as Rust, but nearly so), without being required to work on all embedded platforms or run without a garbage collector?