34
Who's working on a "smaller Rust"?
(programming.dev)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 11 Jan 2024
34 points (87.0% liked)
Rust
6130 readers
77 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 2 years ago
MODERATORS
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.
I spend an inordinate amount of time at my C# day job adding documentation comments about exclusive access and lifetimes and ownership… things which are clearly important but which dotnet provides little or no useful support for, even though it has a perfectly good garbage collector. The dotnet devs were well aware that garbage collection has its limits, especially when interacting with resources managed outside of the runtime, and so they added language features like IDisposable and finalisers and GCHandle and SafeHandle and so on to fix some of the things GC won’t be doing for you.
I’d happily use a garbage collected language with borrow checking.
Sounds like you're using C# for something that it wasn't designed for. You can, of course, but it is obviously painful
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.
Honestly, prototyping is exactly the kind of thing where I don't want to think about all the crap that Python doesn't check itself while Rust does. In a long-term project I could begrudgingly learn every data structure and process well enough to do the compiler's job for it but if the code is very new or changes constantly I want as much support from the compiler as possible to avoid having to remember all of that.
Maybe we just need a preprocessor that adds clone, reference counting and RefCell wherever needed.
Then use
.clone()orArceverywhere?Why would you want to prototype incorrect code? You don't fight with the borrow checker. The borrow checker prevents stupid mistakes. Anything that is correct that the borrow checker rejects is almost certainly a very bad idea in a prototype
Then Rust is the wrong language for you. Use the right tool for the right job.
Yes, and that's what the post is about.
Saying that Rust is not the right tool for this job, what other tools exist which are similar to Rust but also do the job.
I don't have the answer though. Just came to add my thoughts.
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.
F#? It's compiled, statically typed, somewhat fast, garbage-collected, and supports Rust-style error handling
Definitely a good pick! I haven't learned it but I'm aware of some of its features, and it does seem promising.