For a new project we're looking for the pro's and con's of either C++17 and Rust. The project will make use of some very common libraries like LevelDB, LLVM, v8 Engine, and depends heavily on network support. Most of those projects offer an native C++ binding. However Rust seems to be more clean, better compiler support, build system and not least a package manager. This could save much in terms of development time.<p>So far I have not found a good reason to choose one over the other. We do have C++ experience in house. Any advise?
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++.<p>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.<p>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.<p>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.
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.<p>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.<p>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.<p>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.