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'm not joking. If you want something that's very similar to Rust, but doesn't have the restriction of being a systems language, then Haskell might be the right thing for you. Unlike Rust, Haskell is Pure Functional though, so it forces you to have an even cleaner architecture.
If Pure Functional isn't your beer, then you could also check out the language that inspired Rust: ML. If I remember correctly, Rust was started as "something similar to ML, but suitable for systems programming". So, it only feels natural to take an ML dialect if you want "something similar to Rust, but without the restriction of it being suitable for systems programming".
A popular ML dialect would for instance be F#, which is built on top of the .Net runtime and is therefore compatible with C# and the likes. On the other hand, in order to make it compatible with C# and the likes, there are some weird compromises in F#...
Or, if you (like me) dislike the idea of having a Garbage Collector, you could go for Lean4. That's what I'm learning currently, and it feels a bit like a bastard child of Haskell and ML.
have an even cleaner architecture
Although I'm fully in camp functional, I doubt that. There are problems that are inherently stateful and rely on mutability. Modelling that in Haskell often results in unnecessary abstractions. I think Rust hits a sweet spot here (when you're that experienced to write idiomatic Rust, whatever that exactly is). Also being lazy by default has its own (performance) implications, strict + lazy iterators (like Rust) is a good default IMO.
I did mention ML, of which OCaml is a dialect. Afaik Elm doesn't have type classes (aka Traits) - a property I would consider necessary to call it "similar to Rust".
OCaml seems really close, but I'm told that there are problems with its concurrency story. I do think it sounds like a really good language.
I'm curious if you were told that recently. I know that there have been stable releases of major features and libraries concerning concurrency and parallelism near the end of 2022. It may be much improved since you your source last looked. Or it could be a limitation in the implementations of these.
My understanding was that there's some ecosystem bifurcation, somewhat like Rust's. But I'll look into it again!
Oh, yeah. The Jane Street vs non-Jane Street library incompatibilities still exist. But there is a new concurrency library that was made such that the need to use monads has been eliminated.
I do want to learn Haskell some day, but it seems like it has a whole different set of reasons why it's tricky to learn; and I hear enough about the more complex features (e.g. arrow notation) having compiler bugs that I think it really doesn't sound like a "smaller" or "simpler" language than Rust.
That said, yeah, it definitely meets the criteria of having strong typing, a functional style, a garbage collector, and pretty good performance.
You mean a interpretative language with similar role to Python, but more like Rust/C++ style? I actually want that so that I can ditch Python even if I learned it and use this instead.
Not necessarily interpreted, but possibly. I think a more likely path is something like Go that's compiled but still has a garbage collector.
If you use a garbage collector the whole borrow checker would not make any sense.
Do you want to have error handling and functional paradigms in go? I think you should start there and ask go Devs why their language is lacking such basic stuff.
Not sure if this is what OP is seeking, but I would be fine to have borrow checker removed, replaced with Garbage collector like Go/Python in such a language.
To build prototypes, I don't want to fight with borrow checker and neither I care for efficiency much. But I do want the macro system, traits, lazily asynchronous runtime, cargo like package manager, easy build system, etc.
Rust has so many powerful features, but only because of borrow checker (IMO) we can't use it for rapid prototyping like Python. With that replaced, this subset of Rust would be something which can be a great contender to Python/Go, etc.
The borrow checker handles more than just freeing allocated memory, it will also prevent data races and invalid concurrent access aso. I personally don't have any issues with using garbage collected languages, but the fearless concurrency is nothing I'm willing to give up.
Oh, I agree.
My worst experiences with Python are related to running multiple processes of which share anything. Rust was far easier in that.
Looks like interpreted Rust would be my only demand for Rust to shine in prototyping world.
Did you read the original "Notes" post? I thought it did a pretty good job of explaining why Rust-like ownership semantics are not necessarily at odds with having a garbage collector.
I think I saw something called 'Rune' that might fit the criteria pretty well. I didn't dig really deep.
can have a nontrivial (or “thick”) runtime and doesn’t need to limit itself to “zero-cost” abstractions.
Wouldn't that be a bigger rust rather than a smaller one?
Not an area I'm particularly interested in, given that I do embedded and hard realtime development. Rust is the best language for that now, I just which allocations were fallible as well. And storage/allocator API was stabilised.
Not unless you consider Go a "bigger" language than Rust. The blog post means "smaller" in terms of what the user has to learn and think about, rather than smaller in implementation size or resulting binary.
I would indeed consider Go a bigger language, because I do indeed think in terms of the size of the runtime.
But your way of defining it also makes sense. Though in those terms I have no idea if Go is smaller or not (as I don't know Go).
But Rust is still a small language by this definition, compared to for example C++ (which my day job still involves to a large extent). It is also much smaller than Python (much smaller standard library to learn). Definitely smaller than Haskell. Smaller than C I would argue (since there are leas footguns to keep in mind), though C has a smaller standard library to learn.
What other languages do I know... Erlang, hm again the standard library is pretty big, so rust is smaller or similar size I would argue. Shell script? Well arguably all the Unix commands are the standard library, so that would make shell script pretty big.
So yeah, rust is still a pretty small language compared to all other languages I know. Unsafe rust probably isn't, but I have yet to need to write any (except one line to work around AsRawFd vs AsFd mismatch between two libraries).
Go is a "small" language in the sense that it has an exceptionally small number of concepts (i.e. features and syntactic constructs); someone else in this thread made a comment to the effect that it takes almost no time to learn because there's nothing to learn if you've already learned a different language. This is of course an exaggeration, but only slightly: Go was very intentionally and explicitly designed to be as simple as possible to learn and to use. As an example, it famously had no support for generics until almost 10 years after its 1.0 release. I think that when talking about the size of a language, some people do include the standard library while others don't; Go has quite a large standard library, but you don't actually have to learn the whole library or even be aware of what's available in order to be productive.
I personally don't think it makes sense to include the standard library in the "size" of a language for the purpose of this thread, or Boats' original blog posts. The fundamental point is about the learning curve of the language and the amount of work it takes to produce working code, and a large standard library tends to be more convenient, not less. Common functionality that isn't in Rust's standard library tends to come from libraries that become almost ubiquitous, such as serde, regex, crossbeam, and itertools. From the user's perspective, this isn't much more or less complicated than having the same functionality available via the standard library. (Of course, a large standard library certainly makes languages more difficult to implement and/or specify; if I recall correctly, about half the size of the C++ standard is dedicated to the standard library.)
I don't really know how to fairly compare the "size" of Rust and C++, partly because Rust is so much younger, and several C++ "features" overlap with each other or are attempts to replace others (e.g. brace-initialization as a replacement for parentheses). But I don't think I've ever heard someone claim that C++ is "small" or "minimal" in this sense, so it's in no way a good point of comparison for determining whether Rust is "small".
Edit to add: for what it's worth, if I weren't quoting Boats' blog post (which is sort of the "canonical" post on this concept), I probably would have opted for "simpler (to learn & use)" rather than "smaller."
