
Death to C - ggonweb
http://techcrunch.com/2015/05/02/and-c-plus-plus-too/
======
christianbryant
I'm sorry, but as a user and hacker of UNIX, POSIX and all things GNU/Linux
since 1996 I have to say this is just fruitless and counter-productive.
Although, I will support the sentiment "Death to C++" :-)

The argument is over-simplified and rather than looking to the root of the
problem tries to sweep it under the rug by also ignoring the fact that many
new languages have their interpreters written in C. The root issue is that the
C language needs an update, an overhaul, and that once the standard has been
refreshed, C will continue to be the #1 language among programmers.

Sadly, nothing can be done for C++ and to lump C and C++ together is as
upsetting as calling for programmers to cease the use of C! :-)

Last thought: There needs to also be more focus on teaching programmers how to
write secure C programs. Every year new exploits are released that target
insecure C programming styles, and the C community should make sure
programmers are being educated on how to avoid these issues. Look to subsets
like MISRA C as an example and a move in the right direction; advocating
secure programming/language subsets rather than changing languages ultimately
makes more sense.

~~~
wiggumz
MISRA is a bloated mess from the accounts I've seen, no doubt to encourage
paying for it. If u remove all the filler and padding the substantial part may
be 40 rules.

There should be a new C that obviates the substantial parts of MISRA.

~~~
weland
In my experience, the major problem with standards like MISRA is that people
read the rules, but rarely the rationale behind them, which makes every coding
standard end up _encouraging_ cargo cult bug avoidance.

Case in point: MISRA C forbids goto statements primarily because it can mess
up static analysis. Yet this rule is gratuitously followed even when no static
analysis tools are used, thus yielding none of the gains that you trade off
for occasionally writing ugly code.

~~~
christianbryant
The intent with standards like MISRA C is actually to be a reference point
against which certifiable audits can cite companies for infractions. That is,
the standard is no good as you note, unless a desired industry certification
is only attainable for a company if an audit demonstrates the programmers are
indeed following the rules.

Otherwise, you're right. The value goes out the window without enforcement,
without compliance.

~~~
weland
Absolutely. If you're audited for MISRA compliance, you need to follow it
point by point.

The rules themselves are not meaningless or without a point, but there are a
lot of companies that adopt MISRA without actually _having_ (in the sense of
audit and certification) to be compliant. Instead of focusing on _the point_
of every provision, they rigidly follow them even when not applicable.

But it can be worse, really. The gem of a coding standard we have at $work
forbids not only goto, but also break, without MISRA's exception of one break
per loop. And forbidding the use of goto and continue is cited as being done
for readability reasons, rather than static analysis tools.

------
gnuvince
You're not going to convince C programmers simply by beseeching them. The
article is missing an entire component: the argument for Rust. There needed to
be examples of C programs that one may write that are actually unsafe and of
how Rust addresses that. There needed to be a discussion on the performance of
Rust, and of its ability to call into C without overhead (or to be called by C
without overhead). Everyone already knows what the problems of C are, what
they need to know is what the alternatives offer and how in the end you are
not giving up too much.

~~~
ci5er
I really like the promise of Rust. I mostly like its design.

But, for myself, I notice this: Writing Rust programs (vs. writing C programs)
correctly is _hard_!

N.B. This might be an old dog new tricks thing.

I automatically structure my programs (be they rendering engines, or
computation/numerical simulations or even agent-based simulations) where
allocating and freeing memory from/to pools just isn't that hard. I don't
really think about it. I just throw together my code, compile it and run it.

Of course, I make many (many!) silly/stupid mistakes during the course of
development, but failing to free a pointer is rarely one of them.

Now I loop back to your point. (Sorry I took the long way)

> Everyone already knows what the problems of C are, what they need to know is
> what the alternatives offer and how in the end you are not giving up too
> much.

I know what the problems of C are. I am aware of the alternatives. But the
problems of C don't seem to be overwhelming enough to bother throwing away and
constructing an entirely new tool-chain and support system on whatever your
platform is.

That was a pretty bold statement, and I would invite a response.

I would like to think that we, as an industry, are not just implementing new
language ecosystems because we can't be bothered to free our pointers...

~~~
dbaupp
_> Writing Rust programs (vs. writing C programs) correctly is hard!_

To be clear: getting Rust programs past the compiler is much harder that C
programs: C doesn't incorporate much type-system/static checking so a lot more
gets past the compilers. But writing truly _correct_ C programs (i.e. don't
crash horribly) is a harder task, as there's no computer assistance for
avoiding large classes of possible bugs.

 _> failing to free a pointer is rarely one of them_

 _> we can't be bothered to free our pointers_

Solving this "problem" is not the goal of Rust. Rust aims to avoid undefined
behaviour by default, e.g. derefencing invalid pointers, use-after-free,
iterator invalidation are statically ensured to never happen, unless you opt-
in at specific locations via `unsafe`. Cleaning up memory automatically is a
nice feature, but the main draw card and the reason Rust might actually be
interesting is that Rust offers memory safety without garbage collection.

In any case, I think you're being overly glib about the problems of C: it's so
so easy to have a program that exhibits undefined behaviour, and so is
theoretically operating with no restrictions.

~~~
ci5er
> In any case, I think you're being overly glib about the problems of C:

In short form, here, without a doubt.

> it's so so easy to have a program that exhibits undefined behaviour, and so
> is theoretically operating with no restrictions.

I've run into this. A lot! It was almost always my fault. One notable
exception was back when I used to do a fair amount of with GP (Genetic
Programming -- evolving large populations of small programs). The system was
shockingly adept at finding/exploiting edge-cases and exploiting them for
advantage.

------
gregjor
Well, there's Go.

Java was supposed to fix all of these problems, but it's a mess in its own
way. There's no perfect language.

Almost simultaneously with C the Pascal language was introduced, completely
safe and easier to learn. It enjoyed a period of popularity, and for a while
it was widely taught in high schools and universities. Some big systems were
built in Pascal, but every big Pascal app I've ever seen relied on external
code in C (or assembly language) because Pascal is hobbled to enforce safety
(see Brian Kernighan's article "Why Pascal Is Not My Favorite Programming
Language, [http://www.lysator.liu.se/c/bwk-on-
pascal.html](http://www.lysator.liu.se/c/bwk-on-pascal.html)). Some of
Pascal's faults were fixed in Modula and Oberon but those never got any
traction.

To be absolutely safe the language is either crippled so it's missing
important features, or it requires a runtime to sandbox everything, check
pointer references, do garbage collection, etc. And that slows things down.

I don't see C going away any time soon in embedded software, which is where
bugs and vulnerabilities can be most dangerous and where they are hardest to
fix. It's not much of a disaster for a video game to crash, but it can be very
bad if piece of hospital hardware or a flight control system has a latent bug.

There are tools that can analyze C code both statically and dynamically -- the
language is not just old, it's mature.

I'm sure someone is already rewriting the Linux kernel and all of the Unix-y
tools in Rust or Go or whatever. I won't hold my breath.

~~~
coldtea
> _Well, there 's Go._

Not for the things C is good for. OS work, drivers, common libs like OpenSSL
callable from other apps, infrastructure work, etc.

Besides Go is nothing new. There have been similar languages ever since 1970,
and they are not replacing C.

~~~
__Joker
Agree, better shout out would be Rust. Also referring the complete
interview[1] which the TC article quotes, which seems to be favouring Rust.

[1]. [https://www.codementor.io/rust/tutorial/steve-klabnik-
rust-v...](https://www.codementor.io/rust/tutorial/steve-klabnik-rust-vs-c-go-
ocaml-erlang)

~~~
steveklabnik
Two things: First, I'm on the core team, so I obviously have bias. I try to
remain as objective as possible at these things, but still. Second, that
interview was from October. Not a lot has changed, really, but it is an
eternity in Rust-time.

~~~
akulbe
Question for you, sir. When folks like you and the rest of the team set about
making a new programming language, is it ever with the new programmer in mind?
Or is your primary purpose to fix a shortcoming in another language, and as
such, you're not really thinking of the beginners?

The reason I ask is because I went to look at the docs for Rust, and they
still seem incomplete.

As someone on the outside looking in... I'd have a hard time recommending Rust
over C, because the learning path isn't complete yet. C is extremely well-
documented. I want to learn Rust, because it's the new hotness, but it seems
difficult to do _right now_.

That said, I'm very curious to hear your thoughts on this.

Also, if you have advice on how best to learn Rust, I'd love to hear what you
have to say on that. My professional experience has been almost entirely with
scripting languages, and nothing more low-level than that.

~~~
steveklabnik
> is it ever with the new programmer in mind?

New programming languages are almost never designed with the new programmer in
mind. I've spent a _lot_ of time teaching people to program, and they all have
really serious hurdles. There are some good projects in this space, but
they're a very, very tiny minority. Don't underestimate how hard "Hello world"
is, which is actually something that that PDF I linked points out.

> they still seem incomplete.

Can you elaborate on this, with specifics? It'd be really helpful.

~~~
akulbe
I created a video with ScreenFlow.

[https://www.dropbox.com/s/vuax1ocki846llu/rust_example.mp4?d...](https://www.dropbox.com/s/vuax1ocki846llu/rust_example.mp4?dl=0)

Downloading and installing Rust, no problem. Then I tried doing the "Hello,
World!" example. Pretty sure I had it typed right in vim. It didn't work.

Then, I typed it in Sublime Text, it still didn't work. Then I thought, I
forgot to set +x on the file, and I remember I hadn't set anything on the
shebang line in the file, so I went on in the docs.

As you can see... I got to the "Learn Rust" page, and it wasn't ready yet.

~~~
steveklabnik
Thanks for making this! It was _very_ instructive.

First of all, I submitted a patch to remove that link to the old intro this
morning, so that should go away.

Second, the issue was that you compiled the program, which worked just fine,
but you never ran it! on [http://doc.rust-lang.org/nightly/book/hello-
world.html](http://doc.rust-lang.org/nightly/book/hello-world.html) , the
example shows:

    
    
        $ rustc main.rs
        $ ./main # or main.exe on Windows
        Hello, world!
    

You did the rustc, but not the ./!

As for "Learn Rust", that's one of two paths through the documentation, as the
first page of the book mentions. I've been focused on the "Syntax and
Semantics" section, which is the other path. "Learn Rust" is coming over the
next two weeks.

~~~
akulbe
Now I see that there was an "hw" file, now. I ran it and got the desired
results. Should have paid better attention.

Hopefully, the instruction was more than, "Wow, this guy is a bonehead." :D

I think some mindset changes are needed here, in that I'm used to dealing with
interpreted languages, rather than compiled ones.

~~~
steveklabnik
It's all good! Seriously, I've taught tons of people to program, and the
beginning is the hardest part.

Yeah, the two-step process is different. In the next setup section, when Cargo
is introduced, you end up with a 'cargo run' command that does the build and
runs your code in one step.

------
kazinator
Rather than "death to C" a better viewpoint is: minimize our use of C _and
anything that looks like it_. We don't need a better C, in which to write
mega-projects.

There is a parallel here in assembly language. Once upon a time, programmers
extended the viability of assembly language by building smarter assemblers
with powerful macros and such. None of that is necessary if you minimize your
use of assembly language, so that all you have in your system that is in
assembly language is a few atomic instructions, some context saving/restoring
code, interrupt dispatch, and a speedy memcpy and whatnot.

Going from C to Rust (or Go, or C++ or whatever) is kind of like trying to use
a deluxe assembler to write large assembly language programs with better
reliability.

If I'm going to leave C behind for some task, it's because I want to get away
from _that sort of_ semantics---any version of that semantics.

------
falcolas
I personally don't see Rust as a good replacement for C - it's too complex a
language, and it is especially easy to loose sight of what is happening at a
low level due to all of the abstractions.

Even if you did decide to use Rust instead of C in C's typical domain -
operating systems, drivers, and constrained resource devices - you would be
forced into using "unsafe" blocks anytime you had to interact directly with
the hardware, manually manage memory, or issue ASM commands; at which point
you're as vulnerable to programming mistakes as C.

~~~
neikos
Not necessarily as the idea is to isolate those components into the unsafe
blocks, and having locality on a bug is a pretty big component of fixing it.

~~~
hga
Well, that's locality on what in theory could be causing a bug, but not on
where it might manifest, i.e. a wild pointer trashing data maintained by
purely safe code.

Still, in theory isolating the possible causes is a fantastic advantage.

------
denim_chicken
The C ecosystem has tools designed to compensate for its issues. There's
valgrind, static analysis, debuggers, asan, tsan, etc.. With its immense
popularity, its flexibility and portability, and its mature, comprehensive
ecosystem behind it, there's no all-purpose programming language better than C
(expect maybe C++).

------
Animats
Rust people, please don't screw up. We desperately need a replacement for C.
Rust could be it. But it's not too late for the Rust crowd to blow it. Rust
may have too much cruft at version 1.0 for C programmers.

Things that worry me about Rust:

* Too much mandatory metaprogramming. Basic things such as I/O require generics, and even lambdas. Rust's cruft level in this area picks up where C++ with Boost left off.

* Error handling is too verbose. Wrapping things in "Result<>" and "Some<>", then unwrapping them with "match" is wordy. Wrapping that in generics makes it shorter but hides what's happening.

* The type system and type inference are very complex, and type errors induced from another module can be hard to diagnose.

* Too much language churn. Supposedly "stable" modules still keep changing. I'm surprised when I recompile a program after a few weeks and it still works. This needs to settle down very soon.

* Resource Allocation is Initialization. Initialization isn't that bad, but what do you do about an error discovered in a destructor? Destructors are always troublesome, and Rust doesn't seem to have that area under control. A "with" clause approach would have been cleaner. The recent discovery of a soundness problem in Rust destructors is being handled in a way that bears watching. First, the actual issue reporting the problem was closed without a fix.[1] The discussion was "moved to an RFC" so as not to block the release of Rust 1.0.[2] Related issues are now being discussed to death. A good discussion of the issue is at [3].

While Rust avoids complex run-time abstractions, it has very complex compile-
time abstractions. Rust has all the cool abstraction ideas - closures,
generics, templates, type inference, RAII, functional programming, etc. This
may be too much for the C crowd. The basic libraries use all these features,
so you can't restrict their use on a project.

[1] [https://github.com/rust-lang/rust/issues/24456](https://github.com/rust-
lang/rust/issues/24456) [2] [https://github.com/rust-
lang/rfcs/pull/1066](https://github.com/rust-lang/rfcs/pull/1066) [3]
[http://smallcultfollowing.com/babysteps/blog/2015/04/29/on-r...](http://smallcultfollowing.com/babysteps/blog/2015/04/29/on-
reference-counting-and-leaks/)

~~~
barosl
I understand your anxiety on the complexity of Rust. I wonder if there were a
language that fixes exactly the pitfalls of C (e.g. sane string manipulation),
without adding any high level concepts, but with memory safety.

However, at the same time I think the language researchers cannot help but add
abstractions on today's languages. The unusual exception was Go, but it failed
to target the same niche as C/C++ at the end. Actually I think there are more
people who like abstractions than those who like the extreme simplicity of C.
So unfortunately, a "direct" replacement of C will not happen in the
foreseeable future, I think.

~~~
Animats
It's not bad that the language has those features. It's that their use is so
deeply embedded in the libraries that all Rust users must understand them to
do anything. It's a big jump in abstraction for C programmers.

~~~
barosl
Indeed! That's why I'm still not used to Haskell. While I can do simple things
with the language, the abstractions made by the popular libraries written in
Haskell require me to understand a certain concept to use them properly.

However, while the feature complexity can be avoided at least in the standard
libraries, I think that's a more general (possibly cultural) problem,
considering a Rust developer will have to use any libraries other than the
standard libraries at the end.

I believe that's why the Go designers are so wary of adding new features to
the language. If there's a feature, library writers _will_ use that feature.
Nothing can prevent this.

------
xorcist
Yeah. "Stop using PostgreSQL and Redis. And Linux." Then these people usually
go on to describe a completely different problem domain, it used to be
something-lisp and now it's ruby-whatever.

Problem is, sooner or later you need to be using the operating system for
something more than just starting processes, be it controlling file handles or
sandbox code or whatever. Then you need API compatibility and control over
your mallocs. Which isn't impossible in non-systems PLs, but it isn't exactly
a walk in the park either, as you're basically left calling wrappers for
syscalls instead of doing it directly, which means you have master both your
runtime _and_ your C-based operating system.

At least this time they have an answer that's at least worth listening to. The
newest crop of languages with Rust and Go actually make an effort towards
system programming. That excites me! Now all you have to do is make something
as secure and robust as Redis or Postfix, and let's see how it fares in
production. And if Servo grows to be a fully grown competitive web browser,
applying binary deltas to itself, sandboxing GL code, and everything in
between, that would be a great litmus test for Rust to actually compete with
C++.

~~~
Ygg2

       >  And if Servo grows to be a fully grown competitive web browser
    

From what I hear Servo is a research project. There exists a great chance it
will never become a fully grown web browser.

It already started sandboxing some code, but I'm not sure what binary deltas
have to do with massively parallel web brwoser.

------
lambdaelite
So for a mission critical or safety critical system, what's the alternative?
It looks like the options are:

    
    
        1, assembler
        2, C + validated compiler + static verification + coding standard (MISRA-C maybe)
        3, C++ + validated compiler + static verification + coding standard (MISRA-C++ maybe)
        4, Java + specialized VM with RTSJ + static verification + coding standard (RTSJ)
        5, Ada/SPARK + ???
    

So really, C/C++/Java/Ada aren't being used alone, it's the language +
validated compiler + verification tools + a coding standard that are being
used.

How are Haskell, Rust, Go, and whatever other nouveau language of interest to
the HN crowd tenable options for serious work when they lack the ecosystem of
a formal standard, validated compilers and verification tools, track record,
etc.?

------
wyldfire
I'll confess, I have looked ever-so-briefly at D and Go and I figured that
Rust was probably similar to Go but I just didn't take the time to learn about
it. I like the idea of D (especially design-by-contract), but I have
difficulty convincing my colleagues (and myself) that a product with a garbage
collector can perform consistently well enough.

Then I read this in TFA:

> Despite guaranteeing memory safety, Rust does not have a garbage collector
> or runtime, and one of the benefits of this is that Rust code can be called
> from C with no setup at all.

Maybe I should think about it as "you always enable ASan in your production
binary"? That suits me just fine, if that's one of its major benefits. I will
resolve today to follow up on Rust and try to learn more about it.

~~~
steveklabnik
Most of Rust's safety guarantees are at compile time, not at runtime, and so
have no runtime overhead. ASan's docs claim a 2x slowdown.

That said, defense in depth is always nice. kmc got AFL working with Rust
recently, and it's uncovered some things. Using an ASan-like tool to do some
of the runtime stuff would be great to have.

~~~
wyldfire
> uncovered some things

Those were problems with the rust compiler or the binaries it generates?

~~~
steveklabnik
Three things so far. Two in the parser, one in generated code:

\- [https://github.com/rust-lang/rust/issues/24276](https://github.com/rust-
lang/rust/issues/24276)

\- [https://github.com/rust-lang/rust/issues/24275](https://github.com/rust-
lang/rust/issues/24275)

\- [https://github.com/rust-lang/rust/issues/21889](https://github.com/rust-
lang/rust/issues/21889)

------
hamiltonkibbe
The whole fallacy with articles like this is that they all too often show why
a language is unsuited for some subset of tasks and then proclaim "death to
$LANGUAGE." There's a time and place for C, and while writing a web framework
is probably not that place, I think for embedded C is going to be around for a
while.

Sometimes you need to do things that could potentially cause problems (like
every single pointer dereference) because there are deadlines for things to
happen. If DMA had to check whether the place it's about to write the next 4
sample from the ADC is ok every single time, you might very well miss it

------
damian2000
I'm sure C will be still going for a while yet in embedded development ...
microcontrollers, etc. There's usually no other option except assembler.

~~~
steveklabnik
While this is true for many embedded platforms, if it's an architecture that
LLVM knows about, you can use Rust on it. That said, many have just a
proprietary C compiler, or something similar for a barrier to entry, it's
true.

------
sudioStudio64
Hardware level approaches to making C more secure are in the works at Intel.
Hardware assisted bounds checking and the
like...[http://en.wikipedia.org/wiki/Intel_MPX](http://en.wikipedia.org/wiki/Intel_MPX)

The main thing that will finally convince people that a high-level of
abstraction is OK for OS level programming is for someone to get off their a$$
and build one. (That's actually usable. It would have to be SO usable that
people could quickly build out the new user code to make something like *nix
or windows seem like more of a hassle in contrast. That's such an insanely
tall order...not sure how you get there.)

I think that the best you'll ever be able to do is to build systems with
frameworks that are safe(r). People won't give up C because it makes them feel
smarter. The pile of code for C based systems will be with us forever. A new
system would have to be able to do all that AND be safe.

~~~
wiggumz
You're missing a key point. What makes Linux usable is that it has numerous
drivers written for it... written in C. An OS's core is not supremely
difficult to write. But the drivers are... Much specialized knowledge is
required.

------
weland
My list of "things I hate about C" is about 4 pages long now, after many years
in embedded development (and a few in scientific computing prior to that). As
soon as a viable replacement for it comes, I'm going to get drunk, ritually
burn K&R's "The C Programming Language" then get drunk again. But I've been
waiting for that day for a long, long, long time, and there's still no sign of
it, not even with Rust ( _maybe_ with Go but we'll have to see).

I cannot think of a single systems programming language that has not vowed to
put an end to all this buffer overflow and dangling pointers mess. The ones I
tried so far (I think there's a dozen...) failed because of at least of one of
the following items:

* Some of them mainly achieve safety by forbidding any unsafe read or write -- and then when you _have_ to do a read or a write, they implement that by cleverly eschewing a protection mechanism or by isolating everything in an unsafe area. The former is disastrous because you can have bugs that eschew the protection mechanisms, too (see Heartbleed -- which can be _perfectly_ replicated in Rust or Go); the latter, while useful in most application software, is next to useless in my day to day activity, where I have entire _modules_ that consist of nothing other than unsafe reads or writes. At that point I might as well be using C.

* Others mainly achieve safety through a complicated system of annotations ("this parameter must not be NULL") or a type system that makes certain guarantees ("these parameter can never be NULL"). The end result is a system of annotations and/or types which you can describe in about as much space as The C Programming Languages takes to describe the whole language. Barring the fact that my memory is limited after ingesting C++, real life experience shows that "more complexity" is how bugs get introduced, rather than resolved. Except that the new problems don't arise because a pointer is pointing where it shouldn't, but rather because 1 == 1 returns False for certain types of 1 or something.

* Aaand some of them simply delude themselves through clever sandboxing and protected writes, ignoring the fact that the sandboxing back-end is C all the way and can be exploited. Except it's so mind-boggingly complex that fixing it is incredibly complicated.

Historically, there have been many instances of _operating systems_ written in
high-level (ish) languages. Hell, there are operating systems written in
Common Lisp. It can be done. People haven't flocked towards high-level
languages despite 30 bloody years, if not more, of operating systems written
in high-level languages because it turns out you usually can't do it unless
you turn most of those fancy protection features off. At which point you end
up with C, only with a more complicated syntax, and why the hell bother?

The key to writing secure software that doesn't crash _is still_ in correct
programming. Tooling can help, but no language, no matter how fancy and hand-
holding, is going to compensate for that.

------
marvel_boy
Newbie here. Can anyone share their experiences with Rust?

~~~
cornstalks
I mainly program in C and C++, but have recently started a side project in
Rust. So these are thoughts from a Rust newbie (which I still think can be
valuable):

Pros:

\- Pattern matching is beautiful, and is one of the things I miss most when
not working in Racket.

\- I love their static typing. I think they hit a sweet spot with type
inference inside of functions but required types to be specified as parameters
(too much inference can make it hard to know exactly what type something is,
too little inference means I spend all my time writing type signatures).

\- Borrowing and lifetimes are neat and have helped me avoid some lifetime-
related bugs.

\- Being able to call Rust code from C is a huge win, and I think this world
needs more "systems-level" languages than C and C++.

Cons:

\- Borrowing and lifetimes. This is actually is a huge pro, but sometimes the
compiler can spot a lifetime issue that I don't understand (which makes fixing
it hard). I'll get better with this with time, but associating lifetimes with
object types is a bit confusing and hard to do if you want to do anything
nontrivial. Again, I'm sure this is mostly because I'm a newbie, but it's also
reality.

\- Verbosity. Rust is actually concise for the most part, but if you want to
pass a &str to a function, but have a String, (which, FYI, is fairly common in
my experience, as most string-related functions take a &str), you've got to
either call as_str() (which is unstable) or dereference-reference (i.e. &*)
the String. There are a few simple things that require you to be more verbose
than some other languages do.

Overall I like Rust. I think it's worth experimenting with, but I wouldn't
start a really serious project with it right now (because it's so young and
volatile). If someone wants to use it for a really serious project, I'd
suggest checking out Rust in another year or two when it's a little more
mature.

~~~
steveklabnik
Glad you're having a good time with Rust. :) One small note:

> if you want to pass a &str to a function, but have a String

You can just add a & to your String. &String coerces to &str. Deref coercions
are one of the few places where Rust does an implicit coercion:
[http://doc.rust-lang.org/nightly/book/deref-coercions.html](http://doc.rust-
lang.org/nightly/book/deref-coercions.html)

~~~
cornstalks
Ah, cool, that's much better! Is that relatively new? I swear you had to do &*
if you had a String and & __if you had a &String.

Edit: Ah, here: [https://github.com/rust-
lang/rfcs/blob/master/text/0241-dere...](https://github.com/rust-
lang/rfcs/blob/master/text/0241-deref-conversions.md#benefits-of-the-design)

~~~
steveklabnik
It's not only new, but there wasn't any user-facing documentation until a few
weeks ago. I'd been waiting to make changes to the book until after beta, and
the re-organization of the TOC I did made me realize that I was missing a few
things, this and UFCS being the primary two.

------
a-saleh
Can anybody point me to a good 'modern c programming' book?

I liked the approach of Learn C the Hard Way, (i.e. lesson 1: "Now compile the
hello.c with -Wall", lesson 2: "Lets learn to write simple makefiles",...,
lesson 4: "Lets use Valgrind", ...)

But the latest revision of the last chapter that I remember had quite a good
critique of K&R's C writing style, now contains just a rant on internet trolls
(?).
[http://c.learncodethehardway.org/book/krcritique.html](http://c.learncodethehardway.org/book/krcritique.html)

------
dibanez
In order for a language to replace C, it _has_ to do two things: 1) be able to
write an OS kernel competitive with Linux in this language. 2) get its
compiler(s) ported to new architectures, including the Top500 supercomputers,
where I work. Note that these two help each other: you make a new
architecture, you either code a custom OS in C or port Linux, both of which
start with a port of a C compiler. If your language can't do the OS thing, C
will remain out of necessity, and be too tempting and stable an alternative.

~~~
wiggumz
Someone to come up with a list of 10 reforms for C, nail it to Kernighan's or
Ritchie's front door, and start a new language sect.

------
cpncrunch
I think the article points out the real problem: overly complex code. If you
make the effort to write sensible, simple, easy to understand code, it's
definitely possible to review every line of code to ensure there are no memory
management bugs.

------
dom96
There is no way that any language can truly replace C at this point, C will
still be around for the foreseeable future. We should learn to coexist with it
not replace it.

~~~
steveklabnik
This is generally the position of the Rust team as well. It's also why the
zero-overhead interop is important to us.

------
leonatan
And here's hoping for the death of sensationalist articles with zero
substance.

~~~
coldtea
Or sensationalist comments with zero substance.

Perhaps there should be this unwritten rule, that if a post has made it to the
front page of HN, it means enough HN users voted it, and it's interesting to
them, so it's counter-productive to dismiss it as uninteresting...

~~~
leonatan
An article can be up voted for many reasons, including mockery. I was not
dismissing the post here, but the article itself. Also, it is already off of
the front page.

------
mtunjic
Safe programming is bogus programming.

------
michaelochurch
Terrible title. A more useful dialogue would be along the lines of "Death to C
where it is inappropriate", but C isn't used much these days where it's the
wrong tool for the job. Mostly, C is used for the things that C does very
well. Maybe we'd agree on "Death to C++ where it's inappropriate", because C++
is much more often used (than C) where it isn't appropriate. Then we have to
go down the rabbit hole of _why_ C++ often sucks, and we realize that it's not
even that it's a bad language itself (not that it's great, but it doesn't have
to be horrible) so much as object-oriented programming (OOP) has been
bastardized by business, and misused by reactively-writing programmers under
tight deadlines, to create obfuscation. Then we realize that this problem is
even more severe in Java codebases. Then we wonder if a new language can
really fix a problem (code quality) that is partially sociological and
political...

The counterexample to the "C is unsafe" argument is that C is what people use
for extremely high-reliability programming. I prefer Haskell, and Rust is
promising, but the fact is that JPL uses C. The Mars Rover is probably running
C code. While C is insecure as hell under typical corporate use (tight
deadlines, unskilled programmers) it can be pretty damn reliable in the right
hands.

~~~
kyllo
Do you think that avionics software is an appropriate application of C?

Boeing does...

[http://www.engadget.com/2015/05/01/boeing-787-dreamliner-
sof...](http://www.engadget.com/2015/05/01/boeing-787-dreamliner-software-
bug/)

------
wiggumz
Jon Evans, master complainer. C could be improved, but the amount of important
C code out there (Linux...) militates against adopting a new C. Is someone
going to pay to switch over the code base?

Ultimately if a newer, tighter, safer C is going to arise it must come fron
the GCC or LLVM people.

Go: owned by google so it's a no-go.

~~~
Intermernet
> Go: owned by google so it's a no-go.

It's actually an open source project, and many of the core contributors don't
work for Google. Just thought I'd point this out as it seems to be a common
misconception.

~~~
wiggumz
And are people expected to download the compiler executable from Google's
website?

Given that the CIA recently bragged that they were able to put spyware in iOS
apps because they have somehow exploited Xcode on developers' machines, one
has to think about the implications of downloading executables from companies
that are complicit in spying.

Just because I do something safe e.g. I compiled the compiler myself, it is
the larger implication of everyone else not doing it right that is the
concern.

~~~
Intermernet
Or you could compile it yourself from the github repo.

