4 ms·

So what exactly is the "much smaller and cleaner language struggling to get out" of Rust? If I'm understanding the post right, that language still has reference

So what exactly is the "much smaller and cleaner language struggling to get out" of Rust? If I'm understanding the post right, that language still has references, lifetimes, traits, enums, etc., because all of those features cohere; you can't remove just one and expect the rest of the language to still work. Once you grant all those features, your language isn't much smaller or cleaner than Rust; your language pretty much is Rust. The last section gives two different hints as to what this "smaller and cleaner" language might be, but neither of them fully makes sense to me. First, withoutboats's "Notes on a smaller Rust". That post and especially its sequel are great and I like them a lot, but the title is fairly misleading as to what they're getting at. The language that boats sketches out in those posts has significantly different design goals from Rust; in particular, it abandons the requirement of low-level programmer control over runtime behavior, and so is unsuitable for many use cases that Rust is used for. The idea, rather, is to explore what lessons Rust can offer for the design of a language with more "mainstream" requirements (i.e., one that can afford things like a tracing garbage collector, and wants to avoid Rust's downsides compared to other popular languages, like slow compile times and heavy syntactic salt). That language is not "struggling to get out" of Rust; Rust doesn't want to be it. Second, "In a manner of speaking, that smaller Rust is the language I fell in love with when I first learned it in 2018. Rust is a lot bigger today, in many ways, and the smaller Rust is just a nostalgic rose-tinted memory." I've explained above why I don't think boats's proposed "smaller Rust" is anything like the real Rust was at any point in its history (at least after the very early days, once the designers figured out that they were targeting C++'s niche). In most fundamental respects, Rust hasn't changed that much since 2018, and a lot of the changes (like the new editions) are about making it more syntactically flexible and increasing the fraction of sensical programs that compile. That said, there are two big exceptions: async and const, which were much more minimal in 2018 and have since expanded to big complex meta-features with many interlocking parts that weren't part of the language's original core. If the claim is specifically that Rust was smaller and cleaner before async and const, then by all means, say that! But the post doesn't, leaving us to try to figure out what was meant.

zozbot234 1y ago
> So what exactly is the "much smaller and cleaner language struggling to get out" of Rust? Austral? https://austral-lang.org/features https://austral-lang.org/features
- ameliaquining 1y ago
  This doesn't strike me as much simpler than Rust; it has most of the features listed above. I know a lot of people don't like RAII (which Rust has and Austral doesn't) because they want every function call to be visible at the call site, but replacing that with linear types, whatever their other virtues, does not make the language easier to learn; implicit destructor calls aren't hard to understand as a concept, once you've got your head around the notion of a value with a specifically bounded lifetime, whereas fighting the linearity checker seems likely to be an even greater speed bump for new users than fighting the borrow checker (which Austral still has).
jynelson 1y ago
you were reading very closely, well done. yes, that is my claim, Rust was smaller and cleaner before async and const. I was so indirect about it because many of my best friends work on those features and I wasn’t sure how to word it. fortunately Matklad has worded it very well on the other site: 2015 rust was a more complete language that cohered better, but the vision of Rust is not to cohere perfectly, it’s to be an industrial language that is useful even if it’s not beautiful. https://lobste.rs/c/b8kevh https://lobste.rs/c/b8kevh
- ameliaquining 1y ago
  Yeah, in that case I think the link to boats's work obscures the point a bit. I take what might be a slightly different read of matklad's point; I don't think Rust has much compromised its vision in terms of which broad features to support, but it has on a couple occasions chosen to ship something that wasn't perfect because being useful requires taking only a bounded amount of time to iterate on design. So Rust 1.0 shipped without async, even though it was known to be needed for some of Rust's core use cases, because it was too far from being ready and it wouldn't do to wait forever. Once that decision was made, it had implications for how async could work; in particular, really doing it right requires linear types, but this wasn't appreciated when Rust 1.0 shipped and it's not a backwards-compatible change, so by 2018 it was off the table. The choice was, do async in a way that works with the existing design decisions, at the cost of some elegance, or don't do it at all. The former choice is not just more "industrial", I would argue that it coheres better, because waiting for multiple events at the same time is a core feature that a language for foundational software has to have, and the combinator-based approach that people were using in 2018 cohered poorly with the rest of the language (e.g., requiring unnecessary heap allocations). So this wasn't really a compromise to coherence. (This also happened on a lesser scale when async/await first shipped—e.g., specific "async" syntax instead of a more general coroutine feature—because of eagerness to ship something that year. boats has claimed that this was a matter of existential survival for the language; I'm not sure I agree. But while async/await is a bit less conceptually pure than fully general coroutines, I don't believe that any of today's common complaints about async are downstream of the decision at that time to try to ship something quickly; there don't seem to have been a lot of obvious mistakes from then.) (My understanding is that const has a similar story but I'm less familiar with the design space there, because people haven't exhaustively chronicled its history like they've done with async, perhaps because it's not as heatedly controversial.)

zozbot234 1y ago

> So what exactly is the "much smaller and cleaner language struggling to get out" of Rust? Austral? https://austral-lang.org/features https://austral-lang.org/features

ameliaquining 1y ago
This doesn't strike me as much simpler than Rust; it has most of the features listed above. I know a lot of people don't like RAII (which Rust has and Austral doesn't) because they want every function call to be visible at the call site, but replacing that with linear types, whatever their other virtues, does not make the language easier to learn; implicit destructor calls aren't hard to understand as a concept, once you've got your head around the notion of a value with a specifically bounded lifetime, whereas fighting the linearity checker seems likely to be an even greater speed bump for new users than fighting the borrow checker (which Austral still has).

jynelson 1y ago

you were reading very closely, well done. yes, that is my claim, Rust was smaller and cleaner before async and const. I was so indirect about it because many of my best friends work on those features and I wasn’t sure how to word it. fortunately Matklad has worded it very well on the other site: 2015 rust was a more complete language that cohered better, but the vision of Rust is not to cohere perfectly, it’s to be an industrial language that is useful even if it’s not beautiful. https://lobste.rs/c/b8kevh https://lobste.rs/c/b8kevh

ameliaquining 1y ago
Yeah, in that case I think the link to boats's work obscures the point a bit. I take what might be a slightly different read of matklad's point; I don't think Rust has much compromised its vision in terms of which broad features to support, but it has on a couple occasions chosen to ship something that wasn't perfect because being useful requires taking only a bounded amount of time to iterate on design. So Rust 1.0 shipped without async, even though it was known to be needed for some of Rust's core use cases, because it was too far from being ready and it wouldn't do to wait forever. Once that decision was made, it had implications for how async could work; in particular, really doing it right requires linear types, but this wasn't appreciated when Rust 1.0 shipped and it's not a backwards-compatible change, so by 2018 it was off the table. The choice was, do async in a way that works with the existing design decisions, at the cost of some elegance, or don't do it at all. The former choice is not just more "industrial", I would argue that it coheres better, because waiting for multiple events at the same time is a core feature that a language for foundational software has to have, and the combinator-based approach that people were using in 2018 cohered poorly with the rest of the language (e.g., requiring unnecessary heap allocations). So this wasn't really a compromise to coherence. (This also happened on a lesser scale when async/await first shipped—e.g., specific "async" syntax instead of a more general coroutine feature—because of eagerness to ship something that year. boats has claimed that this was a matter of existential survival for the language; I'm not sure I agree. But while async/await is a bit less conceptually pure than fully general coroutines, I don't believe that any of today's common complaints about async are downstream of the decision at that time to try to ship something quickly; there don't seem to have been a lot of obvious mistakes from then.) (My understanding is that const has a similar story but I'm less familiar with the design space there, because people haven't exhaustively chronicled its history like they've done with async, perhaps because it's not as heatedly controversial.)