Rust

5981 readers

101 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

[email protected]

Credits

The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago

MODERATORS

[email protected]

Who's working on a "smaller Rust"? (programming.dev)

submitted 10 months ago* (last edited 10 months ago) by [email protected] to c/[email protected]

63 comments fedilink hide all child comments

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

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 4 points 10 months ago

Jeeze, I knew that simplicity was the goal (and I think they largely succeeded in that), but that quote is so explicitly condescending. "They're not capable of understanding a brilliant language"?

I disagree slightly with the need to add full ADT support to the language to implement that style of error handling, because Pike et al. had no problem adding "special cases" to the language: in particular, return values are essentially tuples, but that's the only place in the language with that concept. So they wouldn't need to introduce user-definable enums and full pattern-matching to have better error handling. I can think of a couple approaches they could have used:

Use compound-return-values as they currently exist, but have additional compiler-enforced restrictions:
- There can be at most one error value in the return types, and it must be the last element in the "tuple"
- when returning a non-nil error, the other values must be zero/nil
- the compiler would require all errors to be checked, never ignored (Go should have at least done this, even without the other stuff)
- Add the question-mark operator, which would do basically the same thing as in Rust: check if the error value is nil, discard it if so, return early if not
Have a special "result" type that is quasi-generic (like slices and maps) and treated as a sum-type by the compiler, but which can only be used as a return value from functions. Provide some special variant of the switch statement to destructure it (akin to how type switches have their own bespoke syntax/keyword).