Will there indeed be a replacement for C

[WarFox]

Just wanted to gather the opinions with others and also put out some of my thought. It seems like the big contenders in this field are Rust, Zig and D. I think also Nim is targeting the system space programming of C along with V lang.

Of all of the languages, I personally like the syntax of D and the meta programming concepts. Pretty much looks like what C++ should have been. I also like how memory safety in the compiler is not default and instead has to be specified when to use it and when to not. Might help cut down on compile times. A function that does a simple calculation like maybe calculating an interest rate might only be using stack variables and nothing allocated on the heap, so it doesn't really need the memory safety features wasting time on it, but adding a node to a list might.

I have dabbled some in Rust. Honestly, I don't like it. The syntax just seems a little overly complicated and I feel like a lot of words in the ecosystem are not in fact new concepts, but instead renaming concepts already present in computer science. One thing I do like about rust, the compiler is verbose which always helps with troubleshooting/debugging. I do also like that is catches when branches of execution are not being handled such as exception handling.

Zig has gotten some buzz in the BSD community but I see little else mentioned about it elsewhere. However, it is not at a 1.0 release yet, so that could be a reason why.

 

Overall, I don't think these languages will fully replace C. It is just so easy to port and get stuff bootstrapped. Not to mention the time and resources needed to re-implement something like the Linux kernel in 100% Rust or another language would take forever. I see the C language being timeless and always having a use case. Maybe it will lessen some with the like of Rust, D and Zig starting to come up, but we probably won't have a day in my lifetime where C code isn't at play somewhere.

Edited August 21, 2021 by WarFox
Added last paragraph

[cwade12c]

@WarFox I don't think that C will ever completely be replaced. At least in certain areas, like embedded programming where there are so many libraries written in C. In other areas, though, C might not be "king of the hill." I honestly haven't looked into some of the replacement languages like Rust, but was interested in playing around with it after reading about Wasm.

C will always be here. I think it will be interesting to see in what areas its replacements become more popular, though!

Edited September 1, 2021 by cwade12c

[veteran.respecter.360]

I agree that C isn't going anywhere. COBOL is still around, and I think that at this point C is more entrenched than COBOL ever was. Not everything is going to be rewritten.

 

I can understand the aversion to Rust's verbose-looking syntax, but I think that the sacrifices in convenience are made worthwhile by the compile-time safety guarantees and expressiveness that Rust provides. On the syntactical level, C is simple, but the runtime behavior is difficult to reason about. This is evidenced by the countless security vulnerabilities that arise from common, but easy to make, memory management mistakes. The Rust compiler is able to eliminate these bugs at compile time, in part due to syntactical constructs relating to things such as variable mutability. Rust's type system is also stronger and more expressive than C's, which might make it more difficult to learn initially, but in my opinion it's very nice to have features like generics, instead of needing to rely on things like void pointers. Of course, it takes longer for Rust code to compile than C code, but in most cases I am fine with compile time for more compile-time safety and better ergonomics provided by the type system.

 

To get back to the original topic though, I think it would be ideal for C to eventually get replaced with a more modern alternative that fixes some of C's pitfalls, but I don't think it's going to happen anytime in the near future. The cost of rewriting things can be excessive in many cases (like Linux for example), and there might be no practical benefit in rewriting a finished C program that has been already formally verified (thinking of aerospace software when writing this). Also, there are platforms where only C compilers (or outdated C++ compilers) currently exist, and making a compiler for one of these replacement languages target such platforms could very well be too costly to be worth it.

[cwade12c]

13 minutes ago, veteran.respecter.360 said:

I can understand the aversion to Rust's verbose-looking syntax, but I think that the sacrifices in convenience are made worthwhile by the compile-time safety guarantees and expressiveness that Rust provides. On the syntactical level, C is simple, but the runtime behavior is difficult to reason about. This is evidenced by the countless security vulnerabilities that arise from common, but easy to make, memory management mistakes. The Rust compiler is able to eliminate these bugs at compile time, in part due to syntactical constructs relating to things such as variable mutability. Rust's type system is also stronger and more expressive than C's, which might make it more difficult to learn initially, but in my opinion it's very nice to have features like generics, instead of needing to rely on things like void pointers. Of course, it takes longer for Rust code to compile than C code, but in most cases I am fine with compile time for more compile-time safety and better ergonomics provided by the type system.

Well, guess I am going to play around with Rust now. It's use of Ownership looks really good for ensuring programs are memory-safe without a garbage collection. It seems like a unique approach to memory management, but one that I can get behind: the developer not having to manually manage memory (malloc, free) and memory released from the pool when values go out of the scope of the application.

Does anyone know of any good books for Rust, or know of any good reads / resources for "C replacement" type languages?

Edited September 1, 2021 by cwade12c

[WarFox]

@cwade12c The rust book on the site is as far as I am aware the holy grail for Rust learning right now. I picked up a print version at Barnes and Nobles, so if you prefer pages that is there.

 

interesting to bring up formal verification. I can find the language, but some languages are currently in development where writing it would essentially be like writing a formal verification, any thoughts on this? The one I looked at is still very much in the early phase. Also if those language constructs could come to fruition, would that knock Rust, D, Zig and Nim out of the running for displacing C in some industries?

[Freak]

I've heard of Rust before, but I honestly never looked into it at all and knew nothing about it. Reading the descriptions of it here has really piqued my interest though, and I'm going to take a look for sure. I think I'll also take a look at D.

3 hours ago, cwade12c said:

C will always be here.

When I read this, Wade, it really caught my attention. I think I agree with you, but you really got my gears turning. C was only invented in 1972 which is 49 years ago. It feels old, but relatively speaking it's not. What is technology going to look like in 2100? Will still be things new things being created that use C? 2150? I think it's very likely, and that's so interesting to me.

[WarFox]

There is an issue of the perception of C. Yea, some things are old. However, we also tend to not stay 'up-to-date' with tools and technology in the C world. While Rust has some great features for memory safety, using sanitizers for C code can go a long way in highlighting those memory issues that Rust spots. I did not know about sanitizers in llvm or gcc until I asked a question to NetBSD devs about if there were alternatives to Valgrind on NetBSD since Valgrind is not ported to NetBSD. Nia (NetBSD's audio dev) introduced me to sanitizers. The two classes in my program that use C, there is no mention of most compiler flags. You can go a long way in prevent memory issues by doing:
 

gcc -Wall -pedantic -Wextra -fsanitizer=address <file>.c -o <output_file>

 

Not to mention the update in standards which everyone ignores and the compiler options to enforce coding to standards such as C17 (I am even guilty of this, just look at the makefile of my HttpServer).

So I do feel there is some flak thrown at C that is somewhat well undeserved.

What I do like is new language with new constructs. While right now I am not a huge fan of Rust, I do just see some simple syntactic structures that definitely might fit really well with some use cases. I guess this comment depends on if you agree with Grace Hopper or not. Admiral Hopper believed the best possible scenario was domain specific languages and not a 'one language to rule them all.' I do agree with her approach. While shoving everything into OOP is not optimal for every problem domain, there are simply some cases where OOP is tremendously useful. I can think of game objects in game programming where object structures with inheritance and polymorphism are extremely useful. I do like that most languages being developed now are not purist to one paradigm. But this abstracts into a deeper conversation outside of just the C realm.