Hacker News new | ask | show | jobs
by not-my-account 862 days ago
In which ways does Rust need to improve, in your opinion?
3 comments

I'm fond of rust, but compared to go, I dislike that you need a different code path to support sync vs async in a module. Or pick a different runtime like Tokio. So you end up with modules that are async only, sync only, or both.

Makes me miss go, which has channels build in, has a runtime built in, and both are generally solid. None of use flavor A for this, use flavor B for that, or write wrappers for the wrong color function.

Rust has channels built in. In fact, the std channels were recently rebuilt on top of the excellent crossbeam crate.

Function colors is kind of a meme but maybe-async functions are coming.

https://lib.rs/tokio is king for std environments, https://lib.rs/embassy for no_std.

Yes, MPSC, single consumer which is limiting.
Oh.

    cargo add crossbeam-channel
Compile time, async, steep learning curve are things that come to mind
I’ll add, thanks to their age, C and C++ have more compatibility with boards, OS’s, GUI’s, libraries you might need, etc. Especially in embedded, you have way more options if using or hiring for C/C++. There were also more tooling for analyzing the C/C++ software but they often cost $$$.

For common scenarios and platforms, Rust’s library situation did get way better really quickly.

Thank you
Here we go. I'm not taking this bait.
I’m not trying to bait you, and people who attack you for what you say are morons.

I don’t have much experience in either language, and I don’t have an opinion on which is better. I am just interested in your opinion.

I understand your hesitation, but I’d really appreciate your take, given you seem to know your stuff.

Personally I think the sibling comment is pretty accurate, and rust is held back by:

- slow compiling of larger projects

- async stuff can quickly lead to very complex shenanigans

- embedded still requires you to write HAL stuff for MCUs that is supported out of the box for C