
C++ design goals in the context of Rust (2010) - krat0sprakhar
http://pcwalton.blogspot.com/2010/12/c-design-goals-in-context-of-rust.html
======
toolslive
I want to comment on one quote from the article: """It's impossible to be "as
fast as C" in all cases while remaining safe""".

C is not that fast. One of the major problems is that it's close to hardware.
1970s hardware that is. Ken Thompson reportedly once said: "I'm not going to
do nibbles. I have an 8 bit processor".

A good example of how bad it has become is that modern processors have a
rather good understanding of the 'string' concept, and offer instructions to
process them. C offers a char*.

Another problem is that C has strict contracts on how parameters are to be
passed through, and combined with separate compilation units, this hurts
compilers when they try to optimize things.

I see greater potential for a safe higher level language to be able to align
closer to modern day hardware than C. Some nice examples: Linear types can
avoid garbage altogether, and coroutines can be expressed clearly and
correctly using monads. On the other hand, raw performance is rarely needed,
and most cycles are burned interpreting things like python and php.

~~~
personZ
_A good example of how bad it has become is that modern processors have a
rather good understanding of the 'string' concept, and offer instructions to
process them. C offers a char._

The x86 string functionality that I'm aware of was directly derived from C
string functionality, and any decent library of course uses them. You don't
directly map to those underlying opcodes because that would be silly, and
would completely undermine any platform independence you might have.

The same for vectorization. You don't explicitly express vectorization in your
code, but of course all decent C compilers can easily and robustly generate
such code.

C isn't close to the hardware (beyond very high level notions like "contiguous
memory"). But it's a simple enough language that it's very heavily
optimizable.

~~~
ori_b
> _The x86 string functionality that I 'm aware of was directly derived from C
> string functionality, and any decent library of course uses them. _

The string instructions tend to be slower than using generic instructions,
especially in the presence of SSE.

------
actsasbuffoon
The post is interesting, but was written in 2010. As you'd expect, some of the
details have changed since then. For instance, garbage collected pointers have
been moved out of the core language into a library.

~~~
sanderjd
I didn't realize how old it was until I got to the bottom. It's cool how the
project has stayed true to the goals lined out way back then. While lots of
things have been changed and removed, as far as I can tell, none of those high
level goals has been compromised, while some have even been reinforced.

------
haberman
> The runtime features a separate C stack that's very quick (8 instructions)
> to switch to

I hadn't heard of this -- is it still true now that segmented stacks are gone?
If so, why does C need a separate stack?

~~~
pcwalton
This is out of date. Calling from Rust into C is now as fast as calling from C
into C.

------
Narishma
I was confused by the talk about keeping GC to a minimum until I noticed the
article is 4 years old.

------
a8da6b0c91d
I don't know much about Ada but it seems like Rust vs. Ada is perhaps the more
salient question than Rust vs. C++. Why was Ada not good enough in terms of a
very "safe" language?

~~~
pjmlp
Ada was good enough, but it suffers from a bad reputation.

On the early days it was deemed too complex to implement, although I would say
C++ became even more complex.

The companies that sold Ada compilers had customers with deep pockets, so Ada
compilers were too expensive and required worksations to be used properly.

When affordable Ada compilers became available, not many cared about it.

Nowadays it has found its place where human lifes are at risk. Many avionic
systems, train control systems, hospital devices are coded in Ada.

I do attend FOSDEM regularly and also get the feeling its use is increasing in
Europe thanks to the security exploits in languages tainted by C
compatibility.

------
spelunky
Coming from a modern language background like Swift it appalls me that I still
have to use semicolons in Rust.

~~~
coldtea
Swift came out less 2 weeks ago. As a beta announcement. So most certainly
nobody comes from a "modern language background like Swift".

Plus, it's not like semicolons are any big deal. If they are in a language,
you add them and move on. Dead simple to add, minimal noise, instantly
familiar to most C-derivative programmers. The only comminity that regularly
complaints about them are hipster (for lack of a better term) javascript
programmers.

~~~
userbinator
In fact I like semicolons because they give a clear delimiter to each
statement or expression leaving them out and relying on whitespace like
newlines is to me less readable since we're used to reading sentences with
punctuation and without that everything runs together and you have to mentally
separate them out while parsing not to mention it makes ambiguous cases like
in JavaScript possible

~~~
Dewie
I see what you're trying to do

But your post would still be decently readable if you just made a new
paragraph for each sentence ;)

