Live data from Hacker News

Ask HN: What is the state of C++ vs. Rust?

news.ycombinator.com

91–100 of 156 posts

Re: Ask HN: What is the state of C++ vs. Rust?

#91

Long time C++ dev here(~15 years) currently loving Rust. Someone can probably put together a more eloquent comment however here's my top marks. 1. No memory corruptions/null pointers. Legit holds up to the promises here. 2. The path of least resistance is single-ownership which is far and away the best way I've seen to structure C/C++ applications. 3. Cargo: Pure awesome. Simply one of the best dependency management/…

>I still work regularly on C++0x11 ... but that's not due for another year!

The C++ compiler teams have done heroic work to get their implementations on-track and have been ahead of the spec for several years now.

Many compilers are already supporting a number of C++17 features, and by the time the spec is out it might be almost complete for most major vendors.

http://en.cppreference.com/w/cpp/compiler_support

Re: Ask HN: What is the state of C++ vs. Rust?

#92
post #90

C is still significantly faster than Rust which follows that C++ is too. So unless Rust is able to produce binaries on all major platforms that are as fast as C++, people who need to squeeze out as much performance as possible are not going to drop the language.

Some people would prefer non-buggy, unlikely to crash code than fast but unstable and hard to debug code.

Rust's promise is if it compiles it's probably good code, as that compiler is exceptionally picky. Most common C++ errors that cause "undefined behaviour" are not possible due to the strict checking.

Re: Ask HN: What is the state of C++ vs. Rust?

#93
post #64
post #30

Earlier quoted context omitted.

I have just a couple of points. First, please be careful with the "experts" broad brush. Not all, and possibly not most, experts will agree on many things. Moreover, actual experts will understand that there are pros and cons that are context dependent. I would hesitate to label as "expert" anybody who categorically prefers one over the other for all cases. That's more like zealotry than expertise. Second, for my par…

The Rust team puts a lot of effort into not gratuitously maligning anything, including a "competitor" language like C++: discussions of other languages try to be as factual as possible, and, Rust is very happy to adopt the good ideas of them (and of course acknowledge this), e.g. Rust's closures are modeled after C++11's lambdas. As with anything, some people who like Rust might get a bit enthusiastic about discussin…

> The Rust team puts a lot of effort into not gratuitously maligning anything

Anecdotally, Rust developers are the only group I've interacted with that consistently focus on the positives of other languages when discussing different features or concepts, while acknowledging the tradeoffs and clearly outlining the reasoning behind Rust's choice.

Re: Ask HN: What is the state of C++ vs. Rust?

#94

Earlier quoted context omitted.

I'm not super-familiar with pip-tools however I'll try and explain what I like about Cargo. You're right on the dependencies, there's a lock file to make sure you get the exact build environment. So from a dependency management perspective it sounds similar. What I like about Cargo is it's just slightly opinionated about how you want to build a Rust project. Creating a new project is as simple as "cargo new myproject…

Ah, I see. The main difference I can see is that it's opinionated, because everything else can be done by pip too (you can install utilities right in your path with it). I agree that being opinionated is a big help. Everyone in Python-land uses virtualenv and pip, but it would be great if (as is actually happening now), they were bundled with the language and were the One Blessed way of creating a new project: virtua…

So you want to say that some arcane chain of commands that I have to remember is as good as `cargo run` to run `cargo install name` to install?

`pip` and Python are riddled with problems. Native modules fail to compile all the time and since Python is so slow, it requires a lot of native code. python2 vs python3 share `PYTHONPATH` and `virtualenv` is inheriting it: http://stackoverflow.com/questions/24583777/why-does-virtual... which leads to many weird problems.

Not to mention some python stuff is not available on `pip` (like PyQt, last time I tried).

Third, how (as a user) am I supposed to reliably install and start a Python software system-wide? With a whole `virtualenv`, or with a script that activates it every time? And what if you want to use one python program to run another python program and one is using python2 and other python3 etc? :D

Python software really works only in it's developer sandbox, or when very carefully prepared by Linux-distribution maintainers. Otherwise it's a mess.

Part of the reason why Docker got so popular was because it solved an impossible task of running several separate programs written in Python reliably side by side, on many boxes. Since it works reliably only in developer's sandbox, we now ship the whole sandbox and call it "application container".

I've gave up on using any software written in Python on my boxes. I just avoid it. Not to mention that Python software rarely works reliably...

Re: Ask HN: What is the state of C++ vs. Rust?

#95
post #3

This is all personal opinion so take it with a grain of salt. I think Rust could do some serious C++ competition if it could dethrone C++ from some platform or have a worthy alternative. That is I think Rust really needs a killer app/platform/problem similar to how Swift has Apple devices and DevOps now have Go. If Rust could get into a gaming platform or have a really good gaming library like Unity it could have a g…

> Alternatively I think Rust could compete heavily with Go since the whole microservices space is still sort of up for grabs (or atleast is so massive that there is plenty of pie to be had). I think you're wrong about this one. Go has a ton of HTTP libraries that make it dead simple to get a web service up and running with all the features you'd expect like pattern-matching URL routing, database backends, sessions, e…

I'm not a RUST chap, but came across this the other day:

http://www.arewewebyet.org/

I've done most of my web service work in either Java or Go, but I'd like to give Rust a try for comparison at some point.

Re: Ask HN: What is the state of C++ vs. Rust?

#96
post #90

C is still significantly faster than Rust which follows that C++ is too. So unless Rust is able to produce binaries on all major platforms that are as fast as C++, people who need to squeeze out as much performance as possible are not going to drop the language.

Rust will be if is not already faster than C. Especially in real-life projects. One example would be https://github.com/BurntSushi/ripgrep

Aliasing rules in C make some optimizations not possible in C. Good luck putting that `restrict` everywhere to compensate. Generics with static dispatch makes it possible to get a code that is way better than what a sane person can write with C's preprocessor. Practical developer will very often sacrifice performance for sanity in C codebase. Memory safety makes it easy to write correct, reliable multithreaded programs in Rust and actual package manager makes it practical to reuse well-written and optimized code.

Even if there are some microbenchmarks where C gives better results, it's because Rust version doesn't "cheat" by using `unsafe` constructs. Essentially in Rust one can write functionally exactly same code that C uses, including inline asm etc. which is useful for performance-critical libraries that wrap it in safe abstractions, but would be frowned upon in a tiny synthetic benchmark program that is supposed to benchmark idiomatic code.

Re: Ask HN: What is the state of C++ vs. Rust?

#97

Earlier quoted context omitted.

>I still work regularly on C++0x11 ... but that's not due for another year!

The C++ compiler teams have done heroic work to get their implementations on-track and have been ahead of the spec for several years now. Many compilers are already supporting a number of C++17 features, and by the time the spec is out it might be almost complete for most major vendors. http://en.cppreference.com/w/cpp/compiler_support

0x11 == 17

Re: Ask HN: What is the state of C++ vs. Rust?

#98
I am/was a embedded dev, been using C/C++ since ... more than 15 years. I do C++/Go at $dayjob and I'm in love with Rust.

I've written quite a bit of comments before on Rust, since it's not the first time someone asks similar question. You can read my past comments: https://news.ycombinator.com/threads?id=dpc_pw

Just to sum up, IMO: Rust blows C++ out of the water on almost everything. It's not established enough so there are almost no jobs, and there's a learning curve, lack of tools, slow compilation, business reasons, etc. so you can't just blindly use Rust over C++, but when you can and have time to learn: go for it. The existing tooling is amazing, community is awesome, you will learn really interesting stuff, save time on debugging.

As for C++17 features... I don't really care anymore. C++ is death by thousands little cuts (undefined behavior is my "favorite") it's not going to change much anyway.

Re: Ask HN: What is the state of C++ vs. Rust?

#99

Earlier quoted context omitted.

The C++ compiler teams have done heroic work to get their implementations on-track and have been ahead of the spec for several years now. Many compilers are already supporting a number of C++17 features, and by the time the spec is out it might be almost complete for most major vendors. http://en.cppreference.com/w/cpp/compiler_support

0x11 == 17

That's not a code name I've ever heard of: https://en.wikipedia.org/wiki/C%2B%2B17

C+0x was what turned into C++11. The 0x part was just a placeholder for 08 or 09, but it actually ended up taking a few years longer to ratify.

Maybe people confuse C++11 with C++0x to get C++0x11.

Re: Ask HN: What is the state of C++ vs. Rust?

#100
post #2

Rust is promising but C++ is here to stay. If you have a legacy C++ code base, it is much easier to sell that you are just upgrading the compiler to get new language features, that you are rewriting everything from scratch. Now we'll have to see in the next few years if, for new projects, Rust is chosen over C++ wherever it was used traditionally and in which proportion.

Java is promising but Cobol is here to stay. Kind of true, but one can rise in popularity while the other dwindles, even if not completely dying.

Thing is that 90% of new developers who get to see both Rust and C++ will choose Rust.

Post reply on HN