Hacker News Reader

You are right. rust is lacking many many things. C++ will still be around in 30+ years. But remember, C++ has a good 10 year head start on java, and java gained a lot of traction because of all the tools they didn't have to build.

Nobody needs to build valgrind for rust (or your favorite alternative). Leveraging existing libraries isn't trivial, but it's not a year long project either. IDE's support a lot of languages out of the box. rust support will be rough at first, but quality will be proportional to use. I suspect microsoft could build the layers you want like they did with J++ very quickly. A year? maybe 2?

The biggest bottleneck, imho, is developers. I don't think many people really know all the dark and scary corners of C++, but there are a ton of people that can get stuff done in C++.

If schools start graduating people with rust experience, the writing is on the wall for C++. Shifting school curriculum takes a big reason. Maybe a hit indie game, maybe some other killer app. I don't think servo is the one.

Really, it's a testament to the quality of the language that the complaints are all along the lines of "it's fantastic, but the tooling..." Don't underestimate that. Tooling can happen real fast.

Is rust a sure thing? no. absolutely not. does it have a chance of becoming the systems programming language in 10 years? Yeah. i think it does. i think it's got better than a 5% chance of doing that. 1 in 20 is a perhaps an insanely high number. The language is just so very good.

I am all for Rust and even though I use C++ since C++ARM, I am by no means an expert and nowadays spend most of my time in JVM/.NET lands with C++ only when I need its features.

However, and that is somehow what I wanted to point out, by being part of the community I am fully aware of the uphill battle that was to make C++ relevant as it is today.

We used to be flamed by the C community, like like Rust, D, Go and others are nowadays, yet the C community now has their major compilers being written in C++, funny how things turn out.

So, yeah Rust or other saner systems programming language might eventually replace C++ and I would like to see it happen.

But bashing the efforts of the ones that try out to make C++ safer within its constraints, because not everyone of us is able to throw out our tools and move right away to Rust, is not going to help getting those developers.

For example, I would rather use C# + Rust than C# + C++/CX, but I am not going to convince any customer to allow me to do that.

The C++ community seldom "flames" the Rust one. On the other hand, I often see C++ threads on Hackernews ending with people bashing this language ("C++ hell", "dirty language", "dying soon") and bringing Rust on the table.

It is pretty frustrating when you actually want to exchange on this language, far from dead, and enjoyed by some.

"The C++ community flames the Rust community" right in this thread. TFA didn't say there was no merit to the "safe C++ subset" [1], just that it's not here yet, it's not going to be as safe as Rust, and that it's often mentioned as if it's here and as safe as Rust, that's why TFA called it vaporware.

This thread is not refuting this claim but explicitly or implicitly blames TFA and "the Rust community" for misrepresenting C++ as dead, useless and not worthy of improvement.

Of course C++ is far from dead, enjoyed by some, and used by many more; TFA did not claim otherwise. Of course improving C++ helps those using it; TFA did not claim otherwise. All it claimed was that the current and potential future state of Rust relatively to C++ was misrepresented by people at the C++ side; I think you're more supporting than refuting this claim.

[1] I personally, unlike TFA and some commenters here, must say that I'm not thrilled about anything having to do with unique_ptr (which as TFA demonstrated is not guaranteed to be unique at all, but is as unique as its user made it) and other such; certainly if I have to rewrite an old code base to use new smart pointers, the change will involve every corner of that code base, and I think I'd rather rewrite it in another actually safe language if safety is what worries me. But that's just me; and BTW I haven't personally looked deeply enough into Rust to advocate for it, either.

In that case, the blog post was explicitly comparing Rust and C++. It is not surprising that the comparison goes both way.

I am talking about the HN topics like "How to implement a packet tracer in C++" or "Optimize std::vector with C++14" where invariably a comment like "Who use C++ in 2016 when you have Rust?" spawns. Rust is amazing, but that doesn't make it the de-facto answer to all the projects. Some people might still want to increase their skills in their day-to-day language like C++, even if they are aware of Rust awesome features.

Ah, i had no intention of flaming C++. A ton of really great software is made with C++. I think most sane C++ programmers will freely admit there are dark and scary corners. Just like any other tool people actually use.

A professor of mine used to talk about (i assume he still does) how software is like a plant. New software is always fun and cute and understandable like anything young, babies, puppies, kittens, whatever. C++ is like an oak tree. there are gnarled branches, but is quite beautiful taken as a whole. Like an oak tree, it stands the test of time.

The rust community has been ponderous in adding features. I think they've picked a really nice set of stuff to support. Perhaps rust will turn into a beautiful old oak, perhaps not.

I'll stretch the metaphor a bit more, C++ doesn't have as much room to grow. It's far from done, but there's a lot of legacy code that must be supported. Choices were made decades ago that limit options today. Again, this isn't meant to malign C++, it's just how hindsight works. Rust on the other hand has has the benefit of hindsight. Rust will make plenty of mistakes, but the community can avoid some of the trouble C++ has had simply because it's new and has more information about what's really useful and what's not. The rust community has by and large been very aware of what works and what doesn't. They're careful gardeners. They've learned their history, and want to try other stuff. Perhaps rust can grow to be a mighty oak like C++. I hope it will, but that remains to be seen.

My hypothesis: disgruntled students taking out their frustrations on C++

I don't think it's fair to call criticism flaming, and I think the article and most of this thread are being critical, and fair, again not flaming. I'll grant you that the tone of the article was harsh, but it's a fair criticism (IMO).

The Rust community is one that generally is extremely supportive of new users, even when those users are very pissed off at the steep learning curve with lifetimes, etc. It's impressive to see some of the even handed responses to questions.

Reiterating what others have said, no one is saying C++ is dead, no one is saying that C++ won't be around for a very long time. What people I think are saying in general is; if what you want is a memory safe, data race safe, strongly typed (with ergonomics) language, Rust is a great one. It's got lots of really nice modern semantics, and comes at the same performance cost as C++ (in general).

It's like a Tesla vs. an awesome classic Ferrari; no one wants that Ferrari to die crashing out a window, in fact any car lover wants to see that thing continue to get a lot of love and work to maintain it. But maybe there's a nice car that would be better to drive day in and day out, so that you don't have to worry as much about a parking attendant taking if for a joy ride.

Is really rust not needing valgrind, and more specifically the memcheck tool ? OK for leak detection. But is it really able to detect all not initialized memory accesses ?

Anyway, I suppose that rust can still benefit from other valgrind tools, like helgrind, drd, massif and so on.

Using uninitialized memory is impossible in safe Rust. There's a standard library function that lets you treat an uninitialized object as if it were initialized, but it's marked unsafe.

Rust still can benefit from Valgrind, especially if you are working on low-level libraries that require unsafe, or interface over the C ffi. The point that I think the parent is trying to make though is that Rust has made pragmatic decisions that allow it to piggyback off existing tools - it's not starting entirely from scratch.

Rust doesn't tend to leak memory, but it doesn't make any firm guarantees about memory leaks as opposed to invalid accesses. For example, even in perfectly safe Rust code, you can make a cycle out of reference-counted smart pointers, and their destructors will never run. So valgrind may be useful for that, and it's common to interact with C libraries which may leak memory. But it's much less common to need than it is in the C/C++ worlds.

I think the parent is saying less that you don't need valgrind, more that you get it for free. I can take a program I'm writing in Rust and run it through valgrind, or other debugging / profiling tools written and designed for c / c++ because the rust binary ends up with the same debugging symbols that a gcc compiled binary could have

>"But remember, C++ has a good 10 year head start on java, and java gained a lot of traction because of all the tools they didn't have to build"

The thing is... I don't think Java took over C++ developers. Most likely they took over Pascal, Delphi, VB, Perl and other enterprise developers.

Every decade there is a language that claims to kill C++ (Java in the 90's, Go in the 2000's) offering features that are not bothering C++ developers and end taking off by attracting developers from other communities (like Go with Python devs).

I believe that memory safety or manual memory management is not the mainly concern for a C++ developer. On the other hand, if you give the same tools that C++ has and reduce complexity and then you might got into something, until then...

Depends what you mean by taking over. Certainly C++ developers are a much smaller proportion of developers now than they were in 1990, and much of the difference is made up by Java. Are those Java developers writing the same style of code with the same interfaces that those C++ developers were doing? No. Are business problems that used to be solved in C++ now solved in Java? Yes, often.

I don't think we'll ever see a mass exodus of C++ developers to other languages - but in truth we never saw one from Pascal, Delphi, VB, Perl or Python either. What we will see is the niche where C++ is appropriate gradually shrinking, the borderlines between what's appropriate for C++ and what's appropriate for Java etc. changing, until one day we notice that there's hardly anyone writing C++ anymore. E.g. 20 years ago people would have said there was no way you could write a game except in C++ (or assembly). 10 years ago people would have said ok, you can write some games but not an FPS. Nowadays people say ok, maybe you can write a high-performance game without writing any C++ yourself but the engine you use will still be written in C++...

You are forgetting that Enterprise WAS C++ before Java.

Amazon went from C++ (to Perl) to Java.

Google went from C++ to C++/Java (and now Python and then Go)

Microsoft went from C++ to C++/C# , C# is Microsoft flavor of Java.

In certain areas such as games, GPU, etc C++ still rules, which is why I restarted on c++ nowadays.

Google started with Java and Python, not with C++.

Microsoft is a bad example because they pretty much do everything in C++ (Office, Windows, VS, etc).

Also by enterprise I meant banks, insurance companies, factories, etc.

You can't reduce C++'s complexity without eliminating core language features. This is precisely why people talk about “sane C++ subsets” (although the very idea is silly). Of course, C++'s features were designed to address important use cases, so workable replacements must be provided in their stead:

(0) By far, the most important use case for templates is emulating parametric polymorphism. The solution is obvious: provide actual parametric polymorphism.

(1) The other important use case for templates is performing compile-time computation. This is done either by pattern matching on types (which parametric polymorphism forbids) or on values (e.g., integers) promoted to the type level. The latter feature is available in Haskell (`DataKinds`), and its design can be borrowed mostly as-is by systems languages.

(2) Classes combine, in a single language construct, features that ought to be separate: user-defined types, encapsulation (access specifiers), code reuse (inheritance), etc. Again, the solution is obvious: split these features into different language constructs: structs and enums, module-level privacy, parametric polymorphism, etc.

(3) Ad-hoc polymorphism is useful, but overloading as done in C++ is too unconstrained to support modular type checking of users of overloaded operators (templates). Again, the solution is known: type classes.

C++ only started to gain weight in the 90's, Java came in the 2000's. Before it had a JIT no one cared.

Also just we C++ 90's hipsters were doing systems programming in C++.

Most developers were finally getting convinced that in home computers C, Pascal dialects, Basic compilers, Modula-2 and so forth were getting good enough not to depend on piles of Assembly code.

C++ was getting used in GUI toolkits, CORBA and DCOM and seen as too high level.

Hence why the commite tried to specify the Embedded C++ standard, to cater to the more hardcore C developers.

Java first version was in 1995 and people cared about it before 2000 for sure (Google's first version was Java and Python and was in 1998)

You mean the people doing browser animations in applets?

I only used it in 1999, because our teachers at the university wanted to use this new cool language from Sun.

At banks. insurances and telecommunications businesses, we were all doing C++ with CORBA and DCOM, using MFC and VB 6 as frontends on the desktop.

The amount of Delphi users were already ramping down thanks to Borland's mismanagement.

I worked at a bank in 1998 porting applications from VB6 to Java, and not they weren't browsers applets, there were servlets which were available since mid 1997.

There are still a niche for C++ in banks (i.e transactional server applications) but pretty much all the business logic applications (that counts for 80% of the code of most banks) were starting turned to Java by that time

The regex crate in Rust works perfectly well on stable, AFAIK. The author has improved the runtime-constructed regexes to be much faster, while those same improvements haven't yet made it to the compile-time macro-constructed regexes. So, to get the most speed, one gives up having a hard compiler error when using an invalid regex literal. That said, the clippy tool (https://github.com/Manishearth/rust-clippy) can do compile-time verification of regex literals, but it depends on nightly Rust because it relies on deep integration with unstable compiler internals. (The regex crate also has a new optional nightly-only SIMD-accelerated algorithm, but it's otherwise fully functional on stable.)

Re: nightly features, I agree that there are several things which Rust really needs to stabilize to achieve many of its goals (stable SIMD, inline assembly, procedural macros, stable custom allocator support, the Rust Language Server for IDE integration, etc etc etc). Now that the major compiler internals refactoring of the last year is nearly complete, my understanding is that we may start to see more aggressive progress on some of those items which keep pushing users to nightly Rust.

The issue being that most customers won't agree using tools that aren't stable and having libraries that keep on depending on nightly doesn't bring any confidence to those businesses.

Absolutely, I just wanted to clarify that the regex library isn't really one of those cases. And I haven't personally used a compile-time validator for regex literals in another language, so I'm not sure that missing clippy should be seen as a major gap in the tooling (although it does have many other useful checks).

I certainly think there are other cases (serde immediately comes to mind) where the best developer experience can only be had on nightly, and that's a big problem for wider Rust adoption.

The C community has things like Frama-C and CompCert, because they're not pursuing exponential complexity in their language.

As you correctly point out at first, the value of a language is more than the language itself, it's also the tooling and the environment. And since you can't retrofit safety in the language, it's a good place to work on it.

> The C community has things like Frama-C and CompCert, because they're not pursuing exponential complexity in their language.

Could you elaborate on what complexity you are referring to, and what makes it exponential?

Static analysis tools for C suffer from modularity issues: These tools are primarily based on abstract interpretation, so their results are very sensible to the control flow of your program. This means that your procedures, as analyzed by these tools, are connected by monstrous preconditions and invariants that describe the state of your program in each control flow path the program could possibly take. For obvious reasons, this doesn't scale.

Which very few bother to use.

Yeah, the "C++ killer" meme is annoying. It is exciting that Rust is already as good as it is, and it is also exciting that C++ is improving so much. It's a big world and the proposition is not either/or but both/and.

I am more curious as when Rust can have something equivalent of Eigen.

That's one place where C++ still has Rust beat. The C++'s templates are (for better or for worse), far more powerful and expressive than Rust's parametric polymorphism. There have been advances in doing more extreme compile time metaprogramming using Rust's generics, including unit systems and n-dimensional arrays, but we are still hanging out for things like parametrising types over integers, and for the stabilisation of const functions that will make this kind of thing easier to do. As for something akin to expression templates... I'm not sure if that is on the horizon yet, or even if it is desired. This kind of thing takes time, and won't happen any time soon, as far as I know.