Who are the main developers who will be working on this project? If the developers are largely used to Node, or Ruby, the package management, and language features might make them more comfortable, and if they are not comfortable with C++ already, the Rust learning curve might be negligible compared to some of the oddities with C++.

If you have developers coming from languages like Java or C# which have a structural similarity to C++, or if you have developers already familiar with C++, I would say that there is no need to throw that experience away, and that experience would get you guys farther than trying the new language.

In my experience, the clang compiler is very developer friendly in terms of error reporting and features. The only people that I know that say that C++ is old and clunky were those using gcc and C++98. Make is pretty open ended as a scripting tool/build tool, and there are plenty of alternatives if you don't like make.

I would choose based on demographics of your team. If you have a bunch of young developers, or if you want to hire a bunch of young developers, Rust is pretty popular with that crowd, and has a lot of language features that will make them feel comfortable. That being said, I only recommend Rust if you have a developer that is very comfortable with it, and can guide you through the borrow checker, whether to use stable or nightly rust, and the foreign function interface. C++ will require more discipline because there is less constraints that prevent you from shooting yourself in the face with code readability and memory safety, but it is proven, and if you have the C++ developers on hand, have them decide on a style guide and review process that works for your team.

The team has some experience with C# and Java which makes it easier to go with C++, an then there is a little knowledge of C++17. I think from this perspective its clear that C++ would be the better choice in our case.

I may be misinformed but from what I've seen so far is that Rust crates can be super beneficial and speedup development (where there is an obvious lack of a well-established package manager for C++), but neither Google nor any of the other major C++ shops do provide a Rust <-> C++ lib bridge. For example there does not seem to be official Google support for the v8 engine/leveldb under Rust forcing me to thrust a single Crates maintainer doing some porting in his free time.

The problem I've run into (YMMV) with C++ is that a lot of documentation/information is outdated (dangerously so).

C++ isn't a single language, it is three major revisions (98, 11, and 17) of a similar-ish language. If someone used C++ continuously throughout its evolution this is a non-problem. Because they were able to slowly adapt their knowledge, while still having the ability to mix and contextualize.

For new people entering the language "just use C++17" is largely a fiction. Because the first time you look at stackoverflow, a tutorial, or GitHub code all bets are off. And a lot of developers end up in interop hell because they're trying to get to C++98/11 structures to work with C++17 ideas.

I don't actually agree that C#/Java gives an advantage to C++17. In fact I think the reverse. The syntax is similar, but syntax is relatively minor in the grand scheme. Rust, once you get past syntax, is much more similar to high level language because you aren't wandering through the memory management minefield.

Just my 2c.

PS - I don't "hate" C++. But you cannot just jump straight to C++17 while pretending C++ 98/11 don't exist. You have to learn all three, and then learn not to use the first two, otherwise you wouldn't understand most of the information available to you (and most libraries you're interopping with are writing in a dialect you don't understand). Learning C++ for real is a huge under-taking.

Why would that make C++ easier?

If anything, Rust generics are more familiar vs. templates

A few comments which are just my opinions. First, I'd argue both languages will solve similar problems fairly equally in terms of outcome & performance. But if you have C++ knowledge on the team already it should be the default unless there is proven reasons to move away. This isn't because I don't think teams should learn new things, but when the business is trying to make money or get started that is not the time to risk a project on learning a new language.

If you haven't already worked in Rust and haven't already done POC's in Rust now isn't the time to risk a project on experimenting. You could take a small portion of the project and do a test in both languages to see the pros and cons. I'd probably not put a ton of weight on the implementation time difference here (unless it is large) because Rust might take you slightly longer just to figure out the differences but that isn't a negative and would quickly pass. And when you pick the portion of project do not unfairly bias the test towards either language, that is easy to do to bias the outcome.

If this is a vital system where failure has negative consequences for the company I'd argue again you go with C++ which seems counterintuitive initially but makes sense. With Rust the team will be learning so the number of mistakes and rework will be higher initially. The team is already C++ experienced so they understand its worts and issues, and all languages have issues. So the first result will mean the C++ software will likely be more solid than the Rust version, not because of language capabilities but because of experience in the coders. If the system isn't vital, can accept more risk and is smaller I'd go with Rust, simply because that is the perfect time to experiment.

TL;DR; don't bet a non-trivial project the company is needing to help grow or profit on a new language when the team hasn't already proven competency on smaller test projects in the language.