
Death to C, ++ - janober
https://techcrunch.com/2017/07/16/death-to-c
======
rhuber
Every aspiring programmer should learn C. They should also learn multiple
dialects of ASM. Learning these things helps you better understand how
computers fundamentally work, and knowing how computers work pushes you to
write better code in any language. Ignoring how computers organize data can
lead to inefficient code in any language.

That said, if you are writing something new, you should carefully consider
whether C is the best choice before using it. If you are working within a
nearly-impossible-to-replace + enormous codebase (such as the Linux kernel),
it is the only option. If your project's #1 goal is performance above all
else, and you are a seasoned or aspiring expert, perhaps C is the best choice.
The majority of people writing software do not fall into either of these
categories.

~~~
strictfp
I feel like the length of the list of things "every programmer should know" is
approaching infinity.

~~~
Koshkin
From my experience working with people, one can be an excellent programmer
knowing just one language, whether it is C#, Ruby, or Java. On the other hand,
I have met (too many) people who "knew" a lot but who were quite bad at
putting that knowledge into practice.

------
_callcc
As a younger programmer, speaking honestly, it seems to me a significant part
of the motivation behind Rust evangelism has to do with distinguishing
yourself against older colleagues who have 20+ years of C systems programming
experience. When you find yourself in a field that's supposed to be new and
fast-moving, yet you're stuck in a junior position waiting for the old guys to
retire, potentially for years, as if you're a journalist or academic or
something, it's not hard to see why people look to develop a different skill
set.

~~~
notacoward
I get the same impression, and not just from Rust. It's pretty common for most
new (or newly-popular old) languages. There will always be a certain
percentage of programmers who are less out to solve problems than to look or
feel better than other programmers around them. What better way to do that
than in a language nobody else at your company knows? Nobody to correct your
style, or your use of a deprecated idiom. More glory for writing a library
that didn't exist yet in that language than for improving one that already
did. You get to write the early blog posts and tutorials, maybe even a book,
secure yourself a permanent place at the conferences, etc. The Javascript
community (like the Ruby community before it) is full of people who came from
Java for those kinds of reasons. There's a similar migration path from C/C++
to Go and now Rust. A long time ago, you might have found emigres from
Pascal/Modula/Ada to C.

There are many reasons to move from an older language to a newer one. There
are good reasons, and there are bad reasons. I think language designers and
evangelists generally do a good job of focusing on the good reasons. It's
unfortunate when such advocacy tips over into FUD, but I suppose it's
inevitable too. Nobody likes to see their investment devalued because their
favorite vehicle to fame and glory lost out, even if the alternative really
was even better.

------
softinio
Bashing a successful language is not a way to get a new language adopted in my
opinion.

I think C is a great language. I also think Rust is great but I would not bash
one against the other.

This kind of evangelism is unproductive in my opinion.

------
elementalest
Whilst I agree it is hard to consistently write safe/secure code in C for
increasingly more complex code bases, and that C is no longer the best tool
for the job in these cases (there are better tools/languages out there), I
think the author unfairly lumps modern C++ (>C++11) in with C. Modern C++ has
many of the tools necessary to mitigate many of the problems C (and <C++11)
can encounter.

I do think Rust is a viable replacement for C, but not a replacement for
modern C++, rather an alternative - at least for the foreseeable future.

~~~
pcwalton
I actually think modern C++ is less safe than C, because of the ability of
destructors to be invoked invisibly and cause use-after-free, just to name one
major issue.

~~~
elementalest
Unless I'm mistaken, if you're using smart pointers, the memory wont be freed
until the destructor has executed its code. Use after free should only be an
issue if you're using raw pointers.

~~~
pcwalton
> Use after free should only be an issue if you're using raw pointers.

Which you are, because "this" is a raw pointer. The same applies to references
and iterators, which are used everywhere. It's not feasible to use C++ without
using those features.

Besides, you can get UAF without any references at all. Read/write races on a
vector, for example.

------
tbabb
I'd say that n-gate.com would have a field day making fun of the "Rust
Evangelism Strike Force", but this almost parodies itself.

------
faragon
TL;DR: yet another pro-Rust rant.

------
Yetanfou
C is as unsuitable for the current world ad an axe or a hammer or a knife is.
All of these are tools which, when wielded without care, are likely to cause a
fair bit of damage. Then again, all of them are the go-to tools for their
specific applications, in the case of C that would be systems programming one
level above assembly (C is "structured assembly" and should be treated as
such). Good luck using Rust (et al) to program that controller with a scant
few bytes of memory, or the firmware for that wifi-controller, or ...

------
dfgdghdf
The author does not seem to undestand how modern C++ differs from C. They are
completely different languages with completely different idomatic styles. The
only thing they share is some tooling.

------
aMayn
I'd like to thank Jon Evans for motivating me to write more C.

------
open-source-ux
Most of the modern web is built in C: Apache and NGINX. PHP, Python and Ruby;
Linux and the BSDs.

I see the attitude to C as analogous to PHP in the web programming sphere.
Everyone complains about PHP. And yet despite all the criticism to avoid PHP,
the overwhelming majority of server-side web apps are written in PHP. Not
Python or Ruby or Lua or some other language. Some estimates state PHP makes
up 80% of server-side web code.

Why haven't these other languages displaced PHP? Because none of them can
match PHPs simplicity and ease of deployment. Not Python or Ruby or Lua or any
other language.

And of what of C? It's a similar scenario. Where is the fast, strongly-typed,
low-memory programming language with a friendly readable syntax for low and
high-level programming? Does it exist? Is Rust that language?

~~~
Koshkin
> _Everyone complains about php_

There is a famous quote by B. Stroustrup about this phenomenon.

------
igotsideas
I've heard hype around rust. Any seasoned c and/or c++ programmers use Rust
now?

~~~
faragon
I find Rust an ugly and overengineered language. C++ is getting ugly, too, but
not that much. In my opinion, C is the simplest and the better for systems
programming.

~~~
zerr
You can't escape the ugliness of Rust. You can write simpler and more
efficient code in C++ compared to plain C.

~~~
Koshkin
So true. The only advantage of C compared to C++ is incomparably faster
compilation - primarily due to the "abuse" of header files by C++ libraries,
including STL.

~~~
dkrikun
What about clean syntax, simple straight forward language?

~~~
Koshkin
Sure, with a few caveats: 1) you can limit yourself to a reasonable subset of
C++ that is just as clean and straightforward; 2) _code written_ in C++ could
look much cleaner and straightforward than it is possible to achieve in C; 3)
many have argued that the C syntax is bad, especially compared to some other
languages.

------
jjuhl
Modern C++ avoids many/most of the problems of traditional C with the use of
smart pointers, standard containers and algorithms etc. If you write modern
C++ in 2017 you get the speed benefits without the problems (I'd claim).

~~~
idsout
It's way too easy to do something like this in c++:

    
    
        auto v = vector<int> { 1, 2, 3 };
        auto &e = v[0]; // plan to use element later
        // ...
        v.push_back(v.size());
        // ...
        cout << e << "\n"; // boom
    

As a real example of this: suppose you're managing a vector of connected
users. v is large enough to hold 64 user structs. e is a reference to the last
user who produced an event. If a 65th user connects then the vector will need
to be reallocated, thereby invalidating e.

Rust saves you here. The compiler will let you have a reference to the element
if the vector is marked as immutable. If the vector is marked as mutable the
compiler will yell at you and you'll need to store an index instead.

~~~
fooker
>if the vector is marked as immutable

So, mark it as const here and see the same effect?

~~~
Eridrus
Not really the same thing. const will stop you from mutating the vector, but
it won't stop you taking a reference to an element you get in a const vector.

So, if you have a const reference, you can't make this mistake in it's
entirety, but you can certainly make the mistake of keeping a reference to
something you got through a const pointer.

Also, marking as const is something you have to opt-in to, and there is still
disagreement on the value of const.

~~~
fooker
That is a library design issue. You can certainly design a vector that is
immutable by default and can only allow you to get references when immutable
and push_back when mutable.

That is the point of C++, things other languages do at a language level you
can easily design as a library without paying a cost if you do not use it.

~~~
Eridrus
This still doesn't solve the problem because there is nothing stopping you
from having both immutable & non-immutable references to the same data
structure. And does not enforce that there are no references hanging around
when you go from immutable to mutable.

Which is precisely what Rust does.

------
andrewfromx
this is great "Security tips when programming in C (2017 edition): 1) Stop
typing 2) Delete what you've already typed"

~~~
mirekrusin
What about things that are already compiled, like your os kernel? Delete those
as well? Postgres? rm -Rf? What about "rm" which is written in C as well. Pro
tip is to do `rm /bin/rm` as the last command?

I love the language but this kind of shallow patronising is ridiculous and it
doesn't serve Rust. It's not good for anybody. Rust can do (and does) better
without it.

~~~
awkwarddaturtle
Not only that, many languages ( their compilers/interpreters ) are written in
C...

------
dkrikun
1\. C is simple,elegant but not-so-productive, not-so-modern and, for sure,
very very unsafe. Oldskool hardcore, trust the programmer, quake language.

2\. Modern C++ is so zero-overhead template and otherwise compile-time
obsessed language. Yes it can be productive, somewhat safer than C, but the
language is so terribly complicated, that it really misses the point imo.

3\. Rust is modern low-level language with safety agenda and zero-overhead
abstractions. The type system is still hard to master. Guess this one fits
low-level system programming very well.

4\. We really need a low-level productive modern language with just a
'convenience' level of safety, but high degree of control over low level
performance: simd, alignment, atomics, cache levels etc.

~~~
cheez
Modern C++ gives you 4. Really. Read a tour of C++ and you'll see. The
language there is VERY simple.

~~~
dkrikun
I have been doing C++ for most of my professional life. There is nothing
simple about it. Also there is no standard way to use vector instructions or
cache control. Everything else is terribly complicated with templates and
rvalues/xvalues.

~~~
cheez
As have I, going on 17 years now. The vast majority of programmers do not need
this.

~~~
vardump
21 years of C++ here, give or take.

I haven't seen a C/C++ programmer who doesn't need that.

~~~
cheez
> there is no standard way to use vector instructions or cache control

Really?

Amazing.

------
rarz
I'm more concerned about old web frameworks and untrained engineers using them
to build insecure webapps and data storage than I am about potential consumer
level malware.

Over time many protections have been put in place to help mitigate against
native bugs like DEP, stack cookies and ASLR. While not full proof, they make
these attack vectors a lot more difficult and who knows, maybe we'll start
seeing fully position independent code for all system libraries making it even
more difficult.

I really need to check out Rust though and see what all the hype is about :)

------
baron816
“If a feature is sometimes dangerous, and there is a better option, then
always use the better option.” -- Douglas Crockford

This could probably apply to anything, including a language itself.

~~~
jclulow
There's in impedance mismatch in that assertion, though. Let's assume that the
label "dangerous" can be applied objectively to a feature. What does it mean
for another option to be "better"?

Better by what metric? The quote seems to suggest that the only metric is how
"dangerous" something is, but in the real world that's just one of many trade-
offs we must make. What about performance, instrumentation and debugging
features, complexity of implementation, etc.

One imagines room for quite a lot of nuance in interpreting this
recommendation.

------
Grom_PE
Sometimes I wonder how the computing world would turn out if Pascal has won
over C.

I spent a lot of time programming in Turbo Pascal, and C has always looked
like a major downgrade to me. No modules, insufficient type checking, and the
build system is a completely separate step with its own languages brought in
(arcane command line, makefiles, project files...).

------
kodablah
> Rust, which is, in fact, a viable C/C++ replacement

Wrong. For example I cannot easily use a C++ framework from Rust. As bindgen
and other bridge approaches get better, I have hope, but to say it is a viable
replacement right now is just false.

------
andreasgonewild
Still too much syntax. I don't mind security, but Rust defeats the purpose by
drowning code in an ocean of keywords and punctuation. I'm a firm believer in
encouraging rather than enforcing the right thing; languages are tools, not
religions. Writing correct C++ is perfectly possible, especially if you're
willing to put in a Rust-level of effort to get there.

~~~
pcwalton
> Writing correct C++ is perfectly possible

Unfortunately I know of literally no large-scale project worked on by a large
team using industry-standard practices (i.e. not NASA levels of verification,
which are economically unviable for most software) that has consistently
written correct C++.

~~~
fooker
>has consistently written correct C++.

You can easily find examples for correctness modulo errors Rust would have
prevented.

------
bsaul
off topic : what's the state of swift as a system programming language ? is
its automatic memory management cost too high for this usage ?

~~~
fulafel
Swift is fundamentally tied to the slow reference counting-based Objective-C
GC. That's a compromise that looks unappealing outside the iOS/Mac OS sphere.

------
jgh
Oh god... Like Rust isn't a major PITA to use...

~~~
khedoros1
C's a major PITA to use too, it's just less up-front about it. C++ is a little
more up-front, but also has its own minefields.

