
Bjarne Stroustrup Weighs in on Distributed Systems, Type Safety and Rust - rsecora
https://thenewstack.io/c-creator-bjarne-stroustrup-weighs-in-on-distributed-systems-type-safety-and-rust/
======
distsysdude
> He’s aware of other languages, as he reveals in his answer to a later
> question. (“I think C++ can do anything Rust can do, and I would like it to
> be much simpler to use.”) And towards the end, he couldn’t resist noting
> that longevity has its advantages. “It’s highly humorous when some of the
> Rust people come up and accuse me of having stolen some of their ideas
> without acknowledging — when some of the things I did I actually did almost
> 40 years ago.”

Does anyone know what these accusations were? Given that C++ has been around
for so long, It's incredulous to think that anyone from the Rust community can
put forth such a claim.

~~~
nindalf
The only thing I can think of is modules, which C++20 is planing to introduce.
But I would be very surprised if anyone was accusing anyone else of "stealing"
ideas. It's preposterous because 1. every language copies good features from
others (that's a good thing) and 2. Rust has copied a lot from C++.

I wish people wouldn't talk about one or two people with a warped view as "the
community".

~~~
throwaway894345
> I wish people wouldn't talk about one or two people with a warped view as
> "the community".

At least in the quoted sections, they weren’t talking about the opinions of
the rust community, but rather those of _someone from the Rust community_.

~~~
nindalf
My point is that saying "Rust community" implies that this person represents
the community in some way or worse, is representative of the community.
Neither is true. It's just some random person with no credentials. That person
is no more the Rust community than I am the HN community. Imagine how you'd
feel if people made assumptions about you based on what nindalf said that one
time.

------
diego_moita
> Once you get users, you have responsibilities, and one of the
> responsibilities is not to break their code.

That is both a good and bad thing.

Within both C++ and JavaScript there is a very elegant programming language
with powerful semantics.

However, there are also a lot of bad solutions and dangerous hacks
accumulated. And most of us programmers don't know how or don't have the self
discipline to separate the good parts from the bad parts. And sometimes even
with the knowledge and self discipline you can't avoid them (e.g: when using
someone else's libraries).

In some languages (e.g: Lua, Python) the designers are ready to break
backwards compatibility. C++ chose not too.

~~~
vii
Perl was the #3 language on the Tiobe ranking in 2005. It had massive
codebases in banks and other industries. In 2019 it was ranked #19 and the
incompatible replacement, Perl6, is #93. Breaking backwards compatibility is
hugely costly. It creates immense work as people have to validate that new
versions of previously working code meet the implicit, accumulated
requirements.

Old code will always seem old fashioned. It will not address modern concerns.
However, the option to keep using it is very valuable!

~~~
nindalf
Two things - TIOBE is meaningless. And secondly, Perl is a valid example, but
so is Python. After a 10 year painful transition, Python is more popular than
ever. It's used more than any other language bar Javascript.

~~~
hota_mazi
> Two things - TIOBE is meaningless.

Pick any other language survey of your choice and I guarantee you it will
generally agree with the TIOBE.

~~~
rumanator
Agree with what? TIOBE is just a vague measure of online chatter. I mean,
right now TIOBE's site has a section on how Go, Swift, and SQL are tied. What
is there to agree with? I mean, you can add "burrito" to TIOBE and the result
would be just as meaningful.

~~~
dgellow
That's maybe a good name for a successful programming language :) TIOBE driven
design is the future!

------
sprite
A bit off topic but I didn’t want to make a separate post for this. I want to
brush back up on C++ and learn all the modern features. It’s been over 10
years since I’ve touched any C++ and looking for a good book recommendation
for someone that’s familiar with many other programming languages and has
programmed quite a bit of c/c++ in the past.

~~~
arnarbi
Second for Scott Meyer Effective Modern C++. I was in the same situation as
you and it seemed like the book was written almost specifically for that.

~~~
billti
I love Scott’s books. Not just for the quality of the content, but also for
the humor he manages to inject into a quite dry topic.

That said, I find he only covers a few of the more tricky topics, then after a
brief “this is what it is and why its useful”, then spends more time on “these
are all the edge cases that are dangerous and confusing”.

Maybe he’s right and it’s important to learn all that. But I tend to finish a
chapter and think “Cool feature, but I’ll never remember all those foot-guns
so I’ll just avoid it if I can”.

But maybe that’s a fair take on C++ <shrug>.

~~~
arnarbi
I really like that he points out the dragons.

Most books just explain the language/system design, and add value only by
crafting good explanations. But Scott (and others) add an element of
experience as well, which is extremely valuable.

I don't think you need to learn all the corner cases, but reading about them
at least helps me a lot with understanding the underlying semantics. And when
I do run into them, I might get a vague uncomfortable feeling that's enough to
make me go back to the book for a reminder.

------
cletus
In Rust, ownership is a compile-time issue. This puts constraints on how you
can use references, how ownership is passed around and so on. This programming
model has a cost to the user and is probably inherently slower to compile just
because the compiler has to do more.

But at runtime it's essentially free.

C++ on the other hand added a set of primitives starting in C++11 to be
explicit about ownership through std::unique_ptr and such. These have a
runtime cost and ultimately mean getting locks. I've seen estimates of this
cost in the single digit microseconds. Not exactly super-expensive but not
free either.

There are simply some assumptions Rust can make that C++ can't because certain
things aren't possible in Rust.

Another example: Rust doesn't have exceptions. Over the years I personally
have some to believe that exceptions are largely a false economy (particularly
the failed experiment that is/was checked exceptions in Java).

Instead Rust has match expressions and enumerated types (with state!) that
force you to deal with return types. This BTW is very much what Google C++
looks like. It's even debated if you can ever write truly exception-safe C++
code.

This is another problem Rust doesn't have by virtue of not having the feature.

Are you starting to see the pattern? C++ has everything in it. That comes at a
cost and there's no getting around that.

~~~
quietbritishjim
> ... std::unique_ptr and such. These have a runtime cost and ultimately mean
> getting locks. I've seen estimates of this cost in the single digit
> microseconds.

You're no doubt thinking of shared_ptr (which I guess is what you meant by
"and such"). That has a reference count, which does not lock but does use an
atomic counter with the usual costs that involves. unique_ptr has no such
thing and is essentially free.

~~~
eska
It's not essentially free

[https://m.youtube.com/watch?v=rHIkrotSwcc](https://m.youtube.com/watch?v=rHIkrotSwcc)

17:40

~~~
quietbritishjim
I'd rather you'd just stated your objection instead of making me watch a bit
of video. Thanks for at least including a time stamp. For the benefit of
others: Using a std::unique_ptr adds exception handling code to the functions
that use it to guarantee cleanup when exceptions are thrown. Of course, that
extra code is not actually executed if the exception is not thrown.

I was responding to a comment that claimed that std::unique_ptr used locks to
transfer ownership, and my objection to that is not disputed by what your
saying.

You're making the point that exception-safe code is less efficient than
exception-unsafe code. I do not know enough about that topic to comment on
that matter, I was never trying to say anything about it in my previous
comment. But I would like to point out that Rust has an analogue of
exceptions: panics (although you can change their behaviour to abort() instead
of unwind). So it must have something similar to unique_ptr's unwind handler
anyway.

~~~
eska
Nah, you missed the main point, it doesn't deal with exceptions. But since you
misuse the downvote feature after I looked for the video and timestamp for
you, I guess you don't want to be proven wrong anyway. Have a nice day.

~~~
quietbritishjim
You can't downvote direct replies to your comments, you'll notice the downvote
button is missing for you on this comment of mine. That must be someone(s)
else.

What do you mean by "it" in "it doesn't deal with exceptions"? Rust? Or the
C++ snippet on the left hand side in the presentation with the shorter
assembly output?

Edit: Since I'm still apparently not clear on your main point, this might be
irrelevant, but here [1] is a Godbolt link showing that Rust functions have
similar panic-safe unwind code to the C++ exception unwind code shown in the
presentation. Admittedly the Rust version does seem a bit shorter (comparing
just the actual function, at the bottom of the Godbolt output) and I'm afraid
I don't know enough assembly to be able to analyse the difference. But I think
the principle is similar.

[1] [https://godbolt.org/z/K1xPr3](https://godbolt.org/z/K1xPr3)

------
an_d_rew
Also, don't forget that C++ has _age_ behind it. Lots of places are still on
arm-gcc-5 because heaven forbid you try to get a new compiler digesting an old
code base, then get all stakeholders and customers onboard.

I dream of C++20. But my nightmares are all pre-C++14.

~~~
pjmlp
And that will happen no matter what language, just the other day I was reading
about poor souls still having to deal with Java 6 code.

------
hu3
> We have a model for better concurrency coming up. Almost certainly it will
> be in [C++ version] 23. It exists and it’s used. It’s backed by people like
> Facebook and NVIDIA and Intel… So that’s where we’ll get a better
> concurrency, better use of hardware… Beyond that, I am looking at
> functional-style pattern matching...

Better concurrency and functional-style pattern matching? Yes please.

~~~
rainbow-road
Does anyone know what Stroustrup is referring to regarding "better
concurrency"? It sounds interesting but it's way too vague.

~~~
steveklabnik
I believe the big feature slated is executors.

~~~
The_rationalist
Something like that?
[https://docs.oracle.com/javase/7/docs/api/java/util/concurre...](https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Executors.html)

What I would like to see in C++ would be green threads and use of io uring and
restartable sequences like in project loom.

~~~
steveklabnik
Yes, same concept.

C++20 added coroutines already.

------
pojntfx
Does the case for C++ in 2020 still exist? Rust and Go are much simpler to
learn, can do everything that C++ can and have sane, simple and clean build
systems/package managers, not to mention async/await concurrency in the former
and channels in the latter.

~~~
jfkebwjsbx
> Does the case for C++ in 2020 still exist?

The question is the opposite: you have to prove to managers the benefit
overcomes the risk of using a new language. Rust is still not nearly stable
nor popular enough for many fields.

Go is a very different language with different goals and constraints, so the
question does not really fit.

> Rust and Go are much simpler to learn

Go is a simple language, yes. Rust is a different beast with the same
intrinsic complexity as C++.

> can do everything that C++

Not exactly true (for the moment). Rust is lacking on const generics, HKTs and
other details.

> sane, simple and clean build systems/package managers

That is not a big argument for the kind of projects is used for.

And it is not true either, since nowadays there are several competing, modern
package managers for C++ too (build2, Meson, Conan, modern CMake...).

> not to mention async/await concurrency

The async IO model has been available in many languages for many years,
including C++. In the recent years several languages (including Rust and C++)
are bringing syntax sugar to let the compiler create the state machines. But
it is not the only way of doing async.

~~~
mlindner
> The question is the opposite: you have to prove to managers the benefit
> overcomes the risk of using a new language. Rust is still not nearly stable
> nor popular enough for many fields.

I'm not sure what you're saying. Rust 1.0 code compiles just fine in the most
recent rust compiler. It's been stable since that 1.0 point and promises to
continue being stable. C++ doesn't have a a stable ABI either.

------
atombender
Does anyone have an example of a large codebase that actually uses modern C++
to its fullest?

One of the larges codebases I know about, Chromium, seems to use only a
minimum of C++ features. It's mostly limited to 1980s "C with objects"
paradigm, plus smart pointers.

~~~
lorenzhs
It's not as large as Chromium by far (~55k lines + ~27k lines support
library), but I quite like the Thrill codebase. It's a research prototype (but
not what you would typically associate with "research code") of a big data
platform like Spark but in C++. It makes nice use of lambdas with return type
deduction, some template metaprogramming in the internals, smart pointers &
RAII, and generally uses lots of modern C++ features. [https://project-
thrill.org/](https://project-thrill.org/) and
[https://github.com/thrill/thrill](https://github.com/thrill/thrill)
(disclosure: I know the authors and have worked on/with it for a bit).

~~~
atombender
Perfect, thanks! Looks like an interesting project. I've bemoaned the
dominance of Java in the distributed data processing world for a long time,
and I didn't know about Thrill.

------
luord
“I don’t believe that there is or could be a perfect programming language — at
least not in the time scale we’re talking about, a few decades or a hundred
years. Maybe in a hundred years, but not in my lifetime.”

Absolutely agree and wish more people did.

------
lajawfe
He talks about fixing Exceptions in c++, what is wrong with exceptions in c++
and how would you fix those? Go does not have exceptions, but I don't think
Go's method of checking for error on every step and doing early returns is
more elegant.

------
ryeguy_24
> "Users spend most of their time on other sites. This means that users prefer
> your site to work the same way as all the other sites they already know."

While likely accurate, this thinking is likely not conducive to UX innovation.

~~~
hu3
I think you meant to comment in the Laws of UX thread:
[https://news.ycombinator.com/item?id=24030969](https://news.ycombinator.com/item?id=24030969)

Sorry if my assumption is incorrect.

------
arcticbull
> “I think C++ can do anything Rust can do, and I would like it to be much
> simpler to use.”

I think Bjarne isn't getting the _issue_ with C++. Yes they're Turing-
complete, yes they can both solve the same set of problems.

The issue is that C++ can do _everything_ that _every_ other language can do,
which means it's not a language, it's a universe of features. You make the
language by picking which features, patterns, philosophies, architectures you
want. It's like if a language dictionary included English, simplified Chinese
and Korean.

The problem IMO is there's no such thing as C++. Each company, each team, each
person has their own. Many of these C++'s are incompatible with each other.

Worse, many of the new language features can't be properly implemented because
they would break someone else's C++.

The problem is it tries to be everything to everyone, and that makes it (and
futures standardization efforts) full-on Quixotic efforts. I mean, by all
means, have at those windmills tho.

Bjarne points out how much he hates templates, and has some great new ideas
for generic programming. Lovely, but he's never gonna get rid of templates, so
now we have 2 problems.

~~~
whateveracct
Rust actually can do things C++ can't do. People who use Turing equivalence to
equate language capability are just uneducated imo.

There's another "truth" of PLs: Curry-Howard. So a language with a richer type
system can express more propositions than a lesser one. Just because two
languages are Turing equivalent doesn't mean they are Curry-Howard-equivalent.

So the things some languages can do that others can't happen at compile time.

And tbh, you'd probably be better served by a language that isn't Turing
complete but allows you to express rich types than a Turing complete language
with a bad type system. Very little of people's code needs Turing
completeness.

~~~
postalrat
Can any code written in rust be transpiled to c++ without losing something?

~~~
smitop
No. There is no version of the env! or include_str! macro! in C++ (they are
implemented in the compiler for Rust). These macros can be used to the get the
values of environment variables or the contents of arbitrary files at compile
time. You could of course implement them within a build system, but there
isn't a way to replicate these macros with just pure C++ being passed to a
compiler, even with pre-processor macros.

~~~
slavik81
File embedding seems to have been a low priority for the standard, perhaps
because there's always been workarounds, but it has gotten some attention
recently with the std::embed proposal: [http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2018/p104...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2018/p1040r0.html)

------
tybit
I’d love to know how he’d like for C++ to support distributed systems in broad
strokes.

The first thing that comes to mind is things like gRPC or the actor model but
I can’t imagine he has either of those in mind.

~~~
pjmlp
C++ was born for writing distributed systems at Bell Labs actually.

[https://www.stroustrup.com/hopl-almost-
final.pdf](https://www.stroustrup.com/hopl-almost-final.pdf)

~~~
zzz61831
_" The work on what eventually became C++ started with an attempt to analyze
the UNIX kernel to determine to what extent it could be distributed over a
network of computers connected by a local area network."_

That was the only connection it had to something "distributed". In a literal
meaning of the word, not distributed systems.

The problems distributed systems actually face were never addressed by C++ in
any way. Something like meta facilities for implementing actor runtimes and
using an actor model could be the first step, but who knows what Stroustrup
was talking about, maybe it's all just marketing buzzwords useless for
distributed systems, like in most languages that claim distributed systems
support.

~~~
sumtechguy
Most of my issues with distributed came from poor over the wire interop. Very
crappy libs that would serialize and deserialize in amazingly bad ways. Or
some descriptor lang (like idl). Then God help you if you had two different
CPU/compiler platforms on both sides. JSON has in many ways filled the niche
that XML was doing and RPC before it. But I had to spend so much time writing
glue code just so both sides could send/recv that data.

------
yahyaheee
> I think C++ can do anything Rust can do, and I would like it to be much
> simpler to use

You're going to need to break c++ then. It is so much harder to use than Rust
today, I have no idea why anyone would choose c++. The libraries argument is
mute because its such a pain to use external libraries.

