That depends on what you think of as being the core of C. Or, for example, some see Rust as the next C++, which is itself the next C, so is Rust _transitively_ the next C?

Programming languages never die, so I don't have a personal opinion on this point, exactly. For me, I would only write C code if I was working on a C project, or if I couldn't get a Rust compiler for the target platform. My starting point would be Rust, it would have to be disqualified for me to use C. Then again, I am the most biased person possible... (and also prefer C to C++) But regardless, C will never, ever die, so talk of Rust 'killing' or 'replacing' C is misguided, in my opinion.

I'd consider a language dead if there were no (or very little) new projects being done in it. For example you might say COBOL is alive because many financial institutions still run COBOL services, but you'd be hard pressed to find someone who would advocate to start a new standalone COBOL project.

(Queue person who started a COBOL project last week..)

In that sense, I think Rust has a real shot at at least severely wounding C++ or at least opening the door for the real C++ killer (it might be that Rust is a smidgen too strict in the mut ref department to really kill C++, I'm encountering a lot of push back from experienced C++ devs). We're talking about a 15 year timescale though, so that's at least 3 era's of computing.

> In that sense, I think Rust has a real shot at at least severely wounding C++ or at least opening the door for the real C++ killer (it might be that Rust is a smidgen too strict in the mut ref department to really kill C++, I'm encountering a lot of push back from experienced C++ devs).

Experienced X devs pushing back against Y doesn't mean that Y isn't going to displace X; the big factor in displacement isn't whether experienced devs will voluntarily shift (even if Y does displace X, the experienced X devs have the most vested interest, and will be among the last to voluntarily move to Y.)

  > I'm encountering a lot of push back from experienced C++ devs

Yeah, this bit is really interesting. It seems fairly split, though I'm not sure in what ratio. Some C++ devs are really into it, but others are very opposed. When you're used to total freedom, but then the compiler yells at you, there can be frustration...

We've also seen a _tremendous_ amount of interest from people who don't strongly identify as a 'systems programmer' at present. RustCamp was last weekend, and the audience is very broad. It's a classic "growing the pie" situation: Rust may or may not take away some of C++'s audience, but it very well just might make the pool of systems programmers significantly larger. We'll see!

> We've also seen a _tremendous_ amount of interest from people who don't strongly identify as a 'systems programmer' at present.

Can't underline this enough, as a long time WebDev with a lot of JavaScript, Python and Lua experience, Rust really feels like a door opener into the bare metal* world.

Especially as a Node Dev I felt right at home with Cargo. And as someone who only rarely touches C/C++, having the compiler scream at me for the first 10 days or so was probably the best "tutorial" about memory management and ownership I've ever "read" :) Rust really made me think a lot deeper about who / where and when stuff will be owned and eventually destroyed.

Overall, the language, cargo and everything around them fit so well together, learning it has been a real joy so far :)

* Well I've also done Z80 assembler on GameBoy before but that's probably not what people today would consider "bare metal" these days.

For me it's not really the freedom. I already said that elsewhere, but: I don't mind when the compiler yells at me. I just don't like the compiler to criticize my coding style by default. Initially, I liked Rust because it reminded me of C++. But then I began reading the book and basically it was full of statements about the coding style I prefer (and will keep) being bad. That's an incredibly stupid reason, but it kind of keeps me away from the language. But it's also the fact that C++ still is very widespread and has tons of libraries.

I wouldn't say never, of course. I'm looking forward to using Rust. Just not now.

Every language has different idioms. In many cases, what works in C++ doesn't work in Rust. Generally, anything the book says is bad you should take as qualified to mean bad in the context of Rust programming, not programming at large.

Sorry, I didn't make it clear enough. I was primarily referring to code formatting. Spaces instead of tabs, for example, or not writing opening curly braces on separate lines. These things are a matter of taste and should be friendly recommended at best. Guidelines for idioms are important and should occur as early as possible in the book, so that's perfectly fine.

I don't think telling you how to format your code for a particular language is a bad thing. I am quite happy using { on a new line in C# but on the same line in JS, using underscore_separated_method_names in C and camelCasedMethodNames in Java. To me, once you've been round the block with more than one or two languages you can get used to whatever style, but using the style for the language that you're writing in is something you should try to do for other people who read your code.

Reading Java code that uses undercore_separated_method_names or C# code that uses camedCased immediately makes me think the author doesn't know what s/he's doing.

I actually think that the scenario of Rust versus C++ is going to be quite interesting to see unravel, precisely because I don't think one is going to definitively weaken the other, but both be on their respective tails. This is because of the abnormally dramatic evolution C++ has seen over the past 5 years or so, and is hectically continuing.

Though this has pretty much definitively made C++ too large for any single person, and there are some fundamental semantics that ensure Rust will always have the high ground in some areas, the lines related to functionality are getting blurrier.

"Cue", not "queue". :)

"Programming languages never die"

There have been literally thousands of programming languages over the years ( https://en.wikipedia.org/wiki/List_of_programming_languages ) and I can't imagine that more than a handful (which most people itt can name) have survived from the 50s, 60s, and 70s.

This may be a bit like hair-splitting, but the language doesn't die, only the implementation does. As long as the language was specified in enough detail, a new compiler could be written for it, and be able to compile the old source code in the language. There is an interesting parallel to natural human languages here as well, a language like Latin is considered dead because no one speaks it as a primary language, but humanity still has the ability to translate and understand Latin texts. The same applies to say Egyptian Heiroglyphics as well. In any case it's interesting to think about.

Maybe I should say "Programming languages that were used at wide scale never die."

My "mojikun" brainfuck variant is certainly dead, but then again, it was never really 'alive' either.

Rust is suitable for a great deal of what C is used for (extending higher-level languages, writing language-agnostic libraries, embedded development, etc.) but Rust will likely never support as wide a variety of obscure platforms as C does. That said, Rust already supports Linux, OS X, Windows, and Android as first-class citizens, and support for FreeBSD, iOS, PSP, and lots of embedded and ARM platforms is currently provided by the community.

And C remains the linga franca of FFIs so that's there to stay.

I don't really see why a pile of different languages couldn't FFI through C-style interfaces without any of them actually being C, though.

PSP?

That's pretty cool! I haven't been in on the PSP "scene" in years. Nice to see things are still going on there.

PlayStation Portable, the predecessor to the PS Vita.

Yeah. Wasn't sure if that's what the abbreviation was for. I miss hacking and making PSP homebrew.

Spiritually it seems to be a replacement for C++. If you're using C++ for something, Rust seems like a well-thought-out C++.

If you're using C for something, then probably not, for the same reasons you are not using C++.

If you're using C and encountering memory safety problems, however, then you may want to consider Rust. Moving to C++ from C offers a small safety benefit and a large expressiveness benefit at the cost of a very large complexity drawback. Moving to Rust from C, on the other hand, offers a large safety benefit and a large expressiveness benefit at the cost of a significant complexity drawback. (I think Rust as a language is less complex than C++, and the complexity of C/C++ undefined behavior rules completely vanishes in safe Rust.)

Can you elaborate on what you mean by the "very large/significant complexity drawback"? From what I've seen (which is admittedly small) Rust is much less complex than either C or C++.

Compared to C, Rust has generics, closures, a module system, hygienic macros, real strings, slices, lifetimes, and the borrow checker. But note that all the features that Rust adds over C are, in my view, one of (a) necessary for memory safety (which is an important feature in 2015); (b) improvements on C features (macros compared to cpp, strings compared to char *, modules compared to #include); (c) things you expect from a modern language (generics, closures).

Rust is a larger language than C, though far smaller than C++. More importantly, with Rust you should expect to spend more of your time convincing the compiler that you've written correct code, which requires a reasonable understanding of Rust semantics. (The compiler makes that fairly easy, but it can still be a bit of a shock when you're staring at code that seems obviously correct to you but the compiler has no way to know that.)

On the other hand, once you do convince the compiler, you have an excellent chance that the code actually is correct, and you'll spend far less time chasing down crazy runtime bugs.

> On the other hand, once you do convince the compiler, you have an excellent chance that the code actually is correct, and you'll spend far less time chasing down crazy runtime bugs.

That's what I love about Haskell as well. Know of any other languages like this?

I used to feel more strongly that way about Haskell. I still do about most types of errors, but I spent a long time debugging serious performance issues caused by unbounded laziness and insufficient strictness.

In general, I'm a big fan of static typing. I don't know any other language that manages to provide as much static memory safety as Rust, though; that's the main innovation in Rust.

The difficulty of reasoning about strictness and memory consumption in Haskell is by far its biggest flaw. This is why I stopped writing Haskell: even if you understand your own code perfectly, you can't tell how well-behaved it will be without reading your dependencies and all their dependencies.

And yet strictness typing seems to be on nobody's plan for future Haskell extensions.

I'd say that Go is a better "better C" than Rust, for already functional C programmers. The syntax of Go is as removed from C as Rust's, and it's more mature.

TBH, Rust looks a bit stillborn - too weird to live, too rare to die.

People say this. I looked into Go, to write modules for VoIP platforms. Go is a managed runtime environment. I can't drop it in where I'm currently using C. I can't easily start migrating pieces of a program to Go. But Rust does execute exactly where C can.

In fact, I don't see how Go is C like at all. It seems much more akin to other managed languages, like Java. The only reason it seems to come up in these discussions is that Google said it was for "systems" programming, using a new value of "systems".

Maybe you're referring to mindsets and syntax or something?

I strongly disagree with this assessment. Go may be a better Java or Python, but as a GC'd language it's not in the same league as C or C++ or Rust.

I also happen to prefer Go's syntax to Rust's, but I can live with GC'd performance. If I were writing something as performance critical as a browser rendering engine, I could get past the weird syntax. I think both Go and Rust have bright futures.

This is also why it matters to know what you mean by C: to me, a key aspect of C is the manual memory management and lack of a runtime. A C that adds GC is no longer C.

Go is more mature than Rust, and to the extent that they have similar advantages (which I don't think is very much) Go's first-mover advantage may help it.

OTOH, Rust is maturing quite well, and I think it has broader applicability and a very different area that is its strongest point that is the case for Go, so I think that its quite likely to do well initially in places where Go isn't much of a competitor, and in the long run may well be more successful than Go. (Particularly, its focus seems to be aimed at lower-level system programming than Go's, but a the same time it has constructs that, once good low-level libraries are in place, seem to make it potentially quite good for higher-level programming as well.)

comparing go to c is like comparing python to c - those langauges are designed for different purposes. if you're happily delivering web services with go, stay with go, rust probably is not for you. if you OTOH don't want a GC or want to write a dll that you can then call via FFI from go/python/ruby, rust is the way to go, as is C or C++ (pretty much the only other choices available).

Go isn't designed for the same purposes as Python or Ruby, either. It's statically typed and far less expressive.

indeed there are critical differences regarding certain details like compilation to executables, compile-time time checking, etc. this doesn't mean the purpose can't be the same. it certainly is for many people (developing web sites).

Do you have specific reasons why Go is a better "better C" than Rust?

> too weird to live, too rare to die.

I disagree with "too weird to live" but at least it makes sense. What does "too rare to die" mean?

I'm using Rust as a C replacement (I need speed and ability to produce libraries with a C ABI). To me Rust is "C with templates". Rust isn't an OO language in the same style as C++ (instead of inheritance it has trait polymorphism, which is nice, but doesn't always map to C++ design patterns).

I don't use C++, because for every thing that can be written in C++ there's always a more complex/clever version that should have been written instead.