My reaction is kind of: "So what?" I really don't care about the relative lives of languages and don't really understand why anyone would. Unless I am wrong, there is still lots of COBOL we wish wasn't COBOL? And that reality doesn't sound like a celebration of COBOL?

IMHO it would be completely amazing if magically something 10x better than Rust came along tomorrow, and I'd bet most Rust people would agree. Death should be welcomed after a well lived life.

To me, the more interesting question is -- what if efforts like c2rust, Eurydice, TRACTOR and/or LLMs make translations more automatic and idiomatic? Maybe C will exist, but no one will be "writing" C in 20 years? Perhaps C persists like the COBOL zombie? Perhaps this zombification is a fate worse than death? Perhaps C becomes like Latin. Something students loath and are completely bored with, but are forced to learn simply as the ancient interface language for the next millennia.

Is that winning? I'd much rather people were excited about tech/a language/a business/vibrant community, than, whatever it is, simply persisted, and sometimes I wish certain C people could see that.

I am happy if people are excited about Rust, but I do not like it too much myself. Although I acknowledge that it contains good ideas, it also has many aspects I find problematic and which why I do not think we should all switch to it as a replacement for C.

Could you share those?

Not trying to argue, just curious on the perspective of a C veteran, as someone who’s just starting with lower level languages.

Nowadays, not so much. Computers are multiple orders of magnitude faster, have multiple orders of magnitude more memory and storage and do things multiple orders of magnitude more complex than they used to. Portable assembly still has its uses obviously, but safer/easier/faster alternatives exist in all its niches.

C is much closer to any other high level language than it is to assembly. 'Portable assembly' might have been true with trivial C compilers of the 70s and 80s, but not with compilers like gcc or clang.

And C is still the best way to talk to the hardware in a portable way.

A while back I wrote some C code to do the "short-bread" problem (it's a bit of a tradition at work to give it to people as their first task, though in Python it's a lot easier). Implementing a deque using all of the modern guard rails and a single file unit test framework still took me a lot of attempts.

C has never been a particularly good language, and is so good that finally (with tons of pushbacks!) there is an alternative that make the case so strong that is at least considered the possibility that will come the very happy day where C will be our past.

The only, true, real blocker is that C is the ABI. But if we consider the possibility that C can AND should be the past, then the C Abi can finally adds sophisticated things like Strings and such, and maybe dreaming, algebraic types (ie: the C will be improved with the required features so it can evolve the ABI, but not because will be a good language for write it (manually) on it).

And to reiterate: C should finally be a real assembly language, something we not need to worry about.

Assembly is used quite a lot and if you're a programmer Assembly is very valuable to know _at least_ how to understand it.

I disagree, also, that C should go away. Saying it was never a good language is a bit harsh. It's a great language. One that industries are built on. I'd rather read/write C code than, say, Rust.

Edit: There are, of course, languages coming up that can absolutely compete with C. Zig could be one when it's mature, for instance.

https://www.rocketsoftware.com/en-us/products/cobol/visual-c...

[0] ISO COBOL 2023 - https://www.iso.org/standard/74527.html

I don't think you understand my point. I am explicitly saying "C will definitely survive (like COBOL)". I am asking is that the kind of life people want for C?

I think it would take a while for that to happen, purely due to momentum' the same thing that makes some people think that Rust isn't being used will affect any younger language just as much, if not more.

I think that there's an easier language than Rust struggling to come out of it, but if Rust had been that easier language with different compromises, I doubt it would have gained critical mass that allowed it to get where it is today. Being fast and safe meant it carved a niche in a "free square" that drove it to have a clear differentiator that allowed it to gain an initial audience. I also suspect that it is easier toale a language fast and then evolve it to make it easier to use, than it is to make it easy to use first and then make it fast.

You'd be disappointed if something 10x better came along tomorrow? I suppose you would you also be disappointed if magically we had economical fusion power, because you own utility stocks? Or we invented 10x better new car, because you already own an old car?

Of course the world wouldn't immediately move to one thing or the other, etc., and we'd still have a 10x better thing?

> Obviously I want better languages to come out, but I'd either want a bit of warning or a slower pace

The purpose of this thought experiment is to say -- it's perfectly fine for things to live and die, if they must. We've had a second Cambrian period for PLs. It's perfectly alright if some don't live forever, including Rust, which I really like.

In my thought experiment, Rust and C could also accept this new paradigm, and adapt, and perhaps become 10x better themselves. Though this is something heretofore C/C++ haven't done very well. IMHO new things don't preclude old things, and there mustn't be only one winner.

> Thankfully languages need about 10 years to mature from 0.1 to production readiness, and industry happily ignores marginally (and moderately) better languages

Which my thought experiment did as well? Read: This is a 10x improvement!

I bet you never wrote single program in Cobol...

Who said it was dead? I was clear that I thought it was very much undead, like a zombie.

    rustc_codegen_clr is an experimental Rust compiler backend(plugin), which allows you to transpile Rust into .NET assemblies, or C source files.[0]

[0]: https://github.com/Xudong-Huang/may_minihttp [1]: https://www.techempower.com/benchmarks/#section=data-r23

==

tokio echo server

run the server by default with 2 threads in another terminal

    $ cd tokio-core
    $ cargo run --example=echo-threads --release
    $ target/release/examples/echo_client -t 2 -c 100 -l 100 -a 127.0.0.1:8080
    ==================Benchmarking: 127.0.0.1:8080==================
    100 clients, running 100 bytes, 10 sec.

    Speed: 315698 request/sec,  315698 response/sec, 30829 kb/sec
    Requests: 3156989
    Responses: 3156989
    target/release/examples/echo_client -t 2 -c 100 -l 100 -a 127.0.0.1:8080  1.89s user 13.46s system 152% cpu 10.035 total

run the server by default with 2 threads in another terminal

    $ cd may
    $ cargo run --example=echo --release -- -p 8000 -t 2
    $ target/release/examples/echo_client -t 2 -c 100 -l 100 -a 127.0.0.1:8000

    ==================Benchmarking: 127.0.0.1:8000==================
    100 clients, running 100 bytes, 10 sec.

    Speed: 419094 request/sec,  419094 response/sec, 40927 kb/sec
    Requests: 4190944
    Responses: 4190944
    target/release/examples/echo_client -t 2 -c 100 -l 100 -a 127.0.0.1:8000  2.60s user 16.96s system 195% cpu 10.029 total

    > What does it take to rewrite the foundational components of one of the world’s most popular Linux distributions? Ubuntu serves over 12 million daily desktop users alone, and the systems that power it, from sudo to core utilities, have been running for decades with what Jon Seager, VP of Engineering for Ubuntu at Canonical, calls “shaky underpinnings.”

    > In this episode, we talk to Jon about the bold decision to “oxidize” Ubuntu’s foundation. We explore why they’re rewriting critical components like sudo in Rust, how they’re managing the immense risk of changing software that millions depend on daily, and what it means to modernize a 20-year-old operating system without breaking the internet.

This is nonsense. Apt devs can target a rustc release and that release can be the same release that ships with Debian? Moreover, since those apt devs may have some say in the matter, they can choose to update the compiler in Debian!

> The entire language culture is built around this rapid improvement.

... Because this is a cultural argument about how some people really enjoy having their codebase be 6 years behind the latest language standard, not about any actual practical problem.

And I can understand how someone may not be eager to learn C++20's concepts or to add them immediately to a code base, but upgrades to your minimum Rust version don't really feel like that. It's much more like "Wow that's a nifty feature, I immediately understand and I'd like to use in the std lib. That's a great alternative to [much more complex thing...]" See, for example, OnceLock added at 1.70.0: https://doc.rust-lang.org/std/sync/struct.OnceLock.html

I'm curious: what do the benchmarks say about this?

An index OOB error? Here, it's important to remember the Rust panic is still memory safe. Perhaps you should read the article, or read up on what undefined behavior is?[0] Here, the Rust behavior is very well defined. It will either abort or unwind.[1]

If you prefer different behavior, there is the get method on slices.[2]

[0]: https://en.wikipedia.org/wiki/Undefined_behavior [1]: https://doc.rust-lang.org/reference/panic.html [2]: https://doc.rust-lang.org/std/primitive.slice.html#method.ge...

We understand you're saying it's not possible in the general case to assert that all memory accesses are in bounds. Instead of that, if you ensure all memory accesses are either in bounds or that they at least do not violate memory safety, you've achieved the requirement of "memory safety", regardless of runtime inputs.

Oh, I read it.

Rust, and for that matter, the person to whom you are replying, above, never claimed that Rust could statically check array bounds. You created that straw-man. Yes, Rust does use static analysis, as one important method to achieve memory safety, but Rust doesn't require static analysis in every instance for it to be Rust's big step function, or for Rust to achieve memory safety.

Yes, certain elements of memory safety can only be achieved at runtime. Fine? But using static analysis to achieve certain elements of memory safety at compile time is obviously better where possible, rather than only at runtime, such as re: Java or Fil-C?

Static analysis has a specific meaning, and rote insertion of bounds checking isn't it.

The equivalent of vector[i] in Rust is Vex::get_unchecked, which is marked as unsafe, not the default that people reach for normally.

I refuted that point by pointing out that the same process, if done manually in C++, would not be considered "static analysis that provides memory safety for array access".

C++ can have UB, compilable non-unsafe Rust can’t, that’s what static analysis of memory safety is.

Main point here is you don’t know (and refuse to learn) new knowledge.

People really got to stop with crazy nonsense.

Deadlocks can happen anywhere? You can replicate this pattern in golang.

But, to be very clear, Rust has never claimed to prevent deadlocks?

See: https://doc.rust-lang.org/reference/behavior-not-considered-...

Then blame Canonical? Quit it with the Rust hate.