One of the niceties of C is that I can get anything done pretty damn quickly, without anything getting in my way. The syntax is extremely simple, too, vs. Rust. Rust is close to Perl when it comes to syntax; full of symbols. Too implicit for me. I want to look at the code, and I want to understand what the heck is going on, even if it is written by someone else. I usually do, with C. Rust? Not so much, and believe me, I tried. I would not like to call myself an idiot, either. :)

A viable C replacement is Ada, although it is not for people who dislike the "code is documentation" bit.

> One of the niceties of C is that I can get anything done pretty damn quickly, without anything getting in my way.

not saying you're necessarily wrong (c is definitely simpler than rust), but I think most people would write a similar comment for whatever language they feel most comfortable with. I write c++ most days. even though it's the most verbose and complicated language I've ever used, I can still probably get stuff done way faster than in another language I happen to pick up.

if I'm just throwing something together really fast, I do mostly use the old school C functions though. scanf is way nicer than streams.

Agreed - in that I write it in Perl if I need it to just work right now. Perl is still, to me, the most useful programming language for completing a generic program in the smallest amount of time. (Part of that is due to CPAN, and part to the gazillion built-in features of Perl 5)

I agree. I’m an older programmer (almost 61) and I’ve been using Perl for a long time - maybe 20 or 25 years. I reach for it when a job feels like a bit too much for a bash (1) script.

I don’t go out of my way to teach or suggest Perl to my younger colleagues. I don’t know why that is. They don’t usually reach for Python, which I think would probably be their best choice.

Maybe I’m just a curmudgeon ... and by the way, can you please stay off my lawn?

:)

One way rust's just a different tool for a different job, is it really doesn't optimize for knowing everything that's happening inside someone else's code. It's a great example of the difference in procedural vs functional programming, where in rust you mostly just care what your function args are and what it returns.

Nothing wrong with learning multiple languages, of course. C was my first professional language, and I spend most of my days in rust now. No shortage of rust devs who are big on C too.

Sure. I code in C, Go, OCaml, Ada/SPARK, Factor (Forth-like, Lisp-y), Common Lisp (rarely), and Erlang (moving to Elixir).

But I was responding to "C code is being replaced by Rust fast.".

You might like zig. It's still pre 1.0, but I feel like it really has that "get out of your way" feel of C with a ton of safety. If you write tests, you can get tested memory safety, too.

Zig has a LOT of good stuff going for it but one of my pet peeves is how arsey the linter gets about formatting. No tabs (They might begrudgingly fix that one), no multiline comment/string support (and before anyone tries to correct me on the strings front, you look at that syntax and tell me it isn't an intentional joke), you must use these specific line endings (That one was actually fixed in master recently iirc)

The syntax is also currently REALLY unstable. As in: The hello world has changed almost every major version. Hopefully that too will be squashed with 1.0

To be fair though, Zig is probably the lest egregious and most flexible of the modern "C killers". I can see it's really trying to innovate low level programming. I really like it's flexible malloc systems and support for dynamic linking at runtime. It's compile time code execution is excellent too. The fact that they're actually trying to support obscure platforms like the z80 is a good indicator that they're staying true to C's "code anywhere" mantra. That's why I'm mostly focusing on linting issues of all things.

Ah. If anything, the whole "rust as better than C for everything" thing is starting to hurt its reputation, regardless of veracity. People get so focused on its use in perf-critical applications they ignore its other strengths. eg I've never replaced C code with it, but we redid our whole PHP backend as a rust app, because it's great for rigidly defined business rules too.

Ah. If anything, the whole "rust as better than C for everything" thing is starting to hurt its reputation, regardless of veracity. People get so focused on its use in perf-critical applications they ignore its other strengths. eg I've never replaced C code with it, but we redid our whole PHP backend as a rust app.

Young programmers seem to prefer learning Rust than C. Generational replacement will take care of making Rust prevalent, no matter what existing programmers think.

Do they? Or are they just told that they should be using Rust? Even putting aside outdated curriculum, Rust is a fairly involved language to teach to a new programmer.

Indeed. What languages are most common in universities anyways? Haskell? Java? C++? OCaml? Which ones are the most common?

Maybe he meant outside of the education system. I think the reason for that would be hype and peer pressure, and the feeling of novelty, with a hint of FOMO. I do not see any languages being pushed/hyped as hard as Rust.

I investigated this in Florida. I checked Florida Tech, Embry-Riddle, and a half dozen state universities. One was Java, two or three were C++ (really C with cout and maybe vector), and all the rest were plain C.

That is a mighty good showing for C.

I can't imagine universities actually caring to teach new programmers Rust... it's an overly complex language that most professors themselves would steer far away from because they know there's more to programming than following trends.

(We learned C++ in university in New York which was basically C with occasional help from C++'s standard library).

Sadly the latter is often how C++ is taught even though it is not at all how modern C++ is used…

My much younger brother is currently enrolled at a a major university in comp sci. His coursework is primarily in Java but with certain classes in C and other languages.

My guess is that those four see more use than Rust does, with Java and C++ forming the base of a typical undergraduate curriculum alongside Python and C and Haskell and OCaml showing up in classes where the concepts behind them are typically introduced. (FWIW: my college experience was C++, C, Scala for the required courses.)

I believe we will come back to C eventually. Kind of irrelevant but: I learnt C by writing mods for ioquake3 forks. :) Fun times. I was about 13 years old.

Lol.

For every young programmer learning Rust there are probably 10000 learning C.

C is still the only language you can count on anyone with a programming-related education to have knowledge of. (That doesn't translate into being able to program is C, but still.)

I love the move to d/rust/zig/nim/... but there are other issues too. Ecosystem of libraries, stabilisation of common patterns (futures and Tokio issues are still out there), platform compatibilities, industry support for moving away from known solutions, and many other issues. Even if we all suddenly knew Rust perfectly tomorrow, there are other issues in the way.

futures is definitely the big one for me. Getting all concurrency fully on async/awaits is amazing, e.g. actix-web awaiting an endpoint calling juniper for graphql, with async resolver methods making async calls against my DB, without needing to spawn a single thread, is lovely. Still doesn't work as smoothly as that, even though on paper it ought to. Getting close though.

> C code is being replaced by Rust fast.

One of the key areas C is used that Rust cannot be used easily is in limited embedded devices. That looks like it'll be the case for at least 10 years and probably much longer than that.

The embedded Rust ecosystem is actually pretty vibrant these days. The number and quality of #![no_std] crates is improving rapidly.

The main limitation is going to be if your MCU is supported by LLVM. If you're targetting ARM, RISC-V, MSP430 or Xtensa you might get further than you'd expect.

There's a hell of a lot of tooling built around C though. So nomatter what happens I don't think we'll ever be rid of it.

Many, if not most, small MCUs can also run C++ these days as just as well as C. If you want to write simpler and more robust applications, it's easily achievable.

I used to write whole bunch of firmware for microcontrollers and frankly C was doing just fine for me in this area.

> C code is being replaced by Rust fast. The only limit is how quickly programmers can become good at Rust. It's already happening.

I think Rust has been very quickly fading into obscurity. What Rust hast brought to the tables was nearly the same what was brought by 100+ other programming languages in attempts to "fix C."

Oh... can you show me those 100+ other languages that have opt-out memory safety, explicit lifetime annotation, a borrow checker and no runtime?

Cyclone, ATS, Checked C, Ada/SPARK.

Footnote: With Ada/SPARK being much more battle-tested and ATS being a much more flexible & complete solution. Though I wouldn't exactly recommend ATS in terms of learning curve.

That’s an extremely specific reading of the claim “fix C” that excludes almost everything but Rust.

I never said those are the only ways to fix C. Try reading the argument again:

> What Rust hast brought to the tables was nearly the same what was brought by 100+ other programming languages in attempts to "fix C."

> Oh... can you show me those 100+ other languages that have opt-out memory safety, explicit lifetime annotation, a borrow checker and no runtime?

Maybe I can make it even clearer:

> What Rust has brought to the tables was nearly the same as 100+ other languages

> Oh... can you show me those 100+ other languages that have (some unique Rust features)

It isn't. You can tell how much a language is used by the inverse of the number of blogposts about it. People who have jobs don't have the time to write about how they would solve problems using that language, because they already are and have better things to do in their free time.

It is. Since 2012 C has dropped from about 4% of Github code to 3%. Meanwhile Rust has climbed from 0 to about 1%. That on its own doesn't prove that people are moving from C to Rust but it's not a risky guess. I did see some data on language transitions a while ago but can't find it now unfortunately (why is browser history search still so shit?).

https://madnight.github.io/githut/#/pull_requests/2020/2

>(why is browser history search still so shit?)

Because Google wants people to search using the Google search engine, and see ads while they're at it. That would happen less often if Chrome were properly capable of searching the history.

Opera did full text history search a decade ago, but that browser doesn't exist anymore.

Also, history is expected not to be tied to the device in the cloud era. What more history data could you scalably sync other than URLs and page titles?

Number of blogposts about Python is a counter-argument.

The number of people employed as python programmers is vastly smaller than the number of people who can write hello world in python, which is what the majority of blog-spam is about.

There's a lot of truth in it, but for a slightly different reason. Almost everyone I work with knows or writes C regularly. They're usually very senior people, and not once have I ever heard them talk about a blog, let alone write one. so there is this large group of C practitioners out there that simply don't know or care about all these other things happening around them. To some degree, it doesn't matter since there are plenty of jobs doing this.