[allo37]

There has been a desire to use Rust where I work, but it's really hard to make a business case for "Hey, see this C/C++ code that's worked well for years if not decades? Let's rewrite it in a whole new programming language!". I wonder if it's the same story elsewhere?

[biorach]

In general rewriting a well functioning, battle tested C/C++ codebase in Rust is probably a bad idea.

[nindalf]

In general rewriting a well functioning, battle tested codebase is probably a bad idea.

But sticking to “battle tested” means a local minima at times. For example, there’s no shortage of CVEs in OpenSSL’s past or future. It’s definitely “battle tested”. And yet, that doesn’t mean someone shouldn’t try to write something better.

[marcosdumay]

Well, you said it was battle tested, but you didn't care to mention the battle results.

It may be a good idea to replace, or not. We don't have enough data to decide.

[Ygg2]

I disagree.

Even if Rust wasn't able to eliminate whole swath of errors in C(++). And it is (Nulls and data races).

Rust has way better package manager, and actually works on Windows.

For example coreutils got rewritten in Rust. And got adopted by Yocto.

[galangalalgol]

Just this week we were porting some old c++ over to rust, stuff from the 90s probably. It was relying on the last element of an array being zero due to null termination. It used that value in its computation. That sounds crazy but fine, except it wasn't an array of bytes, so if it wasn't aligned and padded to 4bytes that last value might not be all zeroes. I don't know a common arch outside of microcontrollers where it wouldn't work, but still!

[scruple]

What uC? I'm interested in learning which vendors are shipping rust toolchains for their chips.

[galangalalgol]

not using it on a uC, it did work in c++. Bounds checker caught it in rust. I was just postulating it might not work in c++ everywhere.

[scruple]

Ahh, gotcha.

[nickelpro]

Cargo is not de facto better than vcpkg. That Rust has a blessed package manager instead of community of competing package managers is a lateral, neither better nor worse.

[Ygg2]

Vcpkg? Never heard of it. 90% of C++ project I saw were using make. Remainder were using cmake.

> community of competing package managers is a lateral, neither better nor worse.

While I understand your position, that's not my opinion. Having one way to build a package is a blessing. Having had to juggle Python's competitive package manager is a nightmare.

https://imgs.xkcd.com/comics/python_environment_2x.png

Each one has slightly different usages and they are mostly compatible but then you run into edge cases.

-----

And lack of blessed libs is something I am strongly against.

Rust doesn't have standardized time lib and everyone is suffering for it.

[galangalalgol]

Except for grpc that uses bazel! I know two teams where I work, one uses vcpkg, but the other uses conan. Our company as a whole points to conan as the answer, but mostly everyone uses cmake and git submodules. That is why a single blessed package manager is better than many, none of them play well together. And that is ignoring hunter and meson. I don't know what the gp is talking about.