this post was submitted on 11 Jan 2024
34 points (87.0% liked)

Rust

6046 readers
6 users here now

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

Wormhole

!performance@programming.dev

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
snowe@programming.dev
Ategon@programming.dev
EdTheLegendary@programming.dev
kahnclusions@programming.dev
torcherist@programming.dev
34
Who's working on a "smaller Rust"? (programming.dev)
submitted 10 months ago* (last edited 10 months ago) by BatmanAoD@programming.dev to c/rust@programming.dev
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
[–] asdfasdfasdf@lemmy.world 19 points 10 months ago* (last edited 10 months ago) (2 children)

I didn't love that article - Rust isn't strictly a systems language. It's general purpose, and a lot of the mechanics are very useful for general programs.

[–] BatmanAoD@programming.dev 7 points 10 months ago* (last edited 10 months ago) (1 children)

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 points 10 months ago (1 children)

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
[–] BatmanAoD@programming.dev 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).
[–] porgamrer@programming.dev 4 points 10 months ago (1 children)

Rust is a groundbreaking language, but it's not without tradeoffs. There are loads of things it makes extremely difficult compared to slightly higher level languages.

I used it happily for years, but I wouldn't recommend it for any project that didn't explicitly need the low-level performance optimisation.

[–] asdfasdfasdf@lemmy.world 9 points 10 months ago (1 children)

Extremely hard disagree on the last statement. It certainly has tradeoffs, but they are almost all very valuable to many general applications which don't need performance at all. I've been using it professionally for a very long time now and migrated multiple companies from JS, Python, Java, and C# to Rust and it brought huge advantages.

[–] porgamrer@programming.dev 4 points 10 months ago (1 children)

I believe you, but for it to be a fair comparison you'd need to compare to an alternative rewrite, not to the original software.

Rust has plenty of merits. It has a very readable functional style, single aliasing to reduce complexity, powerful libraries for stuff like generating serialisation code, and cargo is incredible.

However, expressing any complex graph structure in Rust is just painful, and so is refactoring code. Small changes in intent require complex reworking of data structures, because Rust forces you to be extremely specific about data layouts at all times. These issues crop up constantly in any complex project, and they really slow things down.

Although Rust is a nice language, you can now write functional code with immutable data structures in pretty much any modern, statically-typed language. C#, Kotlin, Scala, Swift, etc. It will be concise, quick to write, easy to modify and pretty fast at runtime.

Perhaps I'm mistaken in some way, but this has been my honest experience after many years using Rust.

[–] asdfasdfasdf@lemmy.world 5 points 10 months ago* (last edited 10 months ago) (1 children)

That hasn't been my experience at all, and it's been for both large refactors as well as complete rewrites.

Rust does care about some things like not having self referential structs or recursive types, but those are super easy to fix. Rust pushes you to not write code in the same way as other languages, and IMO that's a very good thing. It's not at all about systems stuff or memory layouts.

Rust's ownership system is used to simply enforce correct usage of APIs. Memory safety is simply a subset of correctness. Many other languages, Java for example, don't enforce thread safety, so you have to be really careful when parallelizing your code. In Rust, you could hire an intern fresh out of high school and I can know 100% that they're not making mistakes with sending data across threads that isn't thread safe.

Another example is file handles. Rust is the only mainstream language where it's not possible to read from a file handle after it's been closed. That has nothing to do with memory layout or systems concerns. That's a basic invariant across all languages, and Rust stops you from making a mistake. Same with things like mutating an iterator during iteration and all kinds of other stuff.

That does mean it is more painful upfront, but that's a good thing. You'll run into many of the same problems in other languages, but at runtime, which is much worse.

As for graphs, I doubt the vast majority of programmers need to build custom graph structures.

You're of course free to disagree. Just weighing in with my perspective.

[–] porgamrer@programming.dev 5 points 10 months ago

I appreciate your perspective, thanks for taking the time to share it!

I also agree with most of your points in favour of Rust. It is clearly the biggest programming language design breakthrough in decades.