3 ms·

The overarching argument in this article seems to be sort of chicken and an egg. > 4. No experienced developers Well, with C you need experienced devs that ar

The overarching argument in this article seems to be sort of chicken and an egg. > 4. No experienced developers Well, with C you need experienced devs that are also EXPERIENCED IN C. You can write C that compiles but is all kinds of incorrect, usually subtly. Any new language that works with the dev on writing correct code or outright refuses to compile with incorrect code (hinting at Rust here) cracks this egg a bit. > If you want to target some obscure platform, then likely it's assuming you're using C. Some (most?) obscure platforms offer a fork of GCC, yes. With LLVM frontend becomes less and less relevant. This particular chicken and an egg is being broken with or without a successor to C. > Any C alternative will be expected to be on par with C in performance. The problem is that C have practically no checks, so any safety checks put into the competing language will have a runtime cost, which often is unacceptable. This leads to a strategy of only having checks in "safe" mode. Where the "fast" mode is just as "unsafe" as C. This argument is circular. There are indeed some scenarios where you do absolutely need "macro system for assembly" to do some weird shit, but typically that is a relatively small part of the whole project. Unsafe modes help tackle this small need. The argument reads like needing C-ish language for some little parts of your project requires to use C-ish language for the whole project. > 3. Programmer productivity This whole argument is weirdly focused. In my experience, a huge chunk of effort is spent on rework. Any language that improves turnaround rate improves productivity on feature level. The argument again assumes that devs manage to produce correct code without turnarounds (which is rare in practice even with highly experienced devs) and therefore any new language would increase turnarounds. Safety and productivity features are usually designed to increase quality without expertise-floor.

arnsholt 1mo ago
Yeah, it's not that the hurdles pointed out in this article are wrong, but IMO the jump from "it's very hard" to "it's impossible" isn't convincingly argued. In discussions of the future of C, something along the lines of "C is never going away" is frequently said, which I think is both right and wrong, depending on what precisely you mean by "going away". If you ask me, C is not going away in the same way that Fortran never went away: it's still hugely important for numerical kernels used extremely widely every day, and software like sqlite will continue to be important. But for C as a culturally defining language in computing, I think the tide is already turning.
- shevy-java 1mo ago
  > But for C as a culturally defining language in computing, I think the tide is already turning. The problem still is which language will replace C here. C++ won't. Neither will Rust or Java. So which language will replace C here? I agree that C and Fortran can not be compared really. C will remain for a very long time to come.
serbuvlad 1mo ago
> Any new language that works with the dev on writing correct code or outright refuses to compile with incorrect code (hinting at Rust here) I've started writing Rust in the past year and... honestly... I LOVE it. But what kept me away from Rust for a long time is this talking point of rejecting incorrect code which is so obviously wrong it made proponents of Rust sound very cultish to me. Rust cannot prevent incorrect code, nor is this possible (halting problem). What Rust can do is enforce a very specific type of correctness, which may be termed resource-use-correctness. Basically it can enforce that every resource that is used, is properly opened, is properly accessed, has (one writer) OR (multiple readers and no writer) at a time, and is properly closed. It can do this for memory, files, sockets, as well as arbitrary constructs of your choice. This ability is extremely valuable! But it is also quite easy to write incorrect buggy programs in Rust, for the very simple reason that it is very easy to write incorrect buggy programs that do not misuse their resources.
- friendzis 1mo ago
  > But what kept me away from Rust for a long time is this talking point of rejecting incorrect code which is so obviously wrong it made proponents of Rust sound very cultish to me. In discussions regarding testing and static vs dynamic languages, I like to emphasize the point that with static languages you get some "tests" for free: the compiler enforcing the contract will "test" that you are not passing in string for integer. With e.g. Python if you want to be defensive and on the correctness side, you need to implement poor-man's type restrictions and tests for the unit so it behaves sensibly with call-site being incorrect. Does it sound cultish to you to insist on static type checks when e.g. writing Python? There's quite tangible value in that. > Rust cannot prevent incorrect code, nor is this possible (halting problem). Yes, nothing will prevent analyst/PO from misunderstanding business requirements, nothing will prevent dev from misunderstanding the technical requirements. Or not thinking things through. Errors on this front will always turnaround. Correctness in this context refers to programmer's and compiler's understanding of code being aligned. Correct code does what it is supposed to do. Rust takes type safety and elevates it to a next level, ensuring reads, writes and object lifetimes are correct.
  - 1mo ago

arnsholt 1mo ago

Yeah, it's not that the hurdles pointed out in this article are wrong, but IMO the jump from "it's very hard" to "it's impossible" isn't convincingly argued. In discussions of the future of C, something along the lines of "C is never going away" is frequently said, which I think is both right and wrong, depending on what precisely you mean by "going away". If you ask me, C is not going away in the same way that Fortran never went away: it's still hugely important for numerical kernels used extremely widely every day, and software like sqlite will continue to be important. But for C as a culturally defining language in computing, I think the tide is already turning.

shevy-java 1mo ago
> But for C as a culturally defining language in computing, I think the tide is already turning. The problem still is which language will replace C here. C++ won't. Neither will Rust or Java. So which language will replace C here? I agree that C and Fortran can not be compared really. C will remain for a very long time to come.

serbuvlad 1mo ago

> Any new language that works with the dev on writing correct code or outright refuses to compile with incorrect code (hinting at Rust here) I've started writing Rust in the past year and... honestly... I LOVE it. But what kept me away from Rust for a long time is this talking point of rejecting incorrect code which is so obviously wrong it made proponents of Rust sound very cultish to me. Rust cannot prevent incorrect code, nor is this possible (halting problem). What Rust can do is enforce a very specific type of correctness, which may be termed resource-use-correctness. Basically it can enforce that every resource that is used, is properly opened, is properly accessed, has (one writer) OR (multiple readers and no writer) at a time, and is properly closed. It can do this for memory, files, sockets, as well as arbitrary constructs of your choice. This ability is extremely valuable! But it is also quite easy to write incorrect buggy programs in Rust, for the very simple reason that it is very easy to write incorrect buggy programs that do not misuse their resources.

friendzis 1mo ago
> But what kept me away from Rust for a long time is this talking point of rejecting incorrect code which is so obviously wrong it made proponents of Rust sound very cultish to me. In discussions regarding testing and static vs dynamic languages, I like to emphasize the point that with static languages you get some "tests" for free: the compiler enforcing the contract will "test" that you are not passing in string for integer. With e.g. Python if you want to be defensive and on the correctness side, you need to implement poor-man's type restrictions and tests for the unit so it behaves sensibly with call-site being incorrect. Does it sound cultish to you to insist on static type checks when e.g. writing Python? There's quite tangible value in that. > Rust cannot prevent incorrect code, nor is this possible (halting problem). Yes, nothing will prevent analyst/PO from misunderstanding business requirements, nothing will prevent dev from misunderstanding the technical requirements. Or not thinking things through. Errors on this front will always turnaround. Correctness in this context refers to programmer's and compiler's understanding of code being aligned. Correct code does what it is supposed to do. Rust takes type safety and elevates it to a next level, ensuring reads, writes and object lifetimes are correct.
- 1mo ago