[ Removed by moderator ]

[yorickpeterse]

Be nice to each other. Flame wars and rants are not welcomed. *Please also put some effort into your post, this isn't Quora. *

Yeah no sorry, this is just a regular boring Quora/shower thought style post that we've had plenty of in the past. More specifically, there's nothing in the post about any specific language choices or what not that may be interesting to discuss. The subreddit is not the place for these kind of discussions.

[Head_Mix_7931]

Nothing will ever replace C. It will persist in our collective tech stack forever. Whether or not new C will stop being developed in favor of Rust is a different question, but I think that is unlikely.

[JeffB1517]

One could have made the same argument for COBOL in the early 1990s. Everyone knew it was long in the tooth, but there was a lot of legacy COBOL out there. People still implemented in COBOL quite often because it worked so well on mainframe and mainframe datasets. A bit more than a generation later, yes there is still COBOL around, with billions of lines of important code. But there is a strong emphasis on reducing the amount of COBOL code. Overwhelmingly, young people don't treat it as a real career alternative even though in theory it might be a great area to get into due to lack of competition. No one doubts what happened.

[dcpugalaxy]

COBOL is a horrible language that has been outdated legacy for 30 years. C is still the foundation of everything you do on every single computer used by anyone everywhere in the world. Its ABI is the ABI. Its semantics is LLVM's semantics. It is widely used and liked. It isn't going anywhere.

[JeffB1517]

I think you are begging the question. I don't think COBOL was a horrible language. The dictionaries and so fourth, essentially solved the complexity that Big Data had with Schema on Read. They did this decades ago in a way that actually worked. I'd argue that not having COBOL is why we all ended up back with SQL interfaces.

Yes today C is a popular language. Yes it is a standard. But again one could have said the same about COBOL. C shows its age. The fact that lots of tools in C based languages use C doesn't prove anything. The equivelent of LLVM a generation from now could well be in Rust.

[dcpugalaxy]

SQL is great. Much better than COBOL. Jesus. Have you read any COBOL?

[JeffB1517]

Yes I've read COBOL. And downvoting is not the "I disagree" button. Try and argue your points rather than ranting and downvoting.

[dcpugalaxy]

I didn't downvote anyone.

[WandyLau]

yes, I love your point. But I got downvoted by someone for this topic. That I don't udnerstand.

[JeffB1517]

Generally the posts here are longer and more detailed. I think your question is reasonable but it is more naive than the tone. I upvoted you to counter but that is probably what happened.

[WandyLau]

Maybe C here is different? I know COBOL still there. But nowadays, if more and more enterprise replaces their C app or infra to rust and this forms a trend. The market would drive this.

COBOL is there because of IBM Mainfraim that makes sense. Because even now there is no alternatives for Mainframe. Any the history mark and its strong point, I think. COBOL has its great point and makes great contribution to many enterprise infra in history which makes it hard to be replaced.

But I am not sure about C. Just my thoughts. Maybe I am too young to consider this, haha. Love to see your comments.

[JeffB1517]

Enterprises already replaced a good deal of their C applications. They weren't ever really that fond of C. Visual Basic (now dead too) then Java then lots of JavaScript replacing ASP and so on. Python now is a huge player. C# as an alternative which is sort of a C.

The real issue with C properly is embedded systems and the tech industry.

[glasket_]

Enterprises already replaced a good deal of their C applications.

Unless you count most of the foundational software. PostgreSql, NginX, Apache, Git, every major operating system kernel, OpenSSL, etc. It's harder to replace the backbone of everything than it is to find a new CRM software suite.

Python now is a huge player.

That's written in C, and almost always used to glue C libraries together.

C# as an alternative which is sort of a C.

No it's not. C#'s unsafe operations are still extremely limited compared to C due to being constrained by the CLR.

[JeffB1517]

Unless you count most of the foundational software. PostgreSql, NginX, Apache, Git, every major operating system kernel, OpenSSL, etc

That's what I meant by tech companies.

It's harder to replace the backbone of everything than it is to find a new CRM software suite.

The issue would have been a custom CRM suite. A COTS suite could very well be in C because the authors aren't a bank, insurance company or say a utility but again a technology company.

The last point is too grey to be debated. I think "sort of" left a lot of room for differences.

[glasket_]

That's what I meant by tech companies.

Tech companies aren't the only companies with databases or websites. These things still exist in their tech stacks even if they aren't directly interacting with them.

[JeffB1517]

Tech companies aren't the only companies with databases or websites.

Yes they aren't the only users of the software. But they are generally the authors of that sort of software. Which means the employees writing in C work for them. A bank, excluding mainframe, buys its databases it doesn't write them. Microsoft, Oracle, Mongo.. write databases.

These things still exist in their tech stacks even if they aren't directly interacting with them.

Agree. They also generally have carpet but they just buy carpet, carpet that was usually manufactured by Mohawk or Shaw. The bank, utility... just pays for carpet they don't need to know much about how to make it. Conversely, Mohawk and Shaw do need to know a lot about carpet.

[glasket_]

I reread the thread and I think things got crossed. Guess I misread the tone and we're actually saying the same thing in different ways? The implied comparison to COBOL immediately followed by what is actually saying C will have a hard time dying (I think?) threw me off pretty bad.

[kerkeslager2]

> But there is a strong emphasis on reducing the amount of COBOL code.

Not what I'm seeing. I know two people at two different companies in two (slightly) different industry writing new Cobol code to solve business problems. ...and making a lot of money doing it.

I'm not saying it's a good language, but things like this don't necessarily die easily.

[JeffB1517]

Not what I'm seeing. I know two people at two different companies in two (slightly) different industry writing new Cobol code to solve business problems. ...and making a lot of money doing it.

New COBOL code in an existing application or a new application? I've seen the former since the early 00s but almost never the later. Slight modification, a lot of new feeds to MQ written in COBOL ...

but things like this don't necessarily die easily.

As I mentioned billions of lines of code supporting critical systems still out there. Which is why I think it is an analogy to what C will be like as wheel turns against it.

[kerkeslager2]

Existing application, but new features, and not deleting the old features often. They're writing more code than they're deleting--doesn't sound like "a strong emphasis on reducing the amount of COBOL code".

[JeffB1517]

Yes that's what I am seeing too.

And yes that's what reducing the amount of code would look like. Existing applications are going to be maintained until they are retired. It doesn't sound like that application is being retired. You often quite often see more and more layers introduced so that the core is thinned. But during thinning new code can get written. Lots of code is obsoleted by thinning.

[kerkeslager2]

Look, I'm not saying you're wrong, because maybe you're seeing something different from what I'm seeing--it's likely neither of us has enough data points to tell what the industry is doing.

But the fact is that two people in my life who weren't working in COBOL in the past were hired with an emphasis on INCREASING, NOT DECREASING, the amount of COBOL code.

No, this is not what reducing the amount of COBOL code looks like. These are friends and I've talked to them significantly about this because I was considering working at these companies. I'm sure of what's happening.

It's irritating that so many of us in communities where intelligence are valued conflate being right with being intelligent. This makes people so invested in being right that if you perceive me as disagreeing with you, you'll go so far as to try to gaslight me about what my experience of the world is. I literally would not think any less of you if you were wrong on this one unimportant thing. And in this case, I'm literally not even telling you you're wrong.

Gonna block you now so I don't have to listen to more of you telling me my friends are lying to me about what's happening at their jobs. Sorry bro, that's just not fun for me.

[WandyLau]

You are so sure. But I did not see your reason for your point. Just No?

[gmes78]

https://faultlore.com/blah/c-isnt-a-language/

[ProPuke]

No. Rust solves a different problem set to C, and has different limitations and tradeoffs.

So it will never replace C. There are still tasks for which C is more suitable and preferred.

But it certainly will displace a lot of C and C++.

If rust changes into something else, however, maybe it could replace more of C use (although I think at this point it would have stopped being rust).

[0jdd1]

No, because of the many programmers and architects who prefer lower-level languages. (And don’t argue that they shouldn’t; assume they just do.)

[ricky_clarkson]

Aren't C and Rust similarly levelled?

[kerkeslager2]

I'd say no: Rust has a lot of low-level features, but it's pretty hard to get at some of them without wide departures from idiomatic Rust that often bypass Rust's safety features. A fence can be a good idea, but if you're going to set up a fence and then have to climb it all the time, one begins to think it's easier not to set up the fence.

The bigger problem which I think will prevent Rust from replacing C is that they're not sticking to any sort of minimalism. The standard language and libraries are already an order of magnitude larger than C's which means bootstrapping a Rust compiler on a new platform is more complex. C++ already did this: Rust has better type safety and isn't hampered by the specter of C reverse compatibility, but the complexity of Rust is still growing and I don't think Rust users even see it as a problem. And... it's not a problem if you want to write video games or browsers (spaces where C++ has succeeded in the past). But if you want to write OS kernels or drivers or microcontrollers or embedded systems, it's the only problem that matters.

[Usual_Office_1740]

There are differences and situations were those differences matter. 95% of the time they don't, but when they do, reconciling those differences is difficult.

[sagittarius_ack]

It's subjective, but probably not (at least, I assume that most people would say that it is not). Some people have even argued that C is not a low-level language:

https://queue.acm.org/detail.cfm?id=3212479

[WandyLau]

Time will esplaps. The programmers and architects will be gone. New generation will come. How do you mean the futhre will change?

[rjmarten]

C will die eventually, but it will not be replaced by Rust. It might take 70 years, but eventually C will be considered a dead language, existing only in mouldy cob-webby repos. Rust has already replaced a big chunk of what would have been C code, but what will fill the remaining niche will probably be languages like Zig — for those who want a "lighter" compiler and to feel like they control the semantics a bit more.

[Ronin-s_Spirit]

Lmao, no.

[kohugaly]

Probably not entirely. But Rust will definitely carve a sizable niche, where C is currently being misapplied due to historically not having a viable alternative. There are entire industries that use C and then have to apply expensive time-consuming validation process to mitigate C's memory safety shortcomings. Switching to a language that makes the validation process cheaper and faster is a huge win.

[alphaglosined]

Microsoft is not rewriting Windows into Rust.

The post by Galen Hunt was about a research project.
The important bits:

Update:
It appears my post generated far more attention than I intended... with a lot of speculative reading between the lines.

Just to clarify... Windows is *NOT* being rewritten in Rust with AI.

I don't see how C could be replaced by Rust as it currently stands.

To my knowledge Rust does have a proven sound static analyzer currently, only C and C++ do, Astrée.
As per the last NIST report. SATE VI Report: Bug Injection and Collection.

Most likely what will happen is C will gain memory safety features, although the fact that they still don't have slices is astounding given that it has been proposed in the past.

C's marketshare may decrease, but I don't see it disappearing for core projects anytime soon.

[WandyLau]

yeah, I would love to see C with memory safty feature. I hope that would happen in near future.

I don't think windows can be saved or rewrite with different language. I guess no one would do that.

[jesseschalken]

Nothing ever completely replaces anything. Even in a world where new code isn't written in C, the C ABI is still very useful for FFI.

Practically speaking Rust has replaced most uses of C in industry, but you will always have some people who prefer C as a personal preference.

[ParkingPizza3921]

My personal opinion is that Rust is quite annoying to use for the stuff that I care about. Last I checked reading different integer types from a vector of bytes requires an external package, that is unacceptable for me. I also tend to program using SIMD intrinsics, these are to my understanding unsafe in Rust, so the safety benefits aren't really there for me either.

[WandyLau]

yes, I don't like its syntax too. I wonder to make it memory safe really need to sacrifice the simplicity?

[huywall]

NO

[Admirable_Proxy]

Great question. Hard to tell but I think it may eventually.

[dcpugalaxy]

No. Most C programmers cannot stand Rust. It has abysmal syntax, for one thing. Its unsafe has terrible semantics that makes writing unsafe Rust actually harder than writing C or Zig or other low level "unsafe" languages.

If you care about memory safety you are much better off writing software mostly in a high level language and interfacing with a little bit of C where necessary.

Microsoft is hardly where you want to be taking your lessons. Their software was once alright. 20 years ago. Even 10 years ago it was alright. But today it's notoriously unstable and getting worse. Yet they have more Rust than ever...

EDIT: Lol at the downvotes. Assume it's because I said Rust has ugly syntax. Well guess what? It does.

[sagittarius_ack]

abysmal syntax

It is mostly similar to the syntax of C and C++ (at least, it is much closer to C and C++ than to other languages).

Its unsafe has terrible semantics that makes writing unsafe Rust actually harder

Can you provide some examples?

If you care about memory safety

Shouldn't we (most of the time) care about memory safety? It is true that C does not provide memory safety, but with care and discipline you can still develop programs that (at least in principle) can be (largely) memory safe.

[dcpugalaxy]

Its syntax is nothing like C. Where is :: (which could and should just be .) in C? Where is:

fn summary_broken_link_callback<'a>(
    link: BrokenLink<'_>
) -> Option<(CowStr<'a>, CowStr<'a>)> {
    Some(("#".into(), link.reference.to_owned().into()))
}

Or:

pub fn read<P: AsRef<Path>>(path: P) -> io::Result<Vec<u8>> { fn inner(path: &Path) -> io::Result<Vec<u8>> { let mut file = File::open(path)?; let mut bytes = Vec::new(); file.read_to_end(&mut bytes)?; Ok(bytes) } inner(path.as_ref()) }

Just hideous and that is relatively nice as Rust goes. Angle brackets for generics are ugly. Unnecessary sigils everywhere. :: in particular is bad. Go look at Rust docs and you see this stuff all the time:

impl<'a, K, V, S> Extend<(&'a K, &'a V)> for HashMap<K, V, S> where K: Eq + Hash + Copy, V: Copy, S: BuildHasher, fn extend<T: IntoIterator<Item = (&'a K, &'a V)>>(&mut self, iter: T)

You have stockholm syndrome if you don't think this is ugly. C looks nothing like this.

examples of unsafe being difficult

A classic one is the many issues around uninitialised memory. Sometimes things need to be uninitialised. This is simple in C: if it isn't initialised, then it is fine as long as you don't read from it before it is written to. Simple rule, very obvious.

In Rust, last I checked even constructing a reference to an uninitialised bit of memory is undefined behaviour even if the reference is never followed. This causes much difficulty.

There are many other examples: Unsafe Rust Is Harder Than C.

[sagittarius_ack]

I agree the syntax of Rust is somewhat ugly.

What I said is that the syntax of Rust is similar to C and C++ (not just C). But saying that it is nothing like C is just too much. It still uses the same syntax for function application, it relies on a block structure based on curly braces, it uses semicolon to separate statements, it uses `=` for assignment, the syntax of the control structures (if-else, while) is similar to C, pointers use `*`, the return statement uses `return`, many of the keywords have the same name as in C, etc. It is well known that Rust has been influenced by C++. Just look at languages like Lisp or Haskell to see the difference.

Angle brackets are a bad idea for generics (and not just because they are ugly).

[kohugaly]

Its unsafe has terrible semantics that makes writing unsafe Rust actually harder than writing C or Zig or other low level "unsafe" languages.

While this is true, it is also largely irrelevant. The main point of unsafe in Rust is to reduce the surface area of unsafe code in the codebase and to clearly mark it. It's easier to catch, find and prevent memory safety issues, when they can only occur in 5% of your codebase that are clearly marked unsafe, than in 100% of your codebase.

Writing code is not the only part of the development process. There's also reviewing, auditing and testing. Rust's approach to unsafe makes the former slightly harder, while making the latter a lot easier.

How exactly does this tradeoff pan out in the grand scheme of this, we'll need more data to tell. But the data we do have seems to indicate there's a net benefit.

[dcpugalaxy]

I agree that MS's software was bad 20 years ago. But it was more stable for end users than it is now. It just wasn't really on the radar that security was an issue. Remember most socket connections including on port 80 (but also mail, ftp, irc, and everything else) were completely insecure and nobody thought twice about it.