3 ms·

Although I agree with almost everything you said, I still feel rust is a general purpose language. Most programming projects are single thread, not async, and

Although I agree with almost everything you said, I still feel rust is a general purpose language. Most programming projects are single thread, not async, and if you aren't juicing for performance, is pretty easy to write. Even in rust. I think what makes writing rust for general purpose projects hard, is knowing you can do something better that doesn't have to be better.

armchairhacker 4y ago
Yeah I get that Rust tries very hard to be general-purpose. It also has a great ecosystem, has rare features like proper ADTs/macros and no annoying backwards-compatible quirks, and its one of the best languages for WebAssembly. So there are reasons you might want to write something in Rust that doesn't need to be low-overhead. But even when you're doing everything single-threaded with Rc and RefCell and Box<dyn>, you can still run into pitfalls. More significant, when you do this your code becomes incredibly verbose. You have to constantly specify over and over again you're doing this the high-overhead way and not the weird optimal way, it gets annoying. Honestly I think Rust should have an "easy mode", where you everything is implicitly wrapped in ARC / dyn / mutex, and when you write code it's almost like you're working in a truly general-purpose "regular" language. Except it interfaces perfectly with regular Rust and compiles to Rust, so you can still use your favorite cargo packages and even jump into real Rust when you need to. The issue with that is Rust is already stretching itself kind of thin. So this "easy mode" has to be implemented so it's very simple and you can completely ignore it if you want. Maybe it will just be adding better FFI support to Rust, or maybe it will be another ambitious language like Rust but has better support for implicit easiness.

3 ms·

Although I agree with almost everything you said, I still feel rust is a general purpose language. Most programming projects are single thread, not async, and

by crabbygrabby 4y ago

armchairhacker 4y ago
Yeah I get that Rust tries very hard to be general-purpose. It also has a great ecosystem, has rare features like proper ADTs/macros and no annoying backwards-compatible quirks, and its one of the best languages for WebAssembly. So there are reasons you might want to write something in Rust that doesn't need to be low-overhead. But even when you're doing everything single-threaded with Rc and RefCell and Box<dyn>, you can still run into pitfalls. More significant, when you do this your code becomes incredibly verbose. You have to constantly specify over and over again you're doing this the high-overhead way and not the weird optimal way, it gets annoying. Honestly I think Rust should have an "easy mode", where you everything is implicitly wrapped in ARC / dyn / mutex, and when you write code it's almost like you're working in a truly general-purpose "regular" language. Except it interfaces perfectly with regular Rust and compiles to Rust, so you can still use your favorite cargo packages and even jump into real Rust when you need to. The issue with that is Rust is already stretching itself kind of thin. So this "easy mode" has to be implemented so it's very simple and you can completely ignore it if you want. Maybe it will just be adding better FFI support to Rust, or maybe it will be another ambitious language like Rust but has better support for implicit easiness.