HN Theater @HNTheaterMonth

- Tour of C++ (http://www.stroustrup.com/Tour.html)

- Principles and Practice Using C++ (http://www.stroustrup.com/programming.html)

- From Mathematics to Generic Programming (http://www.fm2gp.com/)

- The Scott Meyers books

Some of the Bjarne Stroustrup videos,

"Learning and Teaching Modern C++" - https://www.youtube.com/watch?v=fX2W3nNjJIo

Some of the Herb Sutter videos,

"Writing Good C++14... By Default" - https://www.youtube.com/watch?v=hEx5DNLWGgA

"Back to the Basics! Essentials of Modern C++ Style" - https://www.youtube.com/watch?v=xnqTKD8uD64

Some of the Kate Gregory videos,

"Stop Teaching C" - https://www.youtube.com/watch?v=YnWhqhNdYyk

"10 Core Guidelines You Need to Start Using Now" - https://www.youtube.com/watch?v=XkDEzfpdcSg

"It's Complicated" - https://www.youtube.com/watch?v=tTexD26jIN4

⬐ humanrebar

I'd add the CppCoreGuidelines to the list: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...

It's a lot of the content in the above but crowdsourced, open for PRs, searchable, and readable from the browser.

⬐ alexhutcheson

Abseil C++ Tips of the Week are also really good: https://abseil.io/tips/

⬐ zerr

Are these tips mostly "Google-style" C++?

⬐ i45_n5

As for "Stop Teaching C" video one should also consider this book https://www.amazon.com/Accelerated-C-Practical-Programming-E... Alas, it is c++03. On the other hand it's relatively thin and it begins with the standard library (std::vectors, std::sort, std::string) from the first chapters. So I guess it was the first good book that didn't begin with C language from the start.

⬐ colin_mccabe

Good to see that three decades later, C++ still has a massive inferiority complex about its older brother, C.

⬐ pjmlp

It is not an inferiority complex, rather to stop people learning about writing bad code, open to security exploits by default, something that C is pretty good at.

⬐ boblivion

I'd like to recommend Jean Parents talks: https://www.youtube.com/watch?v=QGcVXgEVMJg&list=PLiWEEi8ezR...

They are truly great.

⬐ frankzinger

Sean Parent, that is.

⬐ None

None

⬐ se30b

Would not recommend Principles and Practice Using C++, it is a fluff loaded book seemingly made to sell to university students.

⬐ bewuethr

I think it's a great introduction to Programming, but if you already know some other language, it tends to be verbose - but Stroustrup always tends to be verbose. I, for one, really like his style.

⬐ zerr

I used to like Bjarne's style when I was just starting, but nowadays it seems way too verbose. Even talks, you can "compress" his 1+ hour talks to 15 minutes, lossless :)

⬐ jasonx1e

Is there a progression to this one might follow?

⬐ bloodorange

I agree with this completely :)

I would also like to add that it helps to read "The Design and Evolution of C++".

I found that I plateaued early in my C++ journey. However, I was always reading from the experts and it really helped to read material from Dr. Stroustrup. Once I began to see the common thread behind what he was saying and understood why some things were the way they were, it helped understand when it's a good time to use/not-use certain things. This helped break past that barrier and to improve my skill further.

Also, it helped to write a _lot_ of c++ code and think about how that could be better.

I'm afraid I didn't read a tonne of good C++ code in that period but somehow, I managed to keep growing and at some point, it became my "go to" language and I really started to like it.

Long story, short: Read books from the experts, esp. Dr. Stroustrup.

⬐ krylon

> I would also like to add that it helps to read "The Design and Evolution of C++".

I think that book is worth reading even to people who have no intention of going anywhere near C++, as long as they are interested in programming language design and evolution. I wish there were more books like this one to explain the kind of thinking that went into the design of a language and to tell its history.

⬐ vram22

Agreed.

I had commented on the book on HN about a month ago:

https://news.ycombinator.com/item?id=16275341

Excerpt from it:

"I found that book very interesting in many regards. I had bought and read it several years ago (out of interest, though I have not worked on C++ professionally).

Stroustrup goes into a lot of details about the reasons for many design decisions in the language."

That's one of the reasons that make the book interesting. He even goes into human and cultural aspects of programming.

⬐ scott_s

Agreed on D&E, but I think it really does need an update now.

⬐ vram22

Yes, it is quite some years since it was written.

⬐ cbHXBY1D

I would love a book similar to C# In Depth but for C++. The book takes you on an evolutionary tour of C#s features, version-by-version. One of my favorite programming books of all time and a good read even for someone who doesn't program in C#.

⬐ krylon

I have been using C# at work for a little while now, and I am starting to like it. Thanks for the suggestion!

MSVC is continuing to improve their detection of invalidated pointers: https://youtu.be/hEx5DNLWGgA?t=3231

This is running the static analysis pass instead of the normal compile pass, but stuff is improving. Of course you're preaching to the choir as far as I'm concerned - this stuff is way late to the party, and speaking generally, has issues with false positives and failing to detect things.

Thanks for the tip, your link is missing an A at the end though...

https://www.youtube.com/watch?v=hEx5DNLWGgA

I've been spending a few days going through talks from last years cppcon[1]. They're all good, but they've all left me with a strong desire for a strongly opinionated, there-is-no-past-only-the-future introduction to C++14 (and incidentally, C11).

I've added a few of those talks I've watched and liked to a small playlist (with a couple of other talks on programming, unrelated - the relevant talks are prefixed with "cppcon 2015"):

https://www.youtube.com/playlist?list=PLHvt7sld3hmvdDnwHkdU2...

The full cppcon playlist is here: https://www.youtube.com/playlist?list=PLHTh1InhhwT75gykhs7pq...

Of special relevance is the rather excellent talk by Kate Gregory on "Stop Teaching C" (when you're supposed to do an intro course to C++):

"CppCon 2015: Kate Gregory “Stop Teaching C"": https://www.youtube.com/watch?v=YnWhqhNdYyk

(But again, I want an open wiki/live tutorial, along the lines of "How I start", but longer, which goes through all this stuff. We really should make one, both for C++14 and for C11).

CppCon 2015: Herb Sutter "Writing Good C++14... By Default": https://www.youtube.com/watch?v=hEx5DNLWGgA Is also rather uplifting, and:

CppCon 2015: Sean Parent "Better Code: Data Structures": https://www.youtube.com/watch?v=sWgDk-o-6ZE

makes a pretty good case for simple, modern C++ being clear, easy and efficient.

Finally,

CppCon 2015: Phil Nash “Test Driven C++ with Catch”: https://www.youtube.com/watch?v=gdzP3pAC6UI

apart for being a pretty straight forward intro to a simple testing framework, appears to reveal some secrets combining template magic and still get sane compile times (hint: don't recompile more (template) code on every iteration than you need to).

There's a couple of good ones that touch on meta-programming too (Look for the talk on Spirit X3 and Brigand), and there's a nice lightning talk on clang-tidy (magically go from explicit loops to modern foreach, yay!).

My understanding is that the tools are the answer - it's a linter that must be run before landing/merging. See https://youtu.be/hEx5DNLWGgA for a demo of such tools.

⬐ bjz_

Tools are just band-aids over an unsafe type system, and they are all too easy to ignore or never use them in the first place.

⬐ swaroop

It depends on the community. See gofmt & gometalinter in the golang community.

I don't believe it is, unless something's changed. To quote MSDN:

"The package currently contains checkers for the Bounds and Type profiles. Tooling for the Lifetime profile demonstrated in Herb Sutter’s plenary talk (video at https://www.youtube.com/watch?v=hEx5DNLWGgA) will be made available in a future release of the code analysis tools."

https://blogs.msdn.microsoft.com/vcblog/2015/12/03/c-core-gu...

⬐ pjmlp

I thought that the NuGet package already had a few updates since December.

⬐ kibwen

I don't have access to a Windows machine right this moment to check, but a cursory search of the internet gives no indication that this tool has been released in any subsequent update. If it had, you'd think there'd be some fanfare, or acknowledgement, or documentation, or experience reports from users, or anything.

⬐ pjmlp

Have you seen the CppCon presentation?

About 1% of the audience answered affirmatively to Herb's question about who was using some kind of static analysis tools.

Outside HN and Reddit circles, very few C and C++ developers, at least the typical enterprise ones, don't really care about such tools.

Back on my C++ days, just one company cared to pay for Insure++ and I was probably the only one using it.

This is way I am looking forward to use it eventually, but don't have high hopes for wider adoption from other C++ vendors.

I guess need to update to Update 2 when it goes to RTM ready.

⬐ kibwen

I won't dispute that the vast majority of C++ developers seem to be indifferent to static analysis (look how many decades it took John Carmack to come around...), but the initial video presentation did cause a noticeable stir, and I would expect the actual release of the tool to incite a comparable reaction.

⬐ pjmlp

Yes I do agree with you.

Nowadays I only use C++ for hobby coding between Android and WP nowadays, or when I need to step out of JVM/.NET worlds, so I missed to follow up on it.

⬐ roca

Extra-lingual static analysis tools are OK at finding bugs. They're not good at proving the absence of whole classes of bugs; that is what we should be striving for, and what Rust and other languages can provide.

So what I'm looking for from Herb Sutter is not just a set of good guidelines and tools to check for them, but also a proof --- or at least an argument --- that if the tool finds no errors in a piece of code then that code cannot be the source of memory safety bugs.

⬐ pjmlp

I agree, the biggest issue with extra tools is that they require additional effort to use them.

After all, lint was created to compensate for C's unsafety in 1979 and up until clang's introduction of static analysis, barely unused in the industry.

Still C++ isn't going anywhere and is the only native language with first class support in all mobile SDKs, so anything that helps improve its use is welcome.

Wow, this is the first post I have ever read that even kind of implied that Andrei Alexandrescu was a Blub programmer.

Part of being a Blub programmer is that you don't even think about the issues. In regards to the weird features brought up, the underlying issues behind these features have been in the C++ consciousness for some time. Below are some talks and resources covering at least some of these issues.

Sean Parent - Inheritance is the Base Class of Evil - https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&c...

Herb Sutter - You don't know const and mutable - http://herbsutter.com/2013/01/01/video-you-dont-know-const-a...

Andrei Alexandrescu - Systematic error handling in C++ - https://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012...

Herb Sutter - Writing Good C++ by Default - https://www.youtube.com/watch?v=hEx5DNLWGgA

Andrew Sutton - Generic Programming with Concepts Lite - https://www.youtube.com/watch?v=qwXq5MqY2ZA

One of the things that helps with avoiding "Blubness" in C++ is the significant interest in languages such as Haskel (which is not considered a Blub language by anyone except Agda programmers) and in applying the techniques and insights where possible to C++ whether through writing new libraries (see for example Fit by Paul Fultz II -https://github.com/pfultz2/Fit) or through new language features (see this post by David Sankel - http://davidsankel.com/uncategorized/c-language-support-for-...)

Finally, is also interesting that Paul Graham's blub paradox is being brought up in regards to Rust, C++, and D. The Paul Graham article is in large part talking about the power of meta-programming. In this regard, D and C++ are significantly more powerful in that regard. Features like higher kinded types (template templates), variadics, and non-type template parameters help in this matter. When you can write a function that can generically work with a tuple with any number and type of parameters, you can do some pretty neat stuff. For some examples take a look at Boost.Hana by Louis Dionne (http://boostorg.github.io/hana/). In this regards, Rust is actually the Blub compared to D and C++.

⬐ djur

> In this regards, Rust is actually the Blub compared to D and C++.

I think this demonstrates a significant weakness in Blub as a concept: there is not even a partial ordering of languages by power. The essay only works because Graham picks the two sides of the debate: Lisp, which Graham believes to be the most powerful of languages, and Blub, a theoretical language that can be stipulated to be less powerful than Lisp in all ways.

Outside the essay, "blub" only exists as a slur for a despised language or an insult for another programmer, and it's only useful as a way to start arguments.

⬐ steveklabnik

  > In this regards, Rust is actually the Blub 

I'm not so sure. We are aware of the features that they have; we just prefer the strongly-typed versions to the stringly-typed[1] versions.

We do desire more meta-programming features, and they will happen. Like all decisions, we don't want to rush into them.

1: This is not _entirely_ accurate, but I'm slightly at a loss for how to exactly characterize this at this particular moment. Rust's metaprogramming guarantees that you always generate valid Rust code, D's does not.

⬐ mst

Is that mostly a faster feedback loop and better errors thing? It seems like so long as the generated code doesn't get as far as compiling, it doesn't make that much of a difference?

(this could easily be a stupid question; I know I've come across as condescending to you before by mistake and if I've somehow done it again please believe that I meant to come across as genuinely curious :)

⬐ steveklabnik

Not at all!

Yes, to me, it's largely about better errors and such. If th generated code is wrong, it won't compile, so it's not _that_ level of bad. But this can't happen in Rust: http://tgceec.tumblr.com/

⬐ mst

Now I want to see an article that compares the error messages from rust and D metaprogramming ... though admittedly, at least half of this is because you could call said article "D missed nosejob day".

⬐ Manishearth

Note that with bounded polymorphism you get clear API boundaries too. With templates you may have to clearly document what kind of type is allowed in.

There's also the danger of something compiling where it shouldn't.

⬐ pcwalton

There are a number of benefits to concepts:

- They make namespacing of functions easier, eliminating the need for C++'s "argument-dependent lookup". The issues here are somewhat subtle and would take a lot of space to explain. But the end result is that we can remove a massive amount of confusion by getting rid of ADL.

- Error messages are much better, because the insides of templates never leak to users of the template.

- Typechecking is simplified, because we only have to typecheck each template once, at the time of definition, as opposed to repeatedly typechecking it from scratch every time it's instantiated. This, in theory, allows compilation to be faster.

⬐ mst

> Error messages are much better, because the insides of templates never leak to users of the template

This is unequivocally a good thing - I think maybe my disconnect here in how excited I am compared to others is that I'm comparing it to the experience of debugging lisp macros and everybody else is comparing it to the bottomless pit of despair that is C++ template errors ;)

⬐ u320

I would go one step further and say that those features in Rust (and ML, Haskell etc) aren't even metaprogramming. So D uses metaprogramming to make up for a weaker type system.

⬐ Manishearth

I like to call C++ templates "structurally typed", since you can get some degree of that from SFINAE and composing templates together. They're more pattern-matching based than type-based. This is reminiscent of how Go auto-impls interfaces, really.

⬐ jbandela1

The last statement was more in regards to the Blub definition implied by the article. Of course, people who are immersed in programming language theory are not Blub programmers - they are aware of what is possible, but are also aware of the inherent tradeoffs.

With regards to Rust, do you have any idea when more meta-programming features like variadics and non-type template parameters might be available in the language (are we looking at months, years, or decades)? Rust, has a lot of features that really interest me, but seeing the tuple serialization code brought back bad nightmares of simulating variadic templates using macros in C++ before I had a compiler that supported C++11 variadics. To me, at least personally, it felt like a step backward from C++14, and kind of curtailed my enthusiasm for doing a deep dive into the language. My test for the power of a language's type manipulation is how easy is it to write an implementation of apply(Function f, Tuple t) which will call f with the values of t. I would be most interested to see how Rust will implement this kind of metaprogramming.

⬐ pcwalton

> My test for the power of a language's type manipulation is how easy is it to write an implementation of apply(Function f, Tuple t) which will call f with the values of t. I would be most interested to see how Rust will implement this kind of metaprogramming.

That's kind of a weird litmus test of the power of the language's type manipulation: it only applies to languages where functions take multiple arguments, it's a pretty niche use case (since the workaround in Rust is straightforward), and there's nothing particularly sophisticated about variadic generics (what you need to solve the problem). I could equally say that my litmus test of a language's generics system is whether the compiler prevents errors during template expansion.

Anyway, to answer your question: that's really easy in Rust, as long as you're on nightly. The FnMut trait (and friends) allow you to call functions with tuples as arguments. https://doc.rust-lang.org/std/ops/trait.FnMut.html

⬐ steveklabnik

Yeah, I agree with my sibling comment above that Blub is kind of a weak concept for this reason.

It's hard to say because the work for those features hasn't even been started; the MIR refactoring is still underway. Once that's done, RFCs for this stuff will start to appear, and we'll have a better idea of overall schedule. I would say that the current schedule is "longer than months, shorter than a few years".

I myself _really_ want higher kinded types, but at the same time, I would rather wait and do it right than rush and regret thing slater. We have a solid language as it is; the need to get these more advanced features is not particularly urgent, in my opinion. I like to think on the long scale when it comes to the language: if it's going to be around 40 or 50 years, we're in year one. There's plenty of time.

⬐ GFK_of_xmaspast

It's always easier to see the blub in someone else's language and not in our own.

⬐ pcwalton

C++'s templates are untyped. Rust's templates are typed. Most people aren't aware of the difference, and they naturally think that templates "have to work" like the ones in their favorite language (dynamically typed if coming from C++ and D, and statically typed if coming from Java, C#, or most other languages). But the fact that Rust and C++/D picked different sides of the tradeoff is the key source of the differences between them.

C++ and D programmers, like you (and Andrei), look down on Rust generics and give examples of all the things that you can't do with Rust generics that are easy to do with C++ templates. But there's an equally strong counterargument, in that Rust generics never give errors at template expansion time and are guaranteed to expand to valid code. This makes code easier to understand, improves the experience for users of your generics, and also simplifies the implementation, leading to potentially better compile times (since you typecheck once instead of after every template expansion). Of course, this is a tradeoff: it's more work for us to implement the features necessary to do the kinds of sophisticated metaprogramming you see in C++ and D, and there will always be some things you can't do in Rust that are easy in C++ and D. But that isn't a slam-dunk argument for untyped templates vs. typed generics any more than easy reflection is a slam-dunk argument for dynamic typing like Python vs. static typing like Java.

I think that is a great answer. I actually see some parallels between the relationship of Rust/C++ to Scala/Java. Both basically use the backend of the established language and provide an 'improved' language on top of it. Scala uses the JVM, and Rust uses LLVM.

What is interesting is that with the release of Java 8, a lot of Scala early adopters and cutting back their investment in Scala in favor of Java (for exampled LinkedIn). This is despite the fact that Scala is widely used in production, has a killer app in Spark, and allows pretty seamless use of the Java library.

Now compare this to Rust. Rust also provides an 'improved' language in the same space as C++ utilizing LLVM. However, what is interesting is the nature of the improvements. The biggest feature of Rust is the memory safety. However, the memory safety is not a productivity improvement as more of a safety improvement. Unlike garbage collection where you just do not have to think about memory allocation issues, Rust forces you to think about ownership and mutability. That same exact thinking will allow you to pretty much get the same memory safety in C++ using unique_ptr and shared_ptr and const. The difference is that the compiler makes you think about it in Rust. Much like Scala inspired the adoption of features for Java, you can see C++ adopting pretty much the borrow checker as a tool - see Herb Sutter's talk at CppCon 2015 - https://www.youtube.com/watch?v=hEx5DNLWGgA .

As the experience with Scala shows, the adopted features of the established language do not have to perfectly match the 'improved' language to convince people to migrate back to the established language. The adopted features just have to be in the ballpark. I think the new C++ tooling will be in the ballpark in much the same way that Java 8 is in the same ballpark as Scala and remove much of the impetus for moving to Rust from C++.

In addition, Rust is not as well positioned as Scala. Scala is actually deployed in production and has a killer application. Rust has no major production deployments of which I am aware and no killer application (the equivalent of Spark). In addition, while Rust can interface with C libraries, Rust cannot interface with C++ libraries unlike Scala which can interoperate with the Java standard library.

Rust has some brilliant aspects just like Scala has some brilliant aspects. However, C++ (like Java) is not sitting still but has been incorporating the best ideas. In addition, when people choose a system language, they are inherently conservative because the system they are creating will typically be long lived and mission critical. If you are writing something that you hope will power your company for the next 20 years, do you want to go with a language created and driven by Mozilla with no major use in production, or with the language that powers Google, Microsoft, Apple, and Facebook?

Here is what I recommend. Learn C++11/14/17. Learn Haskell to really open your mind to what is possible. Learn Rust to learn about the borrow checker. Then apply what you have learned to make yourself a better C++ programmer. Some of the best, most insightful C++ programmers I know are people who are actually well-versed in other languages, especially functional programming languages.

⬐ fiedzia

"However, the memory safety is not a productivity improvement as more of a safety improvement."

I disagree. It frees you from chasing safety bugs and allows to invest more time in the features and that's clearly productivity win. For example rust does not suffer from compiler bugs as much as compilers written in C/C++ used to. Chrome and firefox developers spend a lot of time fixing buffer overflows and are likely to do this for many years to come. They certainly could do something more productive for everyone's benefit.

⬐ pcwalton

> you can see C++ adopting pretty much the borrow checker as a tool - see Herb Sutter's talk at CppCon 2015 - https://www.youtube.com/watch?v=hEx5DNLWGgA .

I have a lot of questions about this tool, both in terms of soundness/expressivity (how do you deal with shared_ptr and similar things if your goal is to statically guarantee no-alias on function entry) and in terms of practicality (the massive subsetting it requires basically makes ISO Core C++ an entirely new language).

Also, Herb's claims about the ISO Core C++ lifetime profile requiring fewer annotations than Rust were incorrect.

I gave basically this exact answer last time you posted a variant of this same comment on the last Rust thread.

⬐ kod

Anyone who's actually used Rust, C++, Scala, and Java knows that Rust and Scala involve considerably less suffering than their counterparts. The "adopted features" don't change the fundamental problems.

Java 8 lambdas are fundamentally broken due to checked exceptions, and the likelihood that checked exceptions are going to be removed from the language is essentially nil.

Likewise, Rust error messages are already better than C++ compiler error messages, and the nature of C++ template expansion makes that unlikely to change.

Learn what you want to learn... not what large companies have decided to adopt (or not) based on a number of factors that have nothing to do with the quality of the language or its educational value.

⬐ steveklabnik

  > you can see C++ adopting pretty much the borrow checker as a tool

This may be because I'm too close to it, but the Core Guidelines are similar in ways, but also very different. Preventing data races is an explicit non-goal, for example, whereas in some ways, it's the focus of the borrow checker.

  > Rust has no major production deployments of which I am aware

Dropbox is the latest production user, as of last month. And it's serious production usage: how the bytes get stored on disk, basically the core of the whole business.

⬐ nickpsecurity

I'd really like to know how well that works out at Dropbox. How honest and public do you think they'd be if major data losses resulted from Rust crapping out on them? I'm not sure about them but lots of businesses keep such things on the DL.

I think it's a risky move. I'd have first deployed existing, native code along with Rust in parallel using the data splitting technique so some is saved with original and some with Rust. Any compiler or library related issues on Rust side would be caught without data loss. I wonder if they did this in alpha stage and how long that lasted.

I mean, I love seeing Rust in production and some success stories would be great. It's just... wow, that's pretty mission critical for what I gather is still a beta-phase tool. I'd be testing on the middle or front-end layers first given they're usually stateless(ish).

⬐ kibwen

  > I'd have first deployed existing, native code along with 
  > Rust in parallel using the data splitting technique so 
  > some is saved with original and some with Rust.

Yes, this is how Dropbox tests all of their features, and they did this with their new Rust-based storage engine as well. This tool has been in development for over a year by now and has seen extensive multi-stage testing (at first handling only a few terabytes of data, then "just" petabytes, and now exabytes).

⬐ nickpsecurity

I was expecting they probably did given what's on the line. Re-reading it, I realize it probably didn't come off that way. Gotta work on that.

Thanks for the confirmation, though. I do look forward to reading the experience report. Hoping they include data on all key attributes vs prior language: productivity, debugging time comparison, CPU use, memory use, integration issues, and any changes in defect rates. Community evaluating Rust needs that data for something at this level.

⬐ steveklabnik

The project lead already said on Reddit that if Dropbox loses data, it's now Rust's fault, so... :)

The project was a whole team of engineers working for almost a year, with extensive testing. At least, that's what I've heard. So like, I think they did exactly what you said, it's just that it's ready by now.

⬐ nickpsecurity

Oh shit! That's one hell of an endorsement [in the making]. I bet the excitement and suspense are thick in the office, eh? Hope it works out for adoption reasons.

⬐ steveklabnik

More details: https://www.reddit.com/r/programming/comments/3w8dgn/announc...

⬐ nickpsecurity

I appreciate that. It has some good details. Gotta leave to get some work done but I'll take the time to drop you a compliment related to this:

"Edit: also worth adding that he Rust core team has been amazingly friendly and helpful. We've had several meetings with them where they came to our office and basically said "how's it going? what do you need? open up your laptop and show us your biggest problem." The project is under very good management."

When Rust was being developed, the two languages that got me most excited as next-gen, systems tech were Julia mainly and Nim somewhat. They had a great choice of features balancing all sorts of attributes as PL's that might get easy adoption as C++ alternatives. Thing is, many blog posts reported their communities and dev teams were downright vicious on everything from questions to compiler bugs (wtf!?). That made it a no-go as there's an upper-bound on how good those projects can get building on such a creaky, hostile foundation.

That leaves Rust as my default recommendation for new, non-critical projects in this space. Like Dropbox employee, what I've noticed is the two of you on Rust teams here are unusually helpful and respectful compared to many in PL communities defending their work. Even pcwalton when he's clearly less than happy with my comments. ;)

The combination of brilliant design and seemingly (from my little exposure) excellent community is why I promote Rust. So, keep up the great work all of you! :)

⬐ steveklabnik

Thanks so much. :)

⬐ pcwalton

> I think it's a risky move.

> It's just... wow, that's pretty mission critical for what I gather is still a beta-phase tool.

I think this is very '90s thinking. Extreme "if it's not C++, you can't deploy it!" conservatism about programming languages hasn't been true for well over a decade. Paul Graham has written some nice essays about this very phenomenon.

Also, Rust is not "a beta-phase tool".

New languages are much easier to deploy since the PL Renaissance. There are a few holdout industries that still stick with C++ no matter what, such as games, but they'll come around eventually. :)

⬐ nickpsecurity

You've been in discussions on this forum where I slam both C and C++. I'm clearly against it unless I absolutely have to use it due to its issues. That's why your strawman is more amusing than most. My actual argument was that new tools are usually unstable in terms of features, implementation bugs, and (with compilers) performance. So, default recommendation for mission-critical apps are mature tools whose strengths and weaknesses are well-understood so pro's can use them robustly.

Back to beta-phase claim, you're saying the core features and compiler of Rust are no longer in development or testing? Totally stable now with only extensions, library features, and optimizations being added? If so, that's good news and I'll drop that claim in the future. Otherwise, it's in the beta phase. Another hint would be existence of any bugs with core functionality in your compiler or libraries.

Again, though, if the spec and core functionality are frozen with all bugs fixed then I won't call it beta. Is it there yet?

⬐ pcwalton

Yes, 1.0 is stable and the language will not change in backwards incompatible ways. It's been that way for months (google "rust stability deliverable").

"All bugs fixed" rules out every language in existence except CompCert, so I don't think that's a very interesting metric.

⬐ nickpsecurity

Good to know on stability part. Far as bugs fixed, it's more on the lines of day-to-day use of the language in common scenarios. Are people getting unnecessary troubles out of the compiler? Typically don't for most languages as they work out most of them in common idioms and library functions in first, few years. If they're serious rather than 1-3 people's hobby, that is.

I certainly won't expect it to be bug free. Nice comeback with CompCert, though. ;)

⬐ fiedzia

I've seen rust compiler bug once and that was long before 1.0. The only issue now is that some important API's are not yet declared stable (RFC still being open), so many 3rd-party libraries target nightly and won't work in stable. This is however matter or 1 or 2 releases, and proves that rust developers take this matter seriously and don't wont to stabilize anything they aren't 100% sure. For all practical purposes rust is usable now, and more and more people are using it - certainly more then 3. Generally looking at rust projects on github, most of issues are feature requests. I don't see issues with crashes or panics, while I know plenty for similar projects written in C, at least in their early days.

⬐ nickpsecurity

Thanks for the detailed assessment. Sounds like a high quality, Beta to me. I also like the good things I keep hearing about the quality of libraries, etc.

⬐ danieldk

I think the new C++ tooling will be in the ballpark in much the same way that Java 8 is in the same ballpark as Scala and remove much of the impetus for moving to Rust from C++.

I think that you extrapolate from an incorrect analogy. Java is a relatively simple language (except the mess introduced by generics through type erasure), that is mostly understood by regular practitioners. Java suffered far more from the lack of modern language features than technical debt. Consequently, it benefitted from language extensions tried first in Pizza/Scala, etc.

C++, on the other hand, is a very complex language as a result of inheriting C, the lack of deprecation of misfeatures for compatibility, and perhaps questionable design choices. C++ suffers not so much the lack of language features (though support for real algebraic data types and modules would be nice), but from complexity. Complexity of the language can only be reduced by breaking compatibility.

CppCon 2015: Herb Sutter "Writing Good C++14... By Default":

https://youtu.be/hEx5DNLWGgA

Sutter comments on const_cast around 11m15s.

If it was that easy.

CppCon 2015, Herb Sutter's talk about writing safe code in C++14, just check how many in the audience use such tools.

https://www.youtube.com/watch?v=hEx5DNLWGgA&feature=youtu.be...

A tiny 1%, this on the conference of with many of the top C++ developers.

Now imagine how little they get used on the typical enterprise environment, specially worse with C, that lacks many of the C++ added safety layers.

Here

CppCon 2015: Herb Sutter "Writing Good C++14... By Default" around 00:32:00.

https://youtu.be/hEx5DNLWGgA?t=2053

> The work-in-progress ISO Core C++ lifetime profile does not work on unmodified code and requires a lot of annotations…

Herb mentions that it still less than lifetimes in Rust given C++'s type system:

https://youtu.be/hEx5DNLWGgA?t=1653

https://github.com/isocpp/CppCoreGuidelines/raw/09aef9bd86d9...

⬐ pcwalton

I've read the paper closely.

> Herb mentions that it still less than lifetimes in Rust given C++'s type system:

Yes, I know Herb claimed that. As far as any of us can tell, it's based on a misunderstanding of Rust's rules and is wrong :)

Learn C++. You will have the opportunity to learn low-level features but know how to wrap them up inside highly performant, high-level components.

Rust is interesting, but I think it will remain an interesting language outside the mainstream without any major commercial backers (Mozilla does not count). In addition, C++ is taking a lot of the ideas from Rust and incorporating them along with tooling that will provide 95+% of the value of Rust while still keeping the advantages of C++ (see https://www.youtube.com/watch?v=hEx5DNLWGgA)

What is interesting with C++ is that although a lot of vendors are pushing their own languages - Microsoft with C#, Apple with Swift, Google with Go, Facebook with Hack, Mozilla with Rust - they are all deeply involved with C++ because C++ powers their mission-critical code. Another way of putting it would be that despite all the promotion if all of Mozilla's Rust code were eliminated tomorrow nobody would notice, but if all of Mozilla's C++ code were eliminated, it would cease to exist.

Also, C++ is rapidly evolving and by learning Modern C++ 14 now, you can avoid a lot of the mistakes of C++ that were common in the past and write safe, elegant code. C++ is also experiencing a renaissance (see https://www.jetbrains.com/cpp/cpp-today-oreilly/). C++ is now the one high-level language that is natively supported by the system vendor across Windows, Linux, Mac, iOS, Android, Windows Phone, XBox, and Playstation.

⬐ seren

I agree about the universality of C++. I also agree you have to compare C++ + code analysis versus Rust regarding safety. However, my team is spending over 100k$ a year to get access to these tools. In the grand scheme of things, compared to the salary and other expenses, it is insignificant.

But for a small team for a new project, it is probably easier and more cost-effective to use a language that is safe from the ground up, rather than relying on external vendors. (Most of these tools have a free option for FLOSS projects, but you might need to develop something closed source)

I honestly don't know if this is something that can tip the balance, or if this is a "detail". Time will tell.

⬐ jbandela1

Take a look at Herb Sutter's talk from CppCon 2015. The slides are here (https://github.com/CppCon/CppCon2015/blob/master/Keynotes/Wr...) and the video is here https://www.youtube.com/watch?v=hEx5DNLWGgA.

Microsoft will be releasing the static analysis tool as a free cross-platform tool (and I think open-source IIRC). They shipped a preview for Visual Studio 2015 with Update 1, and are planning on shipping a cross-platform version soon. As tools like this become free and ubiquitous, it will greatly improve C++ code safety.

At this year's CppCon Herb Sutter the chair of the ISO C++ committee addressed just this issue of lifetime safety. Here is a video of his talk and includes a demo of the upcoming static analysis tool that can do this with very minimal annotations https://m.youtube.com/watch?v=hEx5DNLWGgA

I remember thinking when watching the talk that this was a very bad day for Rust as C++ could now do most of what Rust was promising

⬐ pcwalton

The lifetime stuff in C++ is full of annotations, with effectively just as many required as Rust. I think of it effectively as a separate language. It's also significantly more complex, with points-to analysis instead of inherited mutability, and the restrictions on pointer aliasing on function entry seem very restrictive compared to what RefCell provides.

I think that Rust's system has proven itself to be about as simple and easy to use as you can get in this space. I also think that you cannot just "bolt on" a lifetime system to an existing language that was not designed for it without large amounts of annotation, modification of existing code, and additional learning curve.

⬐ weinzierl

Also Rust has the freedom to just leave dangerous features out of the language [1]. This is something we will never be able to do with C++ without transforming it in a not backwards compatible manner.

And it's not only about safety: a language that doesn't suffer from the consequences of legacy design choices is just less mental burden, easier to learn and easier to teach.

[1] http://graydon2.dreamwidth.org/218040.html

⬐ jguegant

One can simply ditch the C++ backward compatible features into an "unsafe" part of C++. That's exactly what the talk given by Herb at the CppConf is trying to address. All the old unsafe part of C++ will trigger errors or warnings. But if truly necessary one will be able to disable these protections!

⬐ pcwalton

> All the old unsafe part of C++ will trigger errors or warnings.

And by breaking backwards compatibility so heavily, it effectively makes the new safe C++ into a different language.

⬐ jbandela1

I was at the presentations, and basically other than owner<T>, and [[suppress]] I do not remember other annotations. In fact, Herb made a point that having too many anotations was a weakness of Rust, and that they wanted to not have those annotations. There were some types to use such as array_view, string_view etc, but not annotations. Perhaps you are thinking of Herb's slides where he shows things like _In_reads_(num). Those are not part of GSL. He was just contrasting the annotation heavy way Microsoft does static analysis now, with the GSL which does not have these annotations.

⬐ steveklabnik

  >  Herb made a point that having too many anotations was a weakness of Rust,

While he did say that, some other comments of his made it sound like he had checked out older Rust, without elision and with pointer sigils and stuff.

⬐ Manishearth

Check out the actual paper on the isocpp github repo. There are `[[lifetime(foo)]]` annotations.

Their proposal does include more elision than Rust (which actually leads to a loss of expressivity of patterns that arise in complex systems), but they still have plenty of annotations.

⬐ pcwalton

I'm referring mainly to [[lifetime(this)]] and friends. Those correspond directly to the lifetime annotations in Rust. Read the paper for more details.

> In fact, Herb made a point that having too many anotations was a weakness of Rust, and that they wanted to not have those annotations.

That's because Herb didn't understand Rust.

> Perhaps you are thinking of Herb's slides where he shows things like _In_reads_(num). Those are not part of GSL.

No, I'm referring to the annotations I saw in the paper: https://github.com/isocpp/CppCoreGuidelines/blob/master/docs...

⬐ pjmlp

The danger here to Rust is the usual "worse is better".

OS vendors will happily just add GSL and static analysis driven support to C++, with Rust becoming the language that drove them to do that and that is it.

Microsoft (GSL + static analysis, C++/CX, System C#, .NET Native) and Apple (Swift) are already working on what might be their next systems programming language.

They might lack full Rust like safety, but they are a good enough incremental approach to safety, come with integration with their existing tools and libraries.

Which leaves Rust adoption for systems programming to other OS vendors, e.g. embedded space or open source OSes.

Remember, languages are a tiny portion of the whole eco-system. Tools, libraries and community play a bigger role.

⬐ jguegant

Exactly! No matter the future of Rust, it has already shaken the programming community and motivated the other language designers to catch up in that domain.

As to guess whether Rust will put down C++ forever and ever, is another hard question. It will be a matter of community and sadly money... For instance, Apple's already got a much better market share with Swift (look at the job trends) simply because it's Apple. Same goes for JavaScript greatly helped by Google (V8) for their interest (a faster JavaScript engine ==> better usage of Google's web services).

⬐ pcwalton

> Microsoft (GSL + static analysis, C++/CX, System C#, .NET Native) and Apple (Swift) are already working on what might be their next systems programming language.

Swift at least isn't in the same space as Rust. It's a fully garbage-collected language.

> Remember, languages are a tiny portion of the whole eco-system. Tools, libraries and community play a bigger role.

And Rust has the most memory-safe low-level systems code available today. It also has Cargo and crates.io, which allow that code to be easily reused.

By contrast, existing C++ code isn't safe C++ code. It will have to be ported, often by drastically altering the idioms in use, and that takes a lot of time.

⬐ pjmlp

> Swift at least isn't in the same space as Rust. It's a fully garbage-collected language.

Have you spent any time reading Apple documentation?

https://developer.apple.com/swift/

"Swift is a successor to both the C and Objective-C languages."

Mesa/Cedar at Xerox PARC was also systems programming language with RC.

Going back to my comment "Remember, languages are a tiny portion of the whole eco-system. Tools, libraries and community play a bigger role.".

<devil advocate mode>

Give me Swift like Playground, Instruments integration, XCode and LLDB integration. Ability to call any Mac API the same way Swift does. Then maybe our customers will request Rust for our iDevices projects.

Give me Visual Studio integration, ability to define WinRT controls like C++/CX, create and debug COM like VC++, mixed mode debugging with .NET. Then maybe our customers will request Rust for our Windows projects.

</devil advocate mode>

Again, I am pretty aware that Rust is way better than half baked solutions like GSL + static analysis, but I have quite a few grey hairs already.

My first C++ compiler was Turbo C++ 1.0 for MS-DOS, remember when it was just released?

I also remember when C had zero presence on home computers.

Which means I was there when Ada, Modula-2, Modula-3, Oberon and derivatives were steam rolled by OS vendors betting the house in C.

As an early C++ adopter, I also carry quite a few flame war scars from being on the C++ side of the fence back on those days (vs C). As I always advocated for the C++ improved safety over what C offers.

> And Rust has the most memory-safe low-level systems code available today.

I agree, but do the OS vendors that sell the SDKs we are allowed to use, also agree or will hide their head on the sand and do another round of "worse is better" with their tools?

> By contrast, existing C++ code isn't safe C++ code. It will have to be ported, often by drastically altering the idioms in use, and that takes a lot of time.

Yes, but the eco-system is already here. Which means most companies will rather endure a slow Python 2 to Python 3 code re-factoring than move to another language.

I really want Rust to succeed and be the language I can use whenever I have to go outside JVM, .NET and mobile worlds.

However I have seen too many nice languages become victim of "worse is better" syndrome.

So sorry if my type of "heads up comment" isn't welcome.

⬐ dbaupp

> "Swift is a successor to both the C and Objective-C languages."

Saying something doesn't automatically make it true... however, I believe it is in this case, but maybe not to the degree the quote/you imply: it seems to me that current Swift may not be the best choice for say, writing the kernel itself, or extremely demanding components like a JS engine/the core of a web-browser.

> Remember, languages are a tiny portion of the whole eco-system. Tools, libraries and community play a bigger role

NB. the Rust leadership understands this: it's part of why crates.io was an early investment (and literally an investment: Mozilla put money into it), and why there's a pile of efforts towards improving tooling, including IDE integration.

> So sorry if my type of "heads up comment" isn't welcome.

Well... you do make a comment along these lines on essentially every Rust thread here, so it may be getting a bit repetitive at this point.

⬐ pjmlp

Maybe because since the mid-90's I have seen any safer alternative that I liked being steamrolled by the C and C++ duo, where the authors shared the same enthusiasm.

I will abstain from such comments from now on, hopefully Rust will succeed where the others failed.

⬐ steveklabnik

While I'm glad to see C++ improve, and I'm happy that Rust seemed to influence this, I don't think that it will kill either Rust or C++.

As you say, there's a ton of C++ code out there. However, five things:

  1. A _lot_ of that is C++98.
  2. These rules are just proposed. There's tons of time.
  3. They don't give you as much safety as Rust.
  4. Many people have already rejected C++.
  5. Langauges don't die.

So, one and two are kind of related. We're still in the "propose" stage for all of this, which means there are still years before this would make its way into the standard. How long have things like modules taken? Who knows when the rules will be final, and when they'll actually land. You get all of this (and more) in Rust right now.

As for three, while these rules help, and are laudable, they still don't give you data race freedom. In general, they're not intended to be an ironclad safety system, just something to help catch more cases where something went wrong. See Herb's insistence that pointers should be able to dangle in some circumstances, as an example. I saw a comment on Reddit that straddles three and four, here it is: https://www.reddit.com/r/programming/comments/3m6j2c/cppcon_...

   > Just follow this set of hundreds of rules (seriously, go read the core
   > guidelines), ignore 20 years of material written about C++ before the
   > year 2011, use this non-standard third-party library of stuff we
   > really like, and you too can have a fraction of Rust's compile safety.

This is phrased a little to sarcastically imho, but there's a nugget of truth there. One of C++'s problems is that it's just got too many features, bolted on over decades. Is bolting on yet another feature the way forward? How much of that existing C++ code will even be able to take advantage of these new safety features?

A lot of people have already rejected C++, for various reasons. The details of those reasons are varied, and may be good reasons or bad reasons, but the point is, they've already said nope. A lot of people coming to Rust fit in this category. "I tried C++ one time, but it's too complex." "I can write some basic C++, but I'm not confident my code is correct." "I write Ruby code, C++ looks terrifying, and I hear it's hard never tried it." And so on. Our industry is huge, there are a lot of developers, and not all of them will use a single language even if it's 'better.' That cuts both ways.

And ties into five. I don't think the question "Will Rust kill C++" is well formed. A language that's used as much as C++ is will never die. We'll have C++ code in production for at least my lifetime, I'd bet. Rust doesn't need for C++ to go away. Languages aren't the Highlander, there can (and often are) more than one. I mean, look at Python and Ruby. They're really similar languages from a PLT perspective, but they're both active, healthy, used-by-millions languages, and many of their programmers wouldn't switch to the other. This is totally fine.

⬐ Manishearth

IMO "kill C++" is better replaced with "Will Rust or isocppcore be the language of choice for new C++ codebases". Where "new" includes dependencies (i.e. a project heavily dependent on an in-house C++ library used elsewhere doesn't ocunt)

I think in the majority of cases this might turn out to happen.

⬐ pjmlp

I hope that Rust succeeds in the mainstream.

If anything, please take my point of view of someone that cannot ever use Rust until the customers say I am allowed to.

On my type of work we only use first class languages, those that are provided as part of whatever platform we are targeting.

This is my point of view of "worse is better".

Many might have rejected C++ or C (e.g. I don't like C at all), but many more are on the same boat as I.

For us system programming means C++ and C, until the IT department or customer allows anything else on our dev machines.

⬐ steveklabnik

Absolutely. This is part of why I think "Will C or C++ die" is a silly question. We're in total agreement here.

⬐ jbandela1

I agree. We are not starting out with a blank slate. There are already billions of lines of C++ in mission-critical production use. Companies such a Microsoft, Apple, Google, and Facebook run on C++. In addition, it has vendor support on all the major operating systems. In contrast, not even Mozilla, has bet the company on Rust (Servo is experimental and Mozilla has made no promises of actually integrating it into Firefox.) Also, Rust is not vendor supported on any platform.

So if you are a CTO or someone who has the responsibility of deciding what language to use for your performance critical software, you already have a large bias toward C++. You may be swayed toward Rust by the fact that Rust is memory safe. However, when someone comes and tells you that with this open source tool for C++ backed by the big names in C++, and developed and supported by Microsoft, and just by using the GSL types you can get most of the benefit of Rust, you will decide that the delta of improvement of Rust over C++ is not worth it.

TLDR: In programming language use pragmatic considerations trump purity. Multibillion dollar companies run on C++. With GSL and static analysis, C++ is "good enough".

⬐ tatterdemalion

I agree that this might be a reason that people delay adoption, but I think things will change when the people who adopt Rust do better than the people who don't. This is similar to how things changed when people who adopted scripting languages for their web apps did better than people who didn't.

⬐ Manishearth

> Mozilla has made no promises of actually integrating it into Firefox.

Rust is already being integrated into Firefox

⬐ jguegant

I am genuinely interested in this. Do you have any good reference about it?

⬐ Manishearth

https://bugzilla.mozilla.org/show_bug.cgi?id=1135640,

https://bugzilla.mozilla.org/show_bug.cgi?id=1151899

https://bugzilla.mozilla.org/show_bug.cgi?id=1161350

Still a work in progress.

⬐ pcwalton

That is very '90s, pre-programming-language-Renaissance thinking. If that thinking actually dominated, then you would never have seen the rise of Python, Ruby, Go, Node, Perl, PHP, Scala, Clojure, and so forth during the 2000s and 2010s. During the '90s, people predicted that Java would be the last programming language that anyone would ever use, using the same kinds of reasoning. That turned out to be false.

> You may be swayed toward Rust by the fact that Rust is memory safe. However, when someone comes and tells you that with this open source tool for C++ backed by the big names in C++, and developed and supported by Microsoft, and just by using the GSL types you can get most of the benefit of Rust, you will decide that the delta of improvement of Rust over C++ is not worth it.

Replace "Rust" with "Ruby on Rails", "C++" with "Java", and "GSL types" with "Spring", and you could make the same statement in 2005. It might even sound plausible. It would also be an incredibly wrong prediction.

> There are already billions of lines of C++ in mission-critical production use.

How many lines of memory-safe C++ are there in production use? The amount of memory-safe Rust code far exceeds that.

Ergonomics and the ecosystem matter. The fact is that the proposed static analysis tool for C++ is very restrictive and complex, from everything I've seen so far, and coupled with the annotation burden equal to that of Rust effectively makes it into a completely different language.

We should be seeing completely safe C++ code soon.

Take a look at Herb Sutter's CppCon talk this year:

https://www.youtube.com/watch?v=hEx5DNLWGgA

Reinventing the wheel isn't entirely necessary. Though if you're a SysAdmin and you write your codebase in Rust.. that's some nice job security. ;)

⬐ gmjosack

I'd already looked through the slides for that talk but I'll check out the video. Thanks!

I think C++ has a lot of awesome stuff coming out but I find Rust more pleasant to code in. Also having package/dependency management has been great compared to using the old versions of libraries that come with distros or tracking down all the transitive dependencies of software. Rust is just a more delightful experience out of the box.

> Though if you're a SysAdmin and you write your codebase in Rust.. that's some nice job security. ;)

I definitely understand this but I don't think it's true and will be less and less true over time. It is becoming very common in the SRE/SysAdmin industry that strong coding skills is a requirement. When I started 10 years ago that was very different but it's becoming harder and harder to find jobs as a Linux grunt. The SREs I work with care about software engineering best practices, code review, testing, continuous integration, etc.

Also, even if that were true, I'd much rather have people with a weaker understanding contribute to Rust where the compiler has your back. If you haven't used Rust you might be surprised how good the error messages are. Once you spend a bit of time understanding the basics the compiler is super helpful.

⬐ yokohummer7

Like I said somewhere, a safe subset of C++ sounds wonderful at first, but it also has demerits:

- If you enforce memory safety to all of your code, the number of the libraries that you can use will be severely limited. Imagine if you can only use C++14 libraries. How many C++14 libraries are out there? And I'm not sure if there will be many libraries written in safe C++, at least for the next few years. The adoption rate for newer C++ standards (C++11, C++14) was generally not satisfactory.

- If you only enforce memory safety to your own code, then you could use the existing ecosystem. But in that case, your program will still segfault because of the libraries you're using. Admittedly this is also a concern of Rust when you use C libraries in Rust. The more safe code you use, the safer your program is. The problem is, if you choose this route, there's not much ecosystem-ish advantage in the C++'s side. You will also have to "reinvent the wheel" as you would have to do in Rust.

This problem all boils to this: adding guaranteed memory safety to the unsafe language is a breaking change. And the problems occurred by breaking changes are very hard to solve.

⬐ something123

Rereading your comment it feels like you've moved the goal posts and are being overly cynical. (This presentations essentially addressed your previous concern by providing interoperability between new safe code and existing code that doesn't have safety guarantees)

These are valid concerns, but you're being very dismissive of the benefits

I think confining errors to libraries is generally a good strategy. In effect you are guaranteeing that you're not going to introduce any new unsafe code.

It might uncover errors in the existing code.. but that's a much smaller issue and one that fades with time (esp if you're talking about libraries that a lot of people are using)

Is this "good enough" for a brand new aircraft-control/heart-lung-machine system? Maybe not. Maybe then you should start from the ground up using either Rust or C++/GSL entirely. But I think for most use cases this is sufficient and brings huge immediate benefits now. And of course with time libraries will be updated to include safety guarantees (which for the most part seem like it wouldn't involve a ton of work)

This is more of an organic process that basically in some form preserves the millions of man hours people have invested in C++ and less of a clean slate solution. As I've said before, you gotta make a living now in the current reality with the current codebases and the current tools. You can't just judge languages in a vaccuum.

⬐ yokohummer7

> which for the most part seem like it wouldn't involve a ton of work

This is probably the reason why our opinions vary. I believe rewriting existing libraries to be safe would be a tremendous amount of work. This estimation comes from my experiences with Rust. Safety guarantee hugely affects the interfaces of the libraries. You cannot "just" gradually increase safety of your library. It is basically a redesign. At least with what Rust currently provides this was my experience. And the method suggested by Herb Sutter seems to be very similar to Rust's. So I expect the same churn to happen in the C++ ecosystem, and it would effectively split the ecosystem into two: safe ones and unsafe ones.

Let me rephrase myself again: if adding safety to C++ in a gradual manner was that easy, Rust would have not been invented in the first place. The Mozilla guys could just use C++. There's a reason why Rust had to exist, despite all the "reinventing the wheel".

⬐ something123

I guess it's a matter of opinion but I think you're wrong that you have to redesign stuff. Most of the guarantees in essence already exist b/c of best-practices (like RIIA) - they're just not guaranteed by a validating program.

Don't diminish it, b/c the presented solution is non obvious/trivial. If it was, it would have been done ages ago.

So either A - The Mozilla folks may have not thought of this solution

B - At the time of Rust's development C++ was stagnant and not evolving as it is right now. There wasn't a lot of hope for fixing it at the time. It's thanks to the work of several people that the C++ standards committee now is a fast moving organization.

If Mozilla were considering starting the Rust project in 2016 I don't think they would have gone ahead with it

⬐ MichaelGG

Once C++ allows people to flip a switch to produce guaranteed memory safe code, then it can start really comparing itself on that metric. (This would be fantastic. Think of the resources that'd be spent on such research! It'd be world-changing.) But even then, the inherent differences in a statement oriented vs expression oriented is likely to keep C++ being needlessly verbose.

And I object to using Rust (or other production-level but "edge" languages) as being "job security". If the underlying software matters enough that using Rust has significant benefits, then it matters enough that employees spend a few days learning a bit of Rust. This fear of languages as if learning a language was this huge mountain to scale in hiring is just silly. The actual code and environment probably outweighs the language used significantly.

The real exception to this is if you're running a codebase that has essentially non-programmers adding bits here and there. Somewhere where you know that the individual contributors will find learning a language to be a higher barrier than contributing new pieces of code. (So either a rather trivial system, or contributors that have an unusually low capacity.)

⬐ blub

I think you mean employees spend half a year to know enough Rust to be comfortable. That's how long it took me and others on my team to learn Java at a level where we knew the idioms, patterns and enough of the libraries. All of us had significant experience in other OO programming langauges.

Learning a language in days is a fairytale, the fact that you're so cavalier about this point makes it seem that you're more interested in doing advocacy than having an honest discussion.

⬐ MichaelGG

I've hired people to work on .net apps (C#) as well as hiring devs with no F# experience and this is simply not my experience at all. I hired someone to do a spike of a project in Rust, ditto. And just this last week I met with one of my consultants that just started using F# the week prior. His F# code isn't quite idiomatic but he's written ~1000 lines of usable code. I've personally investigated and made bugfixes to a system written in a language/platform in which I had no experience.

Therefore I think it's quite fine to say it takes a few days to learn a bit of a language, enough to start contributing. Enough that it's not "job security" to pick something that provides a real benefit.

⬐ kibwen

Take the amount of time that it takes to become comfortable in a given language, and now increase that by an order of magnitude: this is how long it will take you to become comfortable writing C++ unsupervised. The language simply has too many subtle footguns to allow a beginner to be unleashed on a codebase (compare Java, where the worst a beginner will do is write a tangled mess of inflexible classes, but it will still largely work). The massive quantities of pre-C++11 documentation out there aren't doing the language any good either. And colleges (with the exception of game development programs) aren't teaching C++ anymore (and where they are, they're teaching C++98/03), so writing anything new in C++ means you're either going to maintain this yourself in perpetuity (talk about job security), or you're going to commit to a long period of coaching a beginner on the language, or you're going to hire an experienced C++ programmer for a significant multiple of what a less specialized programmer would have cost you.

So in the context of a conversation about the costs of training and long-term maintainability, well, you should probably write all your stuff in Java, but if you can't, then you're better off selecting Rust over C++. I can teach Rust to anyone that knows Python, and once you know Rust you're at least familiar with the most useful subset of C++.

⬐ blub

There are plenty of C++ programmers to hire from. I know because we are hiring both at experienced and junior levels. Furthermore, a C++ programmer is not significantly more expensive than other programmers according to SO salary surveys. An experienced programmer will demand a good salary no matter which language he uses.

I gather from this post that you seem to use a risky strategy for your development - let juniors loose on a problem and hope that Rust/Java will save them. Or is that just a straw man? In any case, all juniors should get coaching, CI with static analysis and code reviews are likewise highly recommended.

Finally, I can't understand how someone can recommend Rust over C++ for long-term maintainability with a straight face.

The first stable version of Rust was announced four months ago, let's talk again in 10 years and see how your code from 2015 is doing.

Sure. That was kind of my point.

Still, as Herb Sutter asked at CppCon 2015: "How many of you have your own homegrown string types at your companies? ... Don't lie. ... Right. And those of you who didn't put up your hand and are just bashful, ... we know we have them." [1]

[1] https://youtu.be/hEx5DNLWGgA?t=1373