> Also, the C++ community is a lot more tolerant.

Yeah the biggest turnoff for me with Rust isn't even the language anymore, but the community surrounding it.

I realize it's mostly a vocal minority and the vast majority of Rust people, including the ones I know personally, are very nice. But boy are there some obnoxious Rust evangelists out there.

> Also, the C++ community is a lot more tolerant. A big plus for C++.

Well I completely disagree with this. The C and C++ communities seem to me personally to be a lot more "elitist", engaging in extreme pedantry or dunking on each other over knowing obscure language trivia. Both the language and the community are beginner-hostile in comparison to Rust.

Not that the Rust community is perfect, because it's obviously not - but lack of "tolerance" has never seemed like one of the problems it has.

This echos my personal experience as well.

I would also add that there now seems to be more of an emphasis around being intentional in how languages foster community. The C and C++ communities (in my opinion) became how they are not by design, but mostly by accident or chance.

Tolerant towards what exactly?

In which ways does Rust need to improve, in your opinion?

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

> I recently developed an oil and gas derivative tool in Rust

Sounds cool! Could you elaborate? Would you have a website somewhere? Do you have any contacts details?

Cheers!

can you share more about how/at what type of jobs you made a lot of money with c++?

> I made a lot of money with C++.

Please elaborate.