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

[–] Reptorian 6 points 10 months ago (1 children)

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.

[–] BatmanAoD 2 points 10 months ago (2 children)

Not necessarily interpreted, but possibly. I think a more likely path is something like Go that's compiled but still has a garbage collector.

[–] [email protected] 10 points 10 months ago (3 children)

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.

[–] [email protected] 7 points 10 months ago (1 children)

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.

[–] [email protected] -1 points 10 months ago

Sounds like you're using C# for something that it wasn't designed for. You can, of course, but it is obviously painful

[–] 80avin 3 points 10 months ago* (last edited 10 months ago) (6 children)

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.

[–] snaggen 12 points 10 months ago (1 children)

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.

[–] 80avin 5 points 10 months ago

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.

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

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.

[–] [email protected] 5 points 10 months ago* (last edited 10 months ago)

To build prototypes, I don't want to fight with borrow checker and neither I care for efficiency much. But I want [rust features]

Maybe we just need a preprocessor that adds clone, reference counting and RefCell wherever needed.

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

To build prototypes, I don’t want to fight with borrow checker and neither I care for efficiency much.

Then use .clone() or Arc everywhere?

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

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

[–] [email protected] -2 points 10 months ago (1 children)

Then Rust is the wrong language for you. Use the right tool for the right job.

[–] 80avin 2 points 10 months ago

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.

[–] BatmanAoD 1 points 10 months ago

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.

[–] [email protected] 2 points 10 months ago* (last edited 10 months ago) (1 children)

F#? It's compiled, statically typed, somewhat fast, garbage-collected, and supports Rust-style error handling

[–] BatmanAoD 2 points 10 months ago

Definitely a good pick! I haven't learned it but I'm aware of some of its features, and it does seem promising.