
Ask HN: C++17 vs. Rust for New Project - Dinux
For a new project we&#x27;re looking for the pro&#x27;s and con&#x27;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?
======
notmainacct
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.

~~~
Dinux
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.

~~~
Someone1234
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.

------
davismwfl
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.

