28 ms·

The case against a C alternative

217 points by lerno 4y ago

bediger4000 4y ago
Well argued. Lots of things factored in.
imachine1980_ 4y ago
the only better c that will count is if c add some features that are critical like a standard library that is more powerful i know c++ 17 have some improvements but need alternatives for most things is not good for the ecosystem, and the old only if you want, is 2022 most embedded system use this tools, we need c to have a reasonable standard library, the whole world depend on it.
- gregoryc_ 4y ago
  Check out https://cboard.cprogramming.com/c-programming/181160-hi-i-have-created-some-work-i-think-will-really-valuable-community.html https://cboard.cprogramming.com/c-programming/181160-hi-i-ha... I posted this less than 24 hours ago. This might be what you want, and there's no overhead at all. It might actually speed up your code. 15x faster regex I just made this. I'm looking for contributors :)
TAForObvReasons 4y ago
(4) is extremely important. Labor pool is smaller and there won't be a wealth of soft documentation and people that can provide immediate support for common questions.
- nicoburns 4y ago
  It is, on the other hand it's a lot of easier to write correct code in, well, almost every language other than C. To give a concrete example, I was able to write production-ready code with 2 weeks of Rust experience and nobody to provide support for questions (beyond reading StackOverflow), and that code was more reliable and less buggy then the Python/JavaScript code our company was otherwise writing, even though we were collectively much more experienced in those stacks. I doubt we'd have gotten that with C, even though we had a bunch of developers who were experienced with C.
  - FpUser 4y ago
    And I wrote a firmware in C for 4-quadrant torque control in about the same time. I do not have any formal proof on how buggy/or not it is but the thing runs properly for 10 years already. If that is not "production code" I do not know what is. I am not inexperienced programmer. Rather quite opposite. But this was after I did not touch C and any microcontrollers for like 10 years.
    - nicoburns 4y ago
      I feel like C is somewhat manageable on microcontrollers. Programs tend to be smaller (micro!), you can often do static allocation which mitigates a lot of the memory management issues, and you're also often dealing with simple types and bit manipulation which is where C shines. In larger programs on full-fat operating systems, programs tend to be much larger (esp. if you include libraries - dealing with libraries being one of the most complex things in C), and you have to deal with sophisticated allocation patterns, and complex types (webs of pointers), abstractions and business logic which is where C basically leaves you on your own and provides very little in terms of structure or guard rails.
      - voidhorse 4y ago
        This is how I’ve started to think about things too. If every program was authored by a single individual and was relatively small, C would already be the perfect programming language. All the advanced safety features of competitors really only become relevant once you introduce scale.
      - FpUser 4y ago
        Generally I agree with everything you say. Each tool has areas where it shines and the opposite. One of the reasons I use multiple languages.
arcticbull 4y ago
(5) is pretty irrelevant, ABI isn't language. You can strap basically any language on top of the C ABI. Many contender languages either use it natively or offer low-cost/no-cost C ABI bindings, specifically as its the lingua franca ABI. You can check (5) off your list if your choice of replacement language has easy C ABI interop. [edit] (1) isn't particularly relevant either. These days the tooling for detecting memory leaks, data races, bugs, etc, operates at the debug info (DAWRF/dSYM) level. It doesn't matter what compiler or input language generated the debugging information, the tools should work just fine. You can run valgrind on your Rust binary for instance. [1] Is there any such tooling that specifically depends on the input source being C? I guess some static analysis tools? [1] https://nnethercote.github.io/2022/01/05/rust-and-valgrind.html https://nnethercote.github.io/2022/01/05/rust-and-valgrind.h...
- AceJohnny2 4y ago
  Yeah, I'm also confused by this. A platform will define an ABI which, as I understand it, explains how parameters are passed to and returned from a "function", what types are supported and how they're encoded, at the processor register and stack level. C, being the "portable assembler" [1] that it is, maps its types and functions pretty easily to that platform ABI, but I've been seeing a fair amount of confusion about that ABI being about C rather than any language that can link through that platform ABI. Couldn't it just as easily be called, I dunno, the Ada ABI? [1] not really, except for the sake of this argument
- deleted 4y ago
  [deleted]
- yazzku 4y ago
  Why is this down-voted? C does not have a standard ABI, this guy here is right?
  - deleted 4y ago
    [deleted]
omgmajk 4y ago
I agree with most things in this article really, but then again, handmade.network has some quality in it overall.
yazzku 4y ago
Next: the case against Cloudflare-gated websites.
- intelVISA 4y ago
  you don't enjoy having half of the Internet MitM'd?
  - yazzku 4y ago
    More than you can possibly imagine.
jhatemyjob 4y ago
Ive been thinking about this topic for years and OP was finally able to put it in writing. I dont think anyone would claim english is the best, but it just so happens that the most powerful empire on earth (until recently?) uses it as its primary language. Its good enough at what it does, and has a lot of history backing it up With this knowledge I choose to align myself with languages and platforms that respect C and complement it (Lua, Objective-C, etc) instead of languages and platforms that try to supplant it (c++, java, swift, rust, etc)
- boffinAudio 4y ago
  I concur with you - everything I want to do in Rust or Golang, I can do with C+Lua just as easily and with far less tooling hassle. I'm yet to find a good reason to switch from just using C+Lua for everything - but the Rust guys sure are trying. Maybe Rust+Lua makes the most sense, though ..
  - deleted 4y ago
    [deleted]
habibur 4y ago
"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 one is the main point. Highest possible speed while consuming as little resource as possible. Put in checks, and most of those checks will run redundantly compromising performance.
- arcticbull 4y ago
  While true, its lack of restrictions is also a hinderance in terms of performance. As pointers can overlap by default (unless you throw a __restrict on them), a whole class of optimizations cannot be performed. That's why Fortran and Rust can in theory beat C from a performance perspective even though they do more checking as a rule. That's just one example, but it's a pretty big one.
  - sanxiyn 4y ago
    "We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine." -- Fran Allen, from Coders at Work
- imglorp 4y ago
  > any safety checks put into the competing language will have a runtime cost How about all guarantees static analysis brings to data races, memory ownership, etc? No runtime cost. C tools do not bring this.
  - zik 4y ago
    The valgrind suite is a very effective answer to these needs and it's used by most C programmers. Helgrind for data races. Memcheck for memory ownership. Not to mention sophisticated tools for cache profiling, call graph analysis and heap profiling. No, they're not static tools but being dynamic has a host of advantages too.
Bayart 4y ago
If anything, "replacing C" is a good excuse to stimulate creativity. The scope is known, the land well trodden. I like seeing new things in programming languages and OS design. I like nerds having fun and giving me interesting stuff to wrap my three neurons around in the process. That's why I love computing to begin with. Not increasing productivity, not disrupting who knows what. Just cool, smart shit.
clysm 4y ago
> any safety checks put into the competing language will have a runtime cost, which often is unacceptable. And what is the runtime cost of all the mitigations put in place because we don't use a memory safe language? Stack canaries, safe stacks, ASLR, control flow integrity, code pointer integrity, runtime attestation, library re-linking and randomization. Not to mention sandboxing techniques and other system level mitigations. I suppose I should thank the C language for job security as a security engineer.
- lisper 4y ago
  And who says that faster runtime trumps all other considerations? I would much rather have my computer run slower than have to continuously deal with security vulnerabilities. My time is much more valuable than CPU time.
  - elcomet 4y ago
    That's not the point. The point the parent is making is that yes, languages that include safety features are slower, but you will actually need those safety features in C as well, in the code. So your program will also be slower in C.
    - lisper 4y ago
      Yes, I think we're actually all in agreement here. The common point is that TFA's argument that we need to keep C because it's faster is invalid. The GP's point is that it is not in fact faster because of all the things you need to do to produce code that can actually be deployed in today's world. My point is that even if C were faster (which it actually isn't) that would not matter because C is unsafe even with all the extra stuff that people stick onto it to try to make it safe. So the original claim is really a judgement call that speed matters more than safety, and this is not something about which there is any kind of consensus.
    - sitkack 4y ago
      What does slower actually mean? Slower in the face of safety, while computers continue to get faster and or cheaper (depending on how you spend your transistors/cost) is a fools paradise. Don't be baited into their flawed logic. If your transistor/cost curve has a doubling time of 3 years, 156 weeks. A 5% difference is approximately 11 weeks. If your transistor/cost curve has a doubling time of 2 years, a 5% difference is approximately 8 weeks. How fast do we have to get before safety is table stakes? Focusing on raw unsafe speed wouldn't be a normalized metric in any other industry. I'll spend 8-11 weeks of performance gains on correctness. C was an inside job.
mustache_kimono 4y ago
Wow, this blog entry's reasoning is a leaky ship. 1. C language toolchain -- No specifics (save static analyzers, ... because C needs static analyzers to catch C specific bugs...). What do you actually feel you're missing? Most of these "new C" languages use the same backend as a C compiler. What can't you use? 2., 3., and 4. -- Just chicken and egg FUD. Not to mention it's "'Better X' doesn't matter" fundamentally doesn't understand the competition. A sample quote: "That's not just one but eight(!) killer features (re: Java). How many of those unique selling points do the C alternatives have? Less than Java did at least!" WTF?! "But Java had 8!" is laughable. Another: "[A]ny safety checks put into the competing language will have a runtime cost, which often is unacceptable". We can also produce a car without windows, doors or a chassis that will survive a crash, and it may be faster too. We may even get lucky and live to tell the tale. Again: "Aside from Jai, is anyone C alternative really looking to pursue having killer features?" Aside from Jai?! Jai. Really? Oh, I remember you just discounted safety and correctness as killer features. ... But Jai. And nothing against Jai. But a language which hasn't been, which may never be, released to the general public. Just, eyes wide open, wow. I hope this is the peak of anti-Rust/pro-C silliness, but I know it's not.
- yazzku 4y ago
  I think what he's saying for (1) is that the toolchain is good compared to other languages (lots of existing tools.) I don't know why you say 2-4 is FUD.
- defen 4y ago
  > What do you actually feel you're missing? It explicitly says in the post... for example static analyzers. What is the "Frama-C" equivalent of any language that bills itself as a replacement / competitor of C? > Most of these "new C" languages use the same backend as a C compiler. Most of them use LLVM as far as I know, which does not target plenty of obscure platforms.
  - mustache_kimono 4y ago
    So the argument is we need the bug finders we've developed for C (because our C is full of bugs)? > Most of them use LLVM as far as I know, which does not target plenty of obscure platforms. Yeah, writing software in the old language is more convenient on obscure, rare, niche platforms, because it's older than dirt. More chicken and egg nonsense. It's not impossible to have LLVM add additional targets, right?
nkurz 4y ago
> And worse, what if the language omits crucial features that are present in C? Features that C advanced programmers rely on? Seems like this might be a good place to ask: which of the C replacement languages mentioned (or not mentioned) support inline assembly? Do any of them do it better than GCC/Clang? For me, I feel like the ability to drop to assembly in a pinch is a necessary feature. I'm sure I could technically get by linking an external file, but I'd be more interested in a language with inline ASM support than one that doesn't allow it. Thanks!
- cogman10 4y ago
  Pretty much all of them at this point. Rust: https://doc.rust-lang.org/nightly/reference/inline-assembly.html https://doc.rust-lang.org/nightly/reference/inline-assembly.... D: https://dlang.org/spec/iasm.html https://dlang.org/spec/iasm.html Ada: https://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn/gnat_ugn/inline_assembler.html https://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn/gnat_ug... Cobol: https://www.ibm.com/docs/en/cobol-zos/6.2?topic=appendixes-applications-cobol-assembler https://www.ibm.com/docs/en/cobol-zos/6.2?topic=appendixes-a... Pascal: https://wiki.freepascal.org/Asm https://wiki.freepascal.org/Asm Python: https://pypi.org/project/il/ https://pypi.org/project/il/ You can almost name a language and find a route to inline assembly :D
  - nkurz 4y ago
    Do you happen to know if is also true for the C replacement languages mentioned in the article: C3, Zig, Odin, Jai and eC?
    - Cyberdog 4y ago
      Zig: https://ziglang.org/documentation/master/#Assembly https://ziglang.org/documentation/master/#Assembly
    - jamesfinlayson 4y ago
      Zig seems to as well, though I haven't looked closely enough at any of them to see if the support goes beyond x86/x64 (or even ARM).
xyzsparetimexyz 4y ago
You could write a 100-line python script that compiles from your custom language to C code and it's still be better than C. There's lots of ways to re-use existing tooling and the bar really isn't that high for better languages
- sicp-enjoyer 4y ago
  Why do you think more of these projects don't take this approach? I would be 10x more likely to try one in a professional setting if I knew the portion I was taking chance on was source translation layer, and I could rely on the well tested and supported C infrastructure.
  - naniwaduni 4y ago
    It's frankly harder and/or less fun to generate C and integrate with whatever locally support C infrastructure you have than it is to BYO.
  - dmux 4y ago
    The Nim language compiles Nim source code into C as an intermediate step.
  - isaac21259 4y ago
    I was considering this for my programming language but I will most likely not use it because it makes optimisations and garbage collection harder, and the C would not be human readable (just look at the output of the chicken compiler for an example) so there's not a huge benefit. C-- could be an option but it isn't very active or well used. In terms of relying on tested and supported infrastructure lots of these projects use llvm.
cogman10 4y ago
> C language toolchain I'm sorry, but the C language toolchain is not great. The only part of the C language toolchain that is good is it's platform support. Every platform has a C compiler. However, that's hardly something most devs will care about. At this point, we are pretty much all targeting Arm or x86 (Sorry PIC and MIPS devs). And every new language that's cropped up at a minimum supports both those platforms and the major OSes for those platforms. So once you dismiss that point, what are you left with? Tools for catching memory leaks? Well, sorry, but pretty much every language has those tools and better. Particularly GCed languages. Profiling tools? Debug tools? To say the C debug tools are "good" is to say you've not used any other toolchain. But let's also point out C's horror story that is "dependency management and building". How do you grab dependencies for and build javascript? npm install, npm build. How about C? Well... are you using auto tools? Cmake? Ninja? Scion? makefiles? etc... Oh, and how do you get dependencies? Well, hope you like reading readme files and decipher cryptic "symbol not found xyz" compiler errors. Suffice it to say C's toolchain isn't anything to be proud of. It's a relic of the 70s that to this day gets in the way because the community has practically given up on the idea of fixing the glaring issues (Too hard, everything already depends on X working the way X does). So why risk switching languages? Well, because the C toolchain is a dumpster fire and you likely aren't trying to write new code for IBM RPG servers.
- User23 4y ago
  > I'm sorry, but the C language toolchain is not great. The only part of the C language toolchain that is good is it's platform support. Every platform has a C compiler. Please take a few days to review John Regehr’s excellent blog. I’m certain that you’ll find dispelling your ignorance rewarding. > How do you grab dependencies for and build javascript? npm install, npm build. Npm is the poster child for supply chain attacks.
  - cogman10 4y ago
    > Please take a few days to review John Regehr’s excellent blog. Haven't heard of him but will certainly give a read. Thanks for the heads up. > Npm is the poster child for supply chain attacks. The only reason C doesn't (often) have similar supply chain attacks is because pulling in dependencies is so hard that you aren't likely to end up with a 10k dependency project. Hard to say that's really a plus. Other ecosystems have their own problems and certainly aren't perfect. However, the toolchains are generally leaps and bounds ahead of what C currently has.
bee_rider 4y ago
Is there a "standard C" llvm target? That would maybe chip away at the "if you are working on some obscure embedded platform, C might be the only supported high level language" advantage.
- bee_rider 4y ago
  Answering my own question, but it looks like llvm-cbe is it, as far as I can tell.
gregoryc_ 4y ago
Has anyone checked out this? You can use C, but with better syntax. https://cboard.cprogramming.com/c-programming/181160-hi-i-have-created-some-work-i-think-will-really-valuable-community.html https://cboard.cprogramming.com/c-programming/181160-hi-i-ha... I'm looking for contributors. :)
- joeldo 4y ago
  Just some advice, I think you'll struggle to gain traction without putting the source onto Github, as that is generally how people contribute :)
  - gregoryc_ 4y ago
    I just made a github. https://github.com/gregoryc/EmeraldC/ https://github.com/gregoryc/EmeraldC/
AceJohnny2 4y ago
> 3. Programmer productivity > [...] Why? Because the actual programming is not the main time sink. In a business, what takes time is to actually figure out what the task really is. So something like a 10% or 20% "productivity boost" won't even register. This reminds me of Amdahl's Law [1], about how a performance optimization (parallelism) has small returns because the performance improvement only affects a small portion of the overall process. [1] https://en.wikipedia.org/wiki/Amdahl's_law https://en.wikipedia.org/wiki/Amdahl's_law
- AceJohnny2 4y ago
  Counterpoint is that a language that allows rapid iteration/prototyping (and thus, increases "programmer productivity") is useful precisely because it helps figuring out what the task really is.
  - substation13 4y ago
    100%. This annoys me so much in Java debates. The argument goes something like "It doesn't matter that Java is verbose and requires hundreds of files because the IDE generates them for you". And this is true... when you write the code. But the real friction is when you must read or change the code in response to new requirements, which is exactly what we as engineers spend the bulk of our time doing.
gregoryc_ 4y ago
The simplest solution is a preprocessor. The original founders of C made one, probably because they needed it. But adding another lightweight one is simple. C++ has bloat. Compilation time can be slow. I realize that this is radical, but if people could work with me on this, this could solve all your problems, no really, it could solve all your problems. And if it can't solve all your problems yet, then modify it to https://cboard.cprogramming.com/c-programming/181160-hi-i-have-created-some-work-i-think-will-really-valuable-community.html https://cboard.cprogramming.com/c-programming/181160-hi-i-ha... There is no need for another language. Just use this Gregory
- jitl 4y ago
  Is your thing on GitHub?
  - gregoryc_ 4y ago
    I just made a github.
  - gregoryc_ 4y ago
    https://github.com/gregoryc/EmeraldC/ https://github.com/gregoryc/EmeraldC/
woodruffw 4y ago
> 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. I don't think this is true, in the general case: Rust has shown that languages can be safe in ways that improve runtime performance. In particular, languages like Rust allow programmers to express stronger compile-time constraints on runtime behavior, meaning that the compiler can safely omit bounds and other checks that an ordinary C program would require for safety. Similarly, Rust's (lack of) mutable aliasing opens up entire classes of optimizations that are extremely difficult on C programs (to the extent that Rust regularly exposes bugs in LLVM's alias analysis, due to a lack of exercise on C/C++ inputs). Edit: Other examples include ergonomic static dispatch (Rust makes things like `foo: impl Trait` look dynamic, but they're really static under the hood) and the entire notion of a "zero-cost abstraction" (Rust's abstractions are no worse than their "as if" equivalent, meaning that the programmer is restricted in their ability to create suboptimal implementations).
- chaeronanaut 4y ago
  this pretty much summarises my opinion - one nitpick - i assume you meant "omit bounds and other checks", not "emit bounds and other checks" which seems to mean the opposite of what you're intending
  - woodruffw 4y ago
    Yes, thank you! That's an embarrassing typo! (And thanks to the other person as well, who presumably deleted the same comment after seeing yours.)
  - zozbot234 4y ago
    Rust does emit bounds and other checks, though. Optimization passes can usually clear some of them away, but you'd need to check the assembly output to be sure.
    - 4y ago
pshc 4y ago
This article is just apologism for the status quo. Nothing new here. > Memory allocation, array and string handling are often tricky, but with the right libraries and a sound memory strategy, it can be minimized. Such a handwavy deflection. Parsing strings in C is a joke and also a minefield bursting with vulnerabilities. And if you use null terminated strings (which you are, let’s face it) it’s slow.
- gregoryc_ 4y ago
  Depends on the functions used. memcpy is better than strcpy
  - pshc 4y ago
    I’m sure you meant something more along the lines of “strncpy is better than strcpy”.
    - gregoryc_ 4y ago
      memcpy is better than strncpy and strcpy ;)
    - naniwaduni 4y ago
      Nah, strncpy is pretty bad and doesn't do something anyone really expects to want. (strncpy doesn't 0-terminate when it hit max length, nor stop when it sees its first 0 in the source buffer; it acts almost entirely like memcpy except that it writes zeroes to the full length of the destination upon seeing a zero in the source. This is allegedly useful for populating fixed-sized buffers in historical Unix, and can plausibly be useful for writing out tar headers, but in practice very little code in the wild does anything observably different if you #define strncpy memcpy.)
- krater23 4y ago
  Ok, but there exists a sulotion for this. Using C++ with STL. Why we exactly need a new language?
msbarnett 4y ago
> The status of C as the lingua franca of today's computing makes it worthwhile to write tools for it, so there are many tools being written. The vast, vast majority of programmers aren’t doing their computing by writing C anymore. It’s been the better part of 20 years since you could plausibly call it the Lingua Franca of computing.
- monocasa 4y ago
  Lingua Franca in this case typically refers to the fact that you write a library with at least C ABI support if you want it to have the largest user base. Almost all languages' FFIs support some C ABI for their libraries.
jitl 4y ago
> But aside from Jai, is anyone C alternative really looking to pursue having killer features? And if it doesn't have one, how does it prove the switch from C is worth it? It can't. Zig's `zig cc` is a killer feature that doesn't even require using Zig-the-language at all. `zig cc` is an LLVM-based C compiler that gives you trivial cross-compilation for existing C codebases, adds effective caching, and can be easily installed on most operating systems with `tar -xzf`. https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
- sitkack 4y ago
  pip install ziglang python -m ziglang
- david2ndaccount 4y ago
  zig cc has enough bugs in it that I just went back to using clang on each platform.
  - dralley 4y ago
    Possibly true, but bugs can be fixed. The potential is still there.
  - flohofwoe 4y ago
    What you're seeing is most likely not bugs (it is clang after all), but the result of the much stricter default compilation settings in "zig cc" which tends to break a lot of C code that hasn't been checked against a static analyzer or ASAN before.
    - david2ndaccount 4y ago
      No, they were bugs in zig CC. They were things like linking against the wrong frameworks on macOS.
      - flohofwoe 4y ago
pkrumins 4y ago
I will never use any other language for server apps than C. C is a language for getting things done. It's finished and final. It will not change. There will be no new surprises, no new operators, and no unpublished packages. There are just source files. Write, compile, ship, repeat. You used it in 1990 to ship, you used it in 2000 to ship, you used it in 2010 to ship, you used in 2020 to ship, and you will use it in 2030 to ship. Learn once, ship forever.
- didip 4y ago
  Wait… really? Not even considering C++ Boost, Go, or Rust?
  - pkrumins 4y ago
    No. I like when nothing changes. C is perfect. All my code from 2000 still works.
- jjgreen 4y ago
  This. I know I'll never get SHOUTY DEPRECATION WARNINGS with C.
- oreally 4y ago
  Aways nice to see good reasoning. Though I'd veer away from it if the task is too large and the program needs to be updated frequently by multiple people. Also, you got any recommendations for a c library for server apps?
deleted 4y ago
[deleted]
Kukumber 4y ago
I just want: C with: - bounds checking - use after free checks - modules - sane metaprograming/template - tagged union built in without: - macro - pre declaration - split header/source That's it, no borrow checker, no weird syntax, no nothing So far D is the answser for me, but i'm worried about its future, will they keep improve the language in that direction? or will they continue with their high level stuff Zig/Jai/Odin so far are looking interesting, the problem is they all depart from the C syntax, wich is annoying, the only syntax i'd like to change is the primitive type, i32/f32/size/usize, and that's it, no need more
- steeleduncan 4y ago
  I have a similar list, but I think part the difficulty with C replacements is that the sort of people who want to go out and write a new language generally do so because they have something more radical in mind. I have pondered forking tinycc and using that as a startpoint for a more conservative set of changes like you describe. It would limit the amount of work to be done and lead to something useable quite quickly.
- valepine 4y ago
  Have you looked at C3 (the language OP is making)? I think it hits a lot of your boxes.
  - Kukumber 4y ago
    I looked at it; and i'm not really a fan of the syntax, `fn` feels out of place Also no language server is a hard pass, tooling is important
didip 4y ago
Jai is not real. It should not be mentioned even on the same sentence as Zig.
- Tozen 4y ago
  You can't say Jai is not real, because there are beta testers using it. However, there are other languages that have taken and implemented various concepts that Jai had to offer. By the time Jai comes out, and is open to the public, there might not be anything compelling about it anymore.
- dralley 4y ago
  It's real but without public access it's largely useless. I understand why Jonathan might want to avoid dealing with a peanut gallery trying to argue with him about what his language should be like, and that's fine, his language his rules and all of that. But until this situation changes it's impossible for anyone to really care about Jai.
didgetmaster 4y ago
Like any other technology that wishes to supplant the status-quo, a new programming language cannot be just 'a little bit better'. It has to be substantially better in order to overcome the inertia that the entrenched technology has established. This is true for both software and hardware. There have been plenty of leaps and bounds such as SSD speeds compared to HDD speeds; but even there, SSDs will not supplant HDDs until there is price parity between the two technologies. Until then, data will be stored on SSD when fast access is critical and on HDD when there is too much of it to justify the cost. Getting a company to switch operating systems, database vendors, or cloud providers is likewise an uphill battle. They don't call them 'walled gardens' for nothing. I am building a new data management system that I think is much better than file systems at storing and managing unstructured data and better than RDBMS at managing structured data; but I wouldn't have even dreamed of starting the project if I wasn't confident that it was at least 2x better at a minimum.
returningfory2 4y ago
> any safety checks put into the competing language will have a runtime cost, which often is unacceptable. Suppose you have bounds checks on array accesses, but your program is 100% correct and the panic case is never hit. Doesn't the branch predictor essentially make the bounds check free? Or very low cost at least?
- jstimpfle 4y ago
  If what comes after the check is a write or any other destructive operation, then the check is not so easy to mask away. I don't have actual numbers, but my gut is a strong 'no'. That said, a lot of pedestrian code that isn't running particularly hot would probably be better off including runtime checks by default.
  - pjmlp 4y ago
    It is no different from QuakeC, GOAL, and a myriad of other programming languages that game studios never had as milestone to release to the wieder public, yet they were quite usefull to their owners.
1vuio0pswjnm7 4y ago
Hypothetical: I need a small, fast systems language to use for writing small, portable programs.^1 Using the language the system is written in would be ideal. 1. In other words, the size of a "hello world" program matters, as does the storage space and time I need for the compiler toolchain and libraries. What language should I use. I am not interested in writing large, complex programs.
flohofwoe 4y ago
What a defeatist take :/ A "better C" language doesn't have to "win the popularity race" to be useful, it just needs to (a) be easy to learn coming from C, (b) integrate well into the existing C/C++/ObjC ecosystem, and (c) easy to install and across all supported platforms. A "better C" cannot and should not replace C for all use cases, but it should at least augment C by fixing its design wart. The actually depressing thing is the "winner takes all" mentality though that seems to be prelevant in the programming world.
- AndyKelley 4y ago
  This person is actively trying to make a "better C" so it's no surprise his arguments against his own project are lukewarm. "It is difficult to get a man to understand something, when his salary depends on his not understanding it."
  - jstimpfle 4y ago
    Why do you put that quote? I'm not sure anybody "tried to get him understand it". I suppose the post comes mostly because of what the author learned or concluded from his own project. There might be other motivations. I think the post has some genuinely good points that need to get more mindshare.
oconnor663 4y ago
> This leads to a strategy of only having checks in "safe" mode. Where the "fast" mode is just as "unsafe" as C. This is hard to describe without getting deep into Rust details, but I think the ability to encapsulate unsafe code in safe APIs is just as important as what pure safe code can do. (Of course those two things end up being intimately related.)
rcarmo 4y ago
I still occasionally write C (and C++), but have come to appreciate the sparseness of Go (although not the intricate abstractions of Rust) and keep wondering if Zig (which does cross-compilation almost as effortlessly as Go) shouldn’t be more popular. In the end, though, you can accomplish the same (from an outcome perspective, not necessarily from a satisfactory one) in all of them, so I try not to be overly biased, although convenience vs correctness seem to be the main issues at play here. (Edit: why the downvotes? Is Zig out of favor? Is it because this may read as a slight on Rust?)
- voidhorse 4y ago
  I like Zig a lot and think it hits precisely the right niche for a C replacement. Rust is a great language, but it’s definitely not C like when it comes to the overall UI and philosophy. I’d like to use Zig a bit more, but the standard library is still going through some significant changes (it seems) which makes it slightly harder to commit to at the moment. In general I wonder if some of these languages would actually benefit from Jai’s approach of deferring availability until the language is ready. While getting early adopters is great for getting feedback early, it can also disuade potential users that try the language before its ready and decide to leave it alone as a result.
naniwaduni 4y ago
An oft-overlooked pain point is that when interacting with C interfaces, it's not good enough to implement a C ABI FFI. There's a world of software out there where the supporrted interface is a C API, at the source level. Compatibility across different versions, or across different implementations, is assured only to programs which interact with the interfaces in ways that correspond particular C source patterns. The biggest culprit I've met on this front is the POSIX stat family of functions.
mlindner 4y ago
> Looking at C++ alternatives there are languages like D, Rust, Nim, Crystal, Beef, Carbon and others. Why do people keep lumping Rust into the category of a "C++ alternative". Rust is a C alternative and can be used places that C can but C++ cannot. i.e the linux kernal and baremetal silicon (C++ can be used in the embedded but I've never heard of it being used without modification for that environment). > My language (C3) is fairly recent, there are others: Zig, Odin, Jai and older languages like eC. Further he seems to claim that Jai is a C alternative when it's explicitly described by it's creator as a C++ alternative.
robalni 4y ago
The problem with making a new language is that it seems like people do it because they want to make a new language. Don't make a new language just to make a new language. Do it because you are solving a problem by doing it, and if you are solving a problem, you already win regardless of how many people will use the language. Have the problem before you make the solution. > It turns out that people don't always agree on what the pain points with C is. People have different problems so they should probably use different languages. Don't even try to make a language that will solve everyone's problems. > Also, while the company has experience recruiting for C developers, it doesn't know how to recruit for this new language. If the language is so hard that people have to have special knowledge to use it and can't learn it quickly then it's probably not a good language. > For a business it's whether despite the downsides the language can help the bottom line: "Is this valuable enough to outweigh the downsides?" Exactly, it's solving real problems that matters. > The "build it and they will come" idea is tempting to believe in A better idea is "build it and we will come because we need it. Then maybe other people will come if they need it too."
deleted 4y ago
[deleted]
Cryptonic 4y ago
Written by someone who does not know about / does not understand compilietime safety guarantees
bowsamic 4y ago
The momentum of C seems so vast that replacing it is like getting humans to switch to a base-12 number system
- qayxc 4y ago
  That's a weird analogy considering humans used base-12 (and base-20 and base-60) number systems for most of history.
  - bowsamic 4y ago
    Really? Wikipedia says it is historically uncommon EDIT: What language uses base-60??
    - jstimpfle 4y ago
      Minutes in an hour, seconds in a minute, and something about degrees.
    - Qem 4y ago
      Babylonians used it. That's the origin of our time counting system of hours, minutes and seconds and our angle measuring system of degrees, minutes and seconds. Anyway, if we someday change our number system away from 10, I hope the change will be towards a smaller base, like 8 or 6, because when one is a child, it sucks to learn the times tables. Base 12 would increase the number of entries by 44%. Base 8 would decrease them by 46%, and base 6 would have only 6*6=36 very easy to remember entries.
      - bowsamic 4y ago
        That's not a pure number system though, because it didn't have a separate character for each digit
        Qem 4y ago
        In cuneiform they probably had.
jokoon 4y ago
Finally an article I can agree with. C is great mostly because it's easy to learn, and it has many other advantages. I dislike all those new languages because they have too many features, and they're non trivial to learn. I've looked at some rust codebases and I don't think there will be a lot of people who will want to maintain them. Rust is difficult, even though it's an awesome language. A language that could compete with C would: * Be fast to compile * Have some quality of life things you can find in the C++ STL: map, string, etc * Look a lot like C, meaning it would not try to innovate too much. To summarize, it would be a lighter version of C++.
- bruce343434 4y ago
  Go?
  - voidhorse 4y ago
    Actually, yes. Go does a lot of the things everyone seems to want in these C replacements, the problem is that it has GC which, to a lot of people, automatically disqualifies it as an option for writing certain kinds of software you can write with manual memory management. A lot of people also tend to think they need manual memory management for $reasons when GC is actually fine.
  - jokoon 4y ago
    without a GC
    - xigoi 4y ago
      Zig? Odin?
- xigoi 4y ago
  > easy to learn What exactly do you mean? Learn the basics? Become productive? Memorize the entire specification? I'd argue C isn't significantly faster at any of these than most other languages.
  - 4y ago
outsomnia 4y ago
There is also a more general "case against the self-indulgent narcissism in creating a new language". There are an insane number of languages with the longevity of a mushroom mentioned on HN.
- abnercoimbre 4y ago
  Heh. This article was posted shortly after we instituted a ban [0] on language talks at Handmade Seattle 2022. There's an oversupply of enthusiastic engineers trying to provide C alternatives and it's creating massive bike-shedding and yak-shaving problems. Language designers are encouraged to give a presentation if it's about building quality software using a language. Otherwise, no. [0] https://vimeo.com/handmadeseattle/languages-are-banned https://vimeo.com/handmadeseattle/languages-are-banned
0xbeefeed 4y ago
Here comes the Rust brigade…
badpun 4y ago
Honestly, I hate includes and preprocessor directives so much that any "better C" variant which replaces them with more modern solutions would probably be enough in my book - with the caveat being that I also like having an IDE very much and wouldn't want to revert to coding in something like emacs with plugins. BTW, C++20 has a good replacement for includes (modules), but IDE support is not there yet and thus it's not usable for me.
- jstimpfle 4y ago
  I wholeheartedly agree, the speed of processing includes annoys me most about C. The sad part is that the mainstream alternatives that I have on the radar are _even slower_ to build. And usage of the preprocessor in APIs is allowing for good things, at least for a compiled systems language like C: Macros allow to get rid of boilerplate on the syntax level and if-defs allow for compatibility. Both points' significance is reduced a long way in other languages, because they have stronger facilities for abstraction, BUT this abstraction comes at a non-significant price and cannot replace all significant uses of the preprocessor. So I'm still stuck with C. The solution is designing header files carefully, resulting in build times that are lightning fast, at least in relation to most other mainstream languages. And there is always the option to go for "unity" builds.
  - badpun 4y ago
    What bother me most is not even the speed of compilation (although it's a major pain too), but the fact that I need to create a header file for every .c file I want to have used from outside it's compilation unit, and add method declarations in it. In 2022 it's SO BACKWARDS it hurts.
    - jstimpfle 4y ago
      I almost never found that painful. Maybe a couple things that help: 1) Improve modularization. APIs should be small (as a rule). 2) Don't write a new file for each "class". It's not a problem to have files with more than 1 KLOC. But it is problematic to have a lot of really small files, as is (I think) customary with say Java.
pornel 4y ago
> No experienced developers Whenever a CVE is discussed, even if the code was from Google, Microsoft, or Apple, commenters immediately point out that these companies must have hired some "bad programmers", because a "good programmer" wouldn't have made such mistake. Given that even top software companies continue producing CVEs on a regular basis, there is a shortage of people capable of writing C. A lot of programming skills are transferable (algorithms, architecture, system APIs, debugging), so you don't really need to hire "language X programmer".
bullen 4y ago
I came to the same conclusion last year: C (client) and Java (server) are the final languages. To fragment the industry with more languages is a hidden cost that wont end well for anyone. KWh is approaching $1, prepare by choosing the proper languages.
brhsagain 4y ago
> First of all, pretty much all languages ever will make vacuous claims of "higher programmer productivity". The problem is that for a business this usually doesn't matter. Why? Because the actual programming is not the main time sink. In a business, what takes time is to actually figure out what the task really is. So something like a 10% or 20% "productivity boost" won't even register. A 100% increase in productivity might show, but even that isn't guaranteed. I stopped reading here. This is like saying typing speed doesn't matter because most of your time is spent thinking about what to type. If your argument basically evaluates to saying that it doesn't matter how productive you are while doing the actual activity of your job itself... at some point it's like, I dunno, do you actually believe what you're saying? Also, not to go off on too unrelated/unhinged a tangent, but, I've also started noticing in the last five years this widespread fear of actually sitting down and programming. There's a weird meta-culture where people want to do anything but sit down and write code, because it's hard and scary. I hear arguments made all the time for how important everything is — aligning stakeholders, scoping tasks, communication, mentoring juniors, soft skills, whatever. Everything except writing the actual code, which is somehow a mere technical triviality that anyone can do, or something.
- jstimpfle 4y ago
  The point is "marginal costs from switching languages may outweigh any benefits in plain programming productivity".
- doctor_eval 4y ago
  Right? Productivity makes thinking easier. It’s part of a virtuous cycle.
- dgb23 4y ago
  I agree especially with that last point. There is something about programming that is very difficult. It gets _more_ difficult if you write complex things, but that's not the essence of it. I think it has something to do with raw concentration. We have all of these tools that help us to write code while making few mistakes. From constrained DSLs/configuration languages, schemas, static typing to automated tests etc. But in the end we still have to exert all that energy to sit down, focus and do the coding. Meetings, design, coordination etc. All of those things are important, and they can be exhausting in their own way. But programming is by far the most challenging, hour per hour (pound for pound). Making all of these micro decisions, think about the impact of your code, the readability, the correctness. It is _at least_ two times harder and more draining than anything else I do, even when I'm in a flow state and the actual work is fun, more fun than all of the other tasks. And I agree: It is the most important thing. I mean all of the other stuff is basically there to support the core task that solves your problems: producing working software (except if it isn't but then you have political problems). There are seemingly infinite dimensions for improvement as well, tradeoffs such as performance, efficiency, robustness, usability, leverage, creativity...
chriswarbo 4y ago
> any safety checks put into the competing language will have a runtime cost, which often is unacceptable This is completely wrong. The best counterexample is probably ATS http://www.ats-lang.org http://www.ats-lang.org which is compatible with C, yet also features dependent types (allowing us to prove arbitrary statements about our programs, and check them at compile time) and linear type (allowing us to precisely track resource usage; similar to Rust) A good example is http://ats-lang.sourceforge.net/DOCUMENT/ATS2CAIRO/HTML/c36.html http://ats-lang.sourceforge.net/DOCUMENT/ATS2CAIRO/HTML/c36.... which uses the Cairo graphics library, and ends with the following: > It may seem that using cairo functions in ATS is nearly identical to using them in C (modulo syntatical difference). However, what happens at the level of typechecking in ATS is far more sophisticated than in C. In particular, linear types are assigned to cairo objects (such as contexts, surfaces, patterns, font faces, etc.) in ATS to allow them to be tracked statically, that is, at compile-time, preventing potential mismanagement of such objects. For instance, if the following line: val () = cairo_surface_destroy (sf) // a type error if omitted > is removed from the program in tutprog_hello.dats, then a type-error message is issued at compile-time to indicate that the resource sf is not properly freed. A message as such can be of great value in practice for correcting potential memory leaks that may otherwise readily go unnoticed. ATS is a programming language that distinguishes itself in its practical and effective support for precise resource management.
manholio 4y ago
Rust is not only a C++ alternative, it's a C alternative too. You don't have to have methods in your structs or use generics, traits, closures, interators etc. You won't be able to use the standard library, but it's doable.
sylware 4y ago
C has already a syntax way too rich. ISO should fix and remove from the syntax. Yes, break backward compatibility starting from "c24". Let's go in a fantasy world where we have a B+ language which should have been C: remove typedef/_generic/typeof/restrict/enum/etc, well all those horrible things. Only one loop statement, loop {}, no switch ofc. Only sized/signed core types with properly sized/signed literals: ub/sb or u8/s8 with integer literals like 123ub/123sb, sw/sd..., udw/sdw... , uqw/sqw..., fdw/1.23fdw (f32), fqw/1.23fqw (f64) (for some hardware ymm/xmm/zmm with fancy literals, sorry I am not aware of the fine details of the C/CPP lexer). Ofc, no integer promotion and no implicit cast (void* would still not require any cast). Compile-time and runtime cast (not like with that horrible c++ syntax), same thing for consts (even though nowadays it is the the compiler which detects real compile-time constants), yes you may have to "static const" your literals. Oh, and for the C preprocessor, do fix that variadic-args function-like macro for good (I wonder if gcc the way is not better than c++ ISO way). Without all that, it should be "reasonable" for a small team of average-skilled or an individual to write a naive compiler until they don't forget they can hit a goto at any line. And they are those who say "but feature A is cheap to implement"... 1 million cheap features later... well, you get the picture. The really hard part for ISO was to keep C actually "cheap" to implement, this is where they are failing hard. As for the gcc extension based C dialect for kernel developement, no salvation here, C is really too alien (or even B+). Namely the little ISA abstraction is not "enough", so either the kernel goes full "slow" with plain C and assembly (_not_ inline assembly ofc), or full assembly on all of its fast-paths which would require proper binary defined specs (I am currently researching how bad this could be). I do believe the open source communities have the strength to maintain parallel assembly _significant_ code bases (which do the same thing), big monolithic corpos... not so sure...
tpoacher 4y ago
After many years in this field, I am convinced we don't need a better "C" at all. We need better "C education".
- selfmodruntime 4y ago
  I tend to disagree at this notion. I've used C for almost a decade now and I've seen many developers who were far more talented than me make similar mistakes all the time. Some problems require solutions which are unable to be solved in C in a safe way.
xorvoid 4y ago
The article misses a really big item. I’ve programmed in C for 20+ years and then recently switched to rust. When fellow C programmers ask me how Rust is going, I say “it’s modern” and “it’s consistent”. What I mean by that unlike C, Rust doesn’t have 50 years of baggage: string functions that handle null termination all differently, complicated implicit promotion rules, null-terminated strings that haven’t been a good idea for decades, apis that we’re completely busted by posix threads but still exist, functions that cannot be used safely that still exist, code snippet examples with horribly broken unsafe code that beginners copy-paste, dubious and bad type-based aliasing, rampant use of UB, etc etc etc Sadly Rust is not a better C. Maybe it’ll grow into one some day. Today it’s a better C++. Sadly I’d still chose C to do C’s job. All I want from “better C” is to fix the obviously bad problems from C’s history. Or rather, maybe that’s the committee’s job. At any rate: it’s embarrassing that we’re still so dependent on a language that’s so broken. And it’s sad that there doesn’t seem to be a path forward.
- mtlmtlmtlmtl 4y ago
  When I discovered strsep was a thing I was genuinely a bit mad that I'd been "tricked" into using strtok all this time. Since then I never just look up a function in the standard library reference. It's a fair chance its API is far from ideal, especially in string.h
- kaba0 4y ago
  What is C’s job, when would you use it for a green field project? Not trying to start a flame war, genuinely curious as I see less and less need for C, other than maintaining all those existing code bases.
  - cartoonfoxes 4y ago
    When working with the huge amounts of embedded silicon that is supported by C libraries and toolchains only.

217 points by lerno 4y ago

Well argued. Lots of things factored in.

imachine1980_ 4y ago

the only better c that will count is if c add some features that are critical like a standard library that is more powerful i know c++ 17 have some improvements but need alternatives for most things is not good for the ecosystem, and the old only if you want, is 2022 most embedded system use this tools, we need c to have a reasonable standard library, the whole world depend on it.

gregoryc_ 4y ago
Check out https://cboard.cprogramming.com/c-programming/181160-hi-i-have-created-some-work-i-think-will-really-valuable-community.html https://cboard.cprogramming.com/c-programming/181160-hi-i-ha... I posted this less than 24 hours ago. This might be what you want, and there's no overhead at all. It might actually speed up your code. 15x faster regex I just made this. I'm looking for contributors :)

TAForObvReasons 4y ago

(4) is extremely important. Labor pool is smaller and there won't be a wealth of soft documentation and people that can provide immediate support for common questions.

nicoburns 4y ago
It is, on the other hand it's a lot of easier to write correct code in, well, almost every language other than C. To give a concrete example, I was able to write production-ready code with 2 weeks of Rust experience and nobody to provide support for questions (beyond reading StackOverflow), and that code was more reliable and less buggy then the Python/JavaScript code our company was otherwise writing, even though we were collectively much more experienced in those stacks. I doubt we'd have gotten that with C, even though we had a bunch of developers who were experienced with C.
- FpUser 4y ago
  And I wrote a firmware in C for 4-quadrant torque control in about the same time. I do not have any formal proof on how buggy/or not it is but the thing runs properly for 10 years already. If that is not "production code" I do not know what is. I am not inexperienced programmer. Rather quite opposite. But this was after I did not touch C and any microcontrollers for like 10 years.
  - nicoburns 4y ago
    I feel like C is somewhat manageable on microcontrollers. Programs tend to be smaller (micro!), you can often do static allocation which mitigates a lot of the memory management issues, and you're also often dealing with simple types and bit manipulation which is where C shines. In larger programs on full-fat operating systems, programs tend to be much larger (esp. if you include libraries - dealing with libraries being one of the most complex things in C), and you have to deal with sophisticated allocation patterns, and complex types (webs of pointers), abstractions and business logic which is where C basically leaves you on your own and provides very little in terms of structure or guard rails.
    - voidhorse 4y ago
      This is how I’ve started to think about things too. If every program was authored by a single individual and was relatively small, C would already be the perfect programming language. All the advanced safety features of competitors really only become relevant once you introduce scale.
    - FpUser 4y ago
      Generally I agree with everything you say. Each tool has areas where it shines and the opposite. One of the reasons I use multiple languages.

arcticbull 4y ago

(5) is pretty irrelevant, ABI isn't language. You can strap basically any language on top of the C ABI. Many contender languages either use it natively or offer low-cost/no-cost C ABI bindings, specifically as its the lingua franca ABI. You can check (5) off your list if your choice of replacement language has easy C ABI interop. [edit] (1) isn't particularly relevant either. These days the tooling for detecting memory leaks, data races, bugs, etc, operates at the debug info (DAWRF/dSYM) level. It doesn't matter what compiler or input language generated the debugging information, the tools should work just fine. You can run valgrind on your Rust binary for instance. [1] Is there any such tooling that specifically depends on the input source being C? I guess some static analysis tools? [1] https://nnethercote.github.io/2022/01/05/rust-and-valgrind.html https://nnethercote.github.io/2022/01/05/rust-and-valgrind.h...

AceJohnny2 4y ago
Yeah, I'm also confused by this. A platform will define an ABI which, as I understand it, explains how parameters are passed to and returned from a "function", what types are supported and how they're encoded, at the processor register and stack level. C, being the "portable assembler" [1] that it is, maps its types and functions pretty easily to that platform ABI, but I've been seeing a fair amount of confusion about that ABI being about C rather than any language that can link through that platform ABI. Couldn't it just as easily be called, I dunno, the Ada ABI? [1] not really, except for the sake of this argument
deleted 4y ago
[deleted]
yazzku 4y ago
Why is this down-voted? C does not have a standard ABI, this guy here is right?
- deleted 4y ago
  [deleted]

omgmajk 4y ago

I agree with most things in this article really, but then again, handmade.network has some quality in it overall.

yazzku 4y ago

Next: the case against Cloudflare-gated websites.

intelVISA 4y ago
you don't enjoy having half of the Internet MitM'd?
- yazzku 4y ago
  More than you can possibly imagine.

jhatemyjob 4y ago

Ive been thinking about this topic for years and OP was finally able to put it in writing. I dont think anyone would claim english is the best, but it just so happens that the most powerful empire on earth (until recently?) uses it as its primary language. Its good enough at what it does, and has a lot of history backing it up With this knowledge I choose to align myself with languages and platforms that respect C and complement it (Lua, Objective-C, etc) instead of languages and platforms that try to supplant it (c++, java, swift, rust, etc)

boffinAudio 4y ago
I concur with you - everything I want to do in Rust or Golang, I can do with C+Lua just as easily and with far less tooling hassle. I'm yet to find a good reason to switch from just using C+Lua for everything - but the Rust guys sure are trying. Maybe Rust+Lua makes the most sense, though ..
- deleted 4y ago
  [deleted]

habibur 4y ago

"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 one is the main point. Highest possible speed while consuming as little resource as possible. Put in checks, and most of those checks will run redundantly compromising performance.

arcticbull 4y ago
While true, its lack of restrictions is also a hinderance in terms of performance. As pointers can overlap by default (unless you throw a __restrict on them), a whole class of optimizations cannot be performed. That's why Fortran and Rust can in theory beat C from a performance perspective even though they do more checking as a rule. That's just one example, but it's a pretty big one.
- sanxiyn 4y ago
  "We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine." -- Fran Allen, from Coders at Work
imglorp 4y ago
> any safety checks put into the competing language will have a runtime cost How about all guarantees static analysis brings to data races, memory ownership, etc? No runtime cost. C tools do not bring this.
- zik 4y ago
  The valgrind suite is a very effective answer to these needs and it's used by most C programmers. Helgrind for data races. Memcheck for memory ownership. Not to mention sophisticated tools for cache profiling, call graph analysis and heap profiling. No, they're not static tools but being dynamic has a host of advantages too.

Bayart 4y ago

If anything, "replacing C" is a good excuse to stimulate creativity. The scope is known, the land well trodden. I like seeing new things in programming languages and OS design. I like nerds having fun and giving me interesting stuff to wrap my three neurons around in the process. That's why I love computing to begin with. Not increasing productivity, not disrupting who knows what. Just cool, smart shit.

clysm 4y ago

> any safety checks put into the competing language will have a runtime cost, which often is unacceptable. And what is the runtime cost of all the mitigations put in place because we don't use a memory safe language? Stack canaries, safe stacks, ASLR, control flow integrity, code pointer integrity, runtime attestation, library re-linking and randomization. Not to mention sandboxing techniques and other system level mitigations. I suppose I should thank the C language for job security as a security engineer.

lisper 4y ago
And who says that faster runtime trumps all other considerations? I would much rather have my computer run slower than have to continuously deal with security vulnerabilities. My time is much more valuable than CPU time.
- elcomet 4y ago
  That's not the point. The point the parent is making is that yes, languages that include safety features are slower, but you will actually need those safety features in C as well, in the code. So your program will also be slower in C.
  - lisper 4y ago
    Yes, I think we're actually all in agreement here. The common point is that TFA's argument that we need to keep C because it's faster is invalid. The GP's point is that it is not in fact faster because of all the things you need to do to produce code that can actually be deployed in today's world. My point is that even if C were faster (which it actually isn't) that would not matter because C is unsafe even with all the extra stuff that people stick onto it to try to make it safe. So the original claim is really a judgement call that speed matters more than safety, and this is not something about which there is any kind of consensus.
  - sitkack 4y ago
    What does slower actually mean? Slower in the face of safety, while computers continue to get faster and or cheaper (depending on how you spend your transistors/cost) is a fools paradise. Don't be baited into their flawed logic. If your transistor/cost curve has a doubling time of 3 years, 156 weeks. A 5% difference is approximately 11 weeks. If your transistor/cost curve has a doubling time of 2 years, a 5% difference is approximately 8 weeks. How fast do we have to get before safety is table stakes? Focusing on raw unsafe speed wouldn't be a normalized metric in any other industry. I'll spend 8-11 weeks of performance gains on correctness. C was an inside job.

mustache_kimono 4y ago

Wow, this blog entry's reasoning is a leaky ship. 1. C language toolchain -- No specifics (save static analyzers, ... because C needs static analyzers to catch C specific bugs...). What do you actually feel you're missing? Most of these "new C" languages use the same backend as a C compiler. What can't you use? 2., 3., and 4. -- Just chicken and egg FUD. Not to mention it's "'Better X' doesn't matter" fundamentally doesn't understand the competition. A sample quote: "That's not just one but eight(!) killer features (re: Java). How many of those unique selling points do the C alternatives have? Less than Java did at least!" WTF?! "But Java had 8!" is laughable. Another: "[A]ny safety checks put into the competing language will have a runtime cost, which often is unacceptable". We can also produce a car without windows, doors or a chassis that will survive a crash, and it may be faster too. We may even get lucky and live to tell the tale. Again: "Aside from Jai, is anyone C alternative really looking to pursue having killer features?" Aside from Jai?! Jai. Really? Oh, I remember you just discounted safety and correctness as killer features. ... But Jai. And nothing against Jai. But a language which hasn't been, which may never be, released to the general public. Just, eyes wide open, wow. I hope this is the peak of anti-Rust/pro-C silliness, but I know it's not.

yazzku 4y ago
I think what he's saying for (1) is that the toolchain is good compared to other languages (lots of existing tools.) I don't know why you say 2-4 is FUD.
defen 4y ago
> What do you actually feel you're missing? It explicitly says in the post... for example static analyzers. What is the "Frama-C" equivalent of any language that bills itself as a replacement / competitor of C? > Most of these "new C" languages use the same backend as a C compiler. Most of them use LLVM as far as I know, which does not target plenty of obscure platforms.
- mustache_kimono 4y ago
  So the argument is we need the bug finders we've developed for C (because our C is full of bugs)? > Most of them use LLVM as far as I know, which does not target plenty of obscure platforms. Yeah, writing software in the old language is more convenient on obscure, rare, niche platforms, because it's older than dirt. More chicken and egg nonsense. It's not impossible to have LLVM add additional targets, right?

nkurz 4y ago

> And worse, what if the language omits crucial features that are present in C? Features that C advanced programmers rely on? Seems like this might be a good place to ask: which of the C replacement languages mentioned (or not mentioned) support inline assembly? Do any of them do it better than GCC/Clang? For me, I feel like the ability to drop to assembly in a pinch is a necessary feature. I'm sure I could technically get by linking an external file, but I'd be more interested in a language with inline ASM support than one that doesn't allow it. Thanks!

cogman10 4y ago
Pretty much all of them at this point. Rust: https://doc.rust-lang.org/nightly/reference/inline-assembly.html https://doc.rust-lang.org/nightly/reference/inline-assembly.... D: https://dlang.org/spec/iasm.html https://dlang.org/spec/iasm.html Ada: https://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn/gnat_ugn/inline_assembler.html https://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn/gnat_ug... Cobol: https://www.ibm.com/docs/en/cobol-zos/6.2?topic=appendixes-applications-cobol-assembler https://www.ibm.com/docs/en/cobol-zos/6.2?topic=appendixes-a... Pascal: https://wiki.freepascal.org/Asm https://wiki.freepascal.org/Asm Python: https://pypi.org/project/il/ https://pypi.org/project/il/ You can almost name a language and find a route to inline assembly :D
- nkurz 4y ago
  Do you happen to know if is also true for the C replacement languages mentioned in the article: C3, Zig, Odin, Jai and eC?
  - Cyberdog 4y ago
    Zig: https://ziglang.org/documentation/master/#Assembly https://ziglang.org/documentation/master/#Assembly
  - jamesfinlayson 4y ago
    Zig seems to as well, though I haven't looked closely enough at any of them to see if the support goes beyond x86/x64 (or even ARM).

xyzsparetimexyz 4y ago

You could write a 100-line python script that compiles from your custom language to C code and it's still be better than C. There's lots of ways to re-use existing tooling and the bar really isn't that high for better languages

sicp-enjoyer 4y ago
Why do you think more of these projects don't take this approach? I would be 10x more likely to try one in a professional setting if I knew the portion I was taking chance on was source translation layer, and I could rely on the well tested and supported C infrastructure.
- naniwaduni 4y ago
  It's frankly harder and/or less fun to generate C and integrate with whatever locally support C infrastructure you have than it is to BYO.
- dmux 4y ago
  The Nim language compiles Nim source code into C as an intermediate step.
- isaac21259 4y ago
  I was considering this for my programming language but I will most likely not use it because it makes optimisations and garbage collection harder, and the C would not be human readable (just look at the output of the chicken compiler for an example) so there's not a huge benefit. C-- could be an option but it isn't very active or well used. In terms of relying on tested and supported infrastructure lots of these projects use llvm.

cogman10 4y ago

> C language toolchain I'm sorry, but the C language toolchain is not great. The only part of the C language toolchain that is good is it's platform support. Every platform has a C compiler. However, that's hardly something most devs will care about. At this point, we are pretty much all targeting Arm or x86 (Sorry PIC and MIPS devs). And every new language that's cropped up at a minimum supports both those platforms and the major OSes for those platforms. So once you dismiss that point, what are you left with? Tools for catching memory leaks? Well, sorry, but pretty much every language has those tools and better. Particularly GCed languages. Profiling tools? Debug tools? To say the C debug tools are "good" is to say you've not used any other toolchain. But let's also point out C's horror story that is "dependency management and building". How do you grab dependencies for and build javascript? npm install, npm build. How about C? Well... are you using auto tools? Cmake? Ninja? Scion? makefiles? etc... Oh, and how do you get dependencies? Well, hope you like reading readme files and decipher cryptic "symbol not found xyz" compiler errors. Suffice it to say C's toolchain isn't anything to be proud of. It's a relic of the 70s that to this day gets in the way because the community has practically given up on the idea of fixing the glaring issues (Too hard, everything already depends on X working the way X does). So why risk switching languages? Well, because the C toolchain is a dumpster fire and you likely aren't trying to write new code for IBM RPG servers.

User23 4y ago
> I'm sorry, but the C language toolchain is not great. The only part of the C language toolchain that is good is it's platform support. Every platform has a C compiler. Please take a few days to review John Regehr’s excellent blog. I’m certain that you’ll find dispelling your ignorance rewarding. > How do you grab dependencies for and build javascript? npm install, npm build. Npm is the poster child for supply chain attacks.
- cogman10 4y ago
  > Please take a few days to review John Regehr’s excellent blog. Haven't heard of him but will certainly give a read. Thanks for the heads up. > Npm is the poster child for supply chain attacks. The only reason C doesn't (often) have similar supply chain attacks is because pulling in dependencies is so hard that you aren't likely to end up with a 10k dependency project. Hard to say that's really a plus. Other ecosystems have their own problems and certainly aren't perfect. However, the toolchains are generally leaps and bounds ahead of what C currently has.

bee_rider 4y ago

Is there a "standard C" llvm target? That would maybe chip away at the "if you are working on some obscure embedded platform, C might be the only supported high level language" advantage.

bee_rider 4y ago
Answering my own question, but it looks like llvm-cbe is it, as far as I can tell.

gregoryc_ 4y ago

Has anyone checked out this? You can use C, but with better syntax. https://cboard.cprogramming.com/c-programming/181160-hi-i-have-created-some-work-i-think-will-really-valuable-community.html https://cboard.cprogramming.com/c-programming/181160-hi-i-ha... I'm looking for contributors. :)

joeldo 4y ago
Just some advice, I think you'll struggle to gain traction without putting the source onto Github, as that is generally how people contribute :)
- gregoryc_ 4y ago
  I just made a github. https://github.com/gregoryc/EmeraldC/ https://github.com/gregoryc/EmeraldC/

AceJohnny2 4y ago

> 3. Programmer productivity > [...] Why? Because the actual programming is not the main time sink. In a business, what takes time is to actually figure out what the task really is. So something like a 10% or 20% "productivity boost" won't even register. This reminds me of Amdahl's Law [1], about how a performance optimization (parallelism) has small returns because the performance improvement only affects a small portion of the overall process. [1] https://en.wikipedia.org/wiki/Amdahl's_law https://en.wikipedia.org/wiki/Amdahl's_law

AceJohnny2 4y ago
Counterpoint is that a language that allows rapid iteration/prototyping (and thus, increases "programmer productivity") is useful precisely because it helps figuring out what the task really is.
- substation13 4y ago
  100%. This annoys me so much in Java debates. The argument goes something like "It doesn't matter that Java is verbose and requires hundreds of files because the IDE generates them for you". And this is true... when you write the code. But the real friction is when you must read or change the code in response to new requirements, which is exactly what we as engineers spend the bulk of our time doing.

gregoryc_ 4y ago

The simplest solution is a preprocessor. The original founders of C made one, probably because they needed it. But adding another lightweight one is simple. C++ has bloat. Compilation time can be slow. I realize that this is radical, but if people could work with me on this, this could solve all your problems, no really, it could solve all your problems. And if it can't solve all your problems yet, then modify it to https://cboard.cprogramming.com/c-programming/181160-hi-i-have-created-some-work-i-think-will-really-valuable-community.html https://cboard.cprogramming.com/c-programming/181160-hi-i-ha... There is no need for another language. Just use this Gregory

jitl 4y ago
Is your thing on GitHub?
- gregoryc_ 4y ago
  I just made a github.
- gregoryc_ 4y ago
  https://github.com/gregoryc/EmeraldC/ https://github.com/gregoryc/EmeraldC/

woodruffw 4y ago

> 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. I don't think this is true, in the general case: Rust has shown that languages can be safe in ways that improve runtime performance. In particular, languages like Rust allow programmers to express stronger compile-time constraints on runtime behavior, meaning that the compiler can safely omit bounds and other checks that an ordinary C program would require for safety. Similarly, Rust's (lack of) mutable aliasing opens up entire classes of optimizations that are extremely difficult on C programs (to the extent that Rust regularly exposes bugs in LLVM's alias analysis, due to a lack of exercise on C/C++ inputs). Edit: Other examples include ergonomic static dispatch (Rust makes things like `foo: impl Trait` look dynamic, but they're really static under the hood) and the entire notion of a "zero-cost abstraction" (Rust's abstractions are no worse than their "as if" equivalent, meaning that the programmer is restricted in their ability to create suboptimal implementations).

chaeronanaut 4y ago
this pretty much summarises my opinion - one nitpick - i assume you meant "omit bounds and other checks", not "emit bounds and other checks" which seems to mean the opposite of what you're intending
- woodruffw 4y ago
  Yes, thank you! That's an embarrassing typo! (And thanks to the other person as well, who presumably deleted the same comment after seeing yours.)
- zozbot234 4y ago
  Rust does emit bounds and other checks, though. Optimization passes can usually clear some of them away, but you'd need to check the assembly output to be sure.
  - 4y ago

pshc 4y ago

This article is just apologism for the status quo. Nothing new here. > Memory allocation, array and string handling are often tricky, but with the right libraries and a sound memory strategy, it can be minimized. Such a handwavy deflection. Parsing strings in C is a joke and also a minefield bursting with vulnerabilities. And if you use null terminated strings (which you are, let’s face it) it’s slow.

gregoryc_ 4y ago
Depends on the functions used. memcpy is better than strcpy
- pshc 4y ago
  I’m sure you meant something more along the lines of “strncpy is better than strcpy”.
  - gregoryc_ 4y ago
    memcpy is better than strncpy and strcpy ;)
  - naniwaduni 4y ago
    Nah, strncpy is pretty bad and doesn't do something anyone really expects to want. (strncpy doesn't 0-terminate when it hit max length, nor stop when it sees its first 0 in the source buffer; it acts almost entirely like memcpy except that it writes zeroes to the full length of the destination upon seeing a zero in the source. This is allegedly useful for populating fixed-sized buffers in historical Unix, and can plausibly be useful for writing out tar headers, but in practice very little code in the wild does anything observably different if you #define strncpy memcpy.)
krater23 4y ago
Ok, but there exists a sulotion for this. Using C++ with STL. Why we exactly need a new language?

msbarnett 4y ago

> The status of C as the lingua franca of today's computing makes it worthwhile to write tools for it, so there are many tools being written. The vast, vast majority of programmers aren’t doing their computing by writing C anymore. It’s been the better part of 20 years since you could plausibly call it the Lingua Franca of computing.

monocasa 4y ago
Lingua Franca in this case typically refers to the fact that you write a library with at least C ABI support if you want it to have the largest user base. Almost all languages' FFIs support some C ABI for their libraries.

jitl 4y ago

> But aside from Jai, is anyone C alternative really looking to pursue having killer features? And if it doesn't have one, how does it prove the switch from C is worth it? It can't. Zig's `zig cc` is a killer feature that doesn't even require using Zig-the-language at all. `zig cc` is an LLVM-based C compiler that gives you trivial cross-compilation for existing C codebases, adds effective caching, and can be easily installed on most operating systems with `tar -xzf`. https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

sitkack 4y ago
pip install ziglang python -m ziglang
david2ndaccount 4y ago
zig cc has enough bugs in it that I just went back to using clang on each platform.
- dralley 4y ago
  Possibly true, but bugs can be fixed. The potential is still there.
- flohofwoe 4y ago
  What you're seeing is most likely not bugs (it is clang after all), but the result of the much stricter default compilation settings in "zig cc" which tends to break a lot of C code that hasn't been checked against a static analyzer or ASAN before.
  - david2ndaccount 4y ago
    No, they were bugs in zig CC. They were things like linking against the wrong frameworks on macOS.
    - flohofwoe 4y ago

pkrumins 4y ago

I will never use any other language for server apps than C. C is a language for getting things done. It's finished and final. It will not change. There will be no new surprises, no new operators, and no unpublished packages. There are just source files. Write, compile, ship, repeat. You used it in 1990 to ship, you used it in 2000 to ship, you used it in 2010 to ship, you used in 2020 to ship, and you will use it in 2030 to ship. Learn once, ship forever.

didip 4y ago
Wait… really? Not even considering C++ Boost, Go, or Rust?
- pkrumins 4y ago
  No. I like when nothing changes. C is perfect. All my code from 2000 still works.
jjgreen 4y ago
This. I know I'll never get SHOUTY DEPRECATION WARNINGS with C.
oreally 4y ago
Aways nice to see good reasoning. Though I'd veer away from it if the task is too large and the program needs to be updated frequently by multiple people. Also, you got any recommendations for a c library for server apps?

deleted 4y ago

[deleted]

Kukumber 4y ago

I just want: C with: - bounds checking - use after free checks - modules - sane metaprograming/template - tagged union built in without: - macro - pre declaration - split header/source That's it, no borrow checker, no weird syntax, no nothing So far D is the answser for me, but i'm worried about its future, will they keep improve the language in that direction? or will they continue with their high level stuff Zig/Jai/Odin so far are looking interesting, the problem is they all depart from the C syntax, wich is annoying, the only syntax i'd like to change is the primitive type, i32/f32/size/usize, and that's it, no need more

steeleduncan 4y ago
I have a similar list, but I think part the difficulty with C replacements is that the sort of people who want to go out and write a new language generally do so because they have something more radical in mind. I have pondered forking tinycc and using that as a startpoint for a more conservative set of changes like you describe. It would limit the amount of work to be done and lead to something useable quite quickly.
valepine 4y ago
Have you looked at C3 (the language OP is making)? I think it hits a lot of your boxes.
- Kukumber 4y ago
  I looked at it; and i'm not really a fan of the syntax, `fn` feels out of place Also no language server is a hard pass, tooling is important

didip 4y ago

Jai is not real. It should not be mentioned even on the same sentence as Zig.

Tozen 4y ago
You can't say Jai is not real, because there are beta testers using it. However, there are other languages that have taken and implemented various concepts that Jai had to offer. By the time Jai comes out, and is open to the public, there might not be anything compelling about it anymore.
dralley 4y ago
It's real but without public access it's largely useless. I understand why Jonathan might want to avoid dealing with a peanut gallery trying to argue with him about what his language should be like, and that's fine, his language his rules and all of that. But until this situation changes it's impossible for anyone to really care about Jai.

didgetmaster 4y ago

Like any other technology that wishes to supplant the status-quo, a new programming language cannot be just 'a little bit better'. It has to be substantially better in order to overcome the inertia that the entrenched technology has established. This is true for both software and hardware. There have been plenty of leaps and bounds such as SSD speeds compared to HDD speeds; but even there, SSDs will not supplant HDDs until there is price parity between the two technologies. Until then, data will be stored on SSD when fast access is critical and on HDD when there is too much of it to justify the cost. Getting a company to switch operating systems, database vendors, or cloud providers is likewise an uphill battle. They don't call them 'walled gardens' for nothing. I am building a new data management system that I think is much better than file systems at storing and managing unstructured data and better than RDBMS at managing structured data; but I wouldn't have even dreamed of starting the project if I wasn't confident that it was at least 2x better at a minimum.

returningfory2 4y ago

> any safety checks put into the competing language will have a runtime cost, which often is unacceptable. Suppose you have bounds checks on array accesses, but your program is 100% correct and the panic case is never hit. Doesn't the branch predictor essentially make the bounds check free? Or very low cost at least?

jstimpfle 4y ago
If what comes after the check is a write or any other destructive operation, then the check is not so easy to mask away. I don't have actual numbers, but my gut is a strong 'no'. That said, a lot of pedestrian code that isn't running particularly hot would probably be better off including runtime checks by default.
- pjmlp 4y ago
  It is no different from QuakeC, GOAL, and a myriad of other programming languages that game studios never had as milestone to release to the wieder public, yet they were quite usefull to their owners.

1vuio0pswjnm7 4y ago

Hypothetical: I need a small, fast systems language to use for writing small, portable programs.^1 Using the language the system is written in would be ideal. 1. In other words, the size of a "hello world" program matters, as does the storage space and time I need for the compiler toolchain and libraries. What language should I use. I am not interested in writing large, complex programs.

flohofwoe 4y ago

What a defeatist take :/ A "better C" language doesn't have to "win the popularity race" to be useful, it just needs to (a) be easy to learn coming from C, (b) integrate well into the existing C/C++/ObjC ecosystem, and (c) easy to install and across all supported platforms. A "better C" cannot and should not replace C for all use cases, but it should at least augment C by fixing its design wart. The actually depressing thing is the "winner takes all" mentality though that seems to be prelevant in the programming world.

AndyKelley 4y ago
This person is actively trying to make a "better C" so it's no surprise his arguments against his own project are lukewarm. "It is difficult to get a man to understand something, when his salary depends on his not understanding it."
- jstimpfle 4y ago
  Why do you put that quote? I'm not sure anybody "tried to get him understand it". I suppose the post comes mostly because of what the author learned or concluded from his own project. There might be other motivations. I think the post has some genuinely good points that need to get more mindshare.

oconnor663 4y ago

> This leads to a strategy of only having checks in "safe" mode. Where the "fast" mode is just as "unsafe" as C. This is hard to describe without getting deep into Rust details, but I think the ability to encapsulate unsafe code in safe APIs is just as important as what pure safe code can do. (Of course those two things end up being intimately related.)

rcarmo 4y ago

I still occasionally write C (and C++), but have come to appreciate the sparseness of Go (although not the intricate abstractions of Rust) and keep wondering if Zig (which does cross-compilation almost as effortlessly as Go) shouldn’t be more popular. In the end, though, you can accomplish the same (from an outcome perspective, not necessarily from a satisfactory one) in all of them, so I try not to be overly biased, although convenience vs correctness seem to be the main issues at play here. (Edit: why the downvotes? Is Zig out of favor? Is it because this may read as a slight on Rust?)

voidhorse 4y ago
I like Zig a lot and think it hits precisely the right niche for a C replacement. Rust is a great language, but it’s definitely not C like when it comes to the overall UI and philosophy. I’d like to use Zig a bit more, but the standard library is still going through some significant changes (it seems) which makes it slightly harder to commit to at the moment. In general I wonder if some of these languages would actually benefit from Jai’s approach of deferring availability until the language is ready. While getting early adopters is great for getting feedback early, it can also disuade potential users that try the language before its ready and decide to leave it alone as a result.

naniwaduni 4y ago

An oft-overlooked pain point is that when interacting with C interfaces, it's not good enough to implement a C ABI FFI. There's a world of software out there where the supporrted interface is a C API, at the source level. Compatibility across different versions, or across different implementations, is assured only to programs which interact with the interfaces in ways that correspond particular C source patterns. The biggest culprit I've met on this front is the POSIX stat family of functions.

mlindner 4y ago

> Looking at C++ alternatives there are languages like D, Rust, Nim, Crystal, Beef, Carbon and others. Why do people keep lumping Rust into the category of a "C++ alternative". Rust is a C alternative and can be used places that C can but C++ cannot. i.e the linux kernal and baremetal silicon (C++ can be used in the embedded but I've never heard of it being used without modification for that environment). > My language (C3) is fairly recent, there are others: Zig, Odin, Jai and older languages like eC. Further he seems to claim that Jai is a C alternative when it's explicitly described by it's creator as a C++ alternative.

robalni 4y ago

The problem with making a new language is that it seems like people do it because they want to make a new language. Don't make a new language just to make a new language. Do it because you are solving a problem by doing it, and if you are solving a problem, you already win regardless of how many people will use the language. Have the problem before you make the solution. > It turns out that people don't always agree on what the pain points with C is. People have different problems so they should probably use different languages. Don't even try to make a language that will solve everyone's problems. > Also, while the company has experience recruiting for C developers, it doesn't know how to recruit for this new language. If the language is so hard that people have to have special knowledge to use it and can't learn it quickly then it's probably not a good language. > For a business it's whether despite the downsides the language can help the bottom line: "Is this valuable enough to outweigh the downsides?" Exactly, it's solving real problems that matters. > The "build it and they will come" idea is tempting to believe in A better idea is "build it and we will come because we need it. Then maybe other people will come if they need it too."

deleted 4y ago

[deleted]

Cryptonic 4y ago

Written by someone who does not know about / does not understand compilietime safety guarantees

bowsamic 4y ago

The momentum of C seems so vast that replacing it is like getting humans to switch to a base-12 number system

qayxc 4y ago
That's a weird analogy considering humans used base-12 (and base-20 and base-60) number systems for most of history.
- bowsamic 4y ago
  Really? Wikipedia says it is historically uncommon EDIT: What language uses base-60??
  - jstimpfle 4y ago
    Minutes in an hour, seconds in a minute, and something about degrees.
  - Qem 4y ago
    Babylonians used it. That's the origin of our time counting system of hours, minutes and seconds and our angle measuring system of degrees, minutes and seconds. Anyway, if we someday change our number system away from 10, I hope the change will be towards a smaller base, like 8 or 6, because when one is a child, it sucks to learn the times tables. Base 12 would increase the number of entries by 44%. Base 8 would decrease them by 46%, and base 6 would have only 6*6=36 very easy to remember entries.
    - bowsamic 4y ago
      That's not a pure number system though, because it didn't have a separate character for each digit
      - Qem 4y ago
        In cuneiform they probably had.

jokoon 4y ago

Finally an article I can agree with. C is great mostly because it's easy to learn, and it has many other advantages. I dislike all those new languages because they have too many features, and they're non trivial to learn. I've looked at some rust codebases and I don't think there will be a lot of people who will want to maintain them. Rust is difficult, even though it's an awesome language. A language that could compete with C would: * Be fast to compile * Have some quality of life things you can find in the C++ STL: map, string, etc * Look a lot like C, meaning it would not try to innovate too much. To summarize, it would be a lighter version of C++.

bruce343434 4y ago
Go?
- voidhorse 4y ago
  Actually, yes. Go does a lot of the things everyone seems to want in these C replacements, the problem is that it has GC which, to a lot of people, automatically disqualifies it as an option for writing certain kinds of software you can write with manual memory management. A lot of people also tend to think they need manual memory management for $reasons when GC is actually fine.
- jokoon 4y ago
  without a GC
  - xigoi 4y ago
    Zig? Odin?
xigoi 4y ago
> easy to learn What exactly do you mean? Learn the basics? Become productive? Memorize the entire specification? I'd argue C isn't significantly faster at any of these than most other languages.
- 4y ago

outsomnia 4y ago

There is also a more general "case against the self-indulgent narcissism in creating a new language". There are an insane number of languages with the longevity of a mushroom mentioned on HN.

abnercoimbre 4y ago
Heh. This article was posted shortly after we instituted a ban [0] on language talks at Handmade Seattle 2022. There's an oversupply of enthusiastic engineers trying to provide C alternatives and it's creating massive bike-shedding and yak-shaving problems. Language designers are encouraged to give a presentation if it's about building quality software using a language. Otherwise, no. [0] https://vimeo.com/handmadeseattle/languages-are-banned https://vimeo.com/handmadeseattle/languages-are-banned

0xbeefeed 4y ago

Here comes the Rust brigade…

badpun 4y ago

Honestly, I hate includes and preprocessor directives so much that any "better C" variant which replaces them with more modern solutions would probably be enough in my book - with the caveat being that I also like having an IDE very much and wouldn't want to revert to coding in something like emacs with plugins. BTW, C++20 has a good replacement for includes (modules), but IDE support is not there yet and thus it's not usable for me.

jstimpfle 4y ago
I wholeheartedly agree, the speed of processing includes annoys me most about C. The sad part is that the mainstream alternatives that I have on the radar are _even slower_ to build. And usage of the preprocessor in APIs is allowing for good things, at least for a compiled systems language like C: Macros allow to get rid of boilerplate on the syntax level and if-defs allow for compatibility. Both points' significance is reduced a long way in other languages, because they have stronger facilities for abstraction, BUT this abstraction comes at a non-significant price and cannot replace all significant uses of the preprocessor. So I'm still stuck with C. The solution is designing header files carefully, resulting in build times that are lightning fast, at least in relation to most other mainstream languages. And there is always the option to go for "unity" builds.
- badpun 4y ago
  What bother me most is not even the speed of compilation (although it's a major pain too), but the fact that I need to create a header file for every .c file I want to have used from outside it's compilation unit, and add method declarations in it. In 2022 it's SO BACKWARDS it hurts.
  - jstimpfle 4y ago
    I almost never found that painful. Maybe a couple things that help: 1) Improve modularization. APIs should be small (as a rule). 2) Don't write a new file for each "class". It's not a problem to have files with more than 1 KLOC. But it is problematic to have a lot of really small files, as is (I think) customary with say Java.

pornel 4y ago

> No experienced developers Whenever a CVE is discussed, even if the code was from Google, Microsoft, or Apple, commenters immediately point out that these companies must have hired some "bad programmers", because a "good programmer" wouldn't have made such mistake. Given that even top software companies continue producing CVEs on a regular basis, there is a shortage of people capable of writing C. A lot of programming skills are transferable (algorithms, architecture, system APIs, debugging), so you don't really need to hire "language X programmer".

bullen 4y ago

I came to the same conclusion last year: C (client) and Java (server) are the final languages. To fragment the industry with more languages is a hidden cost that wont end well for anyone. KWh is approaching $1, prepare by choosing the proper languages.

brhsagain 4y ago

> First of all, pretty much all languages ever will make vacuous claims of "higher programmer productivity". The problem is that for a business this usually doesn't matter. Why? Because the actual programming is not the main time sink. In a business, what takes time is to actually figure out what the task really is. So something like a 10% or 20% "productivity boost" won't even register. A 100% increase in productivity might show, but even that isn't guaranteed. I stopped reading here. This is like saying typing speed doesn't matter because most of your time is spent thinking about what to type. If your argument basically evaluates to saying that it doesn't matter how productive you are while doing the actual activity of your job itself... at some point it's like, I dunno, do you actually believe what you're saying? Also, not to go off on too unrelated/unhinged a tangent, but, I've also started noticing in the last five years this widespread fear of actually sitting down and programming. There's a weird meta-culture where people want to do anything but sit down and write code, because it's hard and scary. I hear arguments made all the time for how important everything is — aligning stakeholders, scoping tasks, communication, mentoring juniors, soft skills, whatever. Everything except writing the actual code, which is somehow a mere technical triviality that anyone can do, or something.

jstimpfle 4y ago
The point is "marginal costs from switching languages may outweigh any benefits in plain programming productivity".
doctor_eval 4y ago
Right? Productivity makes thinking easier. It’s part of a virtuous cycle.
dgb23 4y ago
I agree especially with that last point. There is something about programming that is very difficult. It gets _more_ difficult if you write complex things, but that's not the essence of it. I think it has something to do with raw concentration. We have all of these tools that help us to write code while making few mistakes. From constrained DSLs/configuration languages, schemas, static typing to automated tests etc. But in the end we still have to exert all that energy to sit down, focus and do the coding. Meetings, design, coordination etc. All of those things are important, and they can be exhausting in their own way. But programming is by far the most challenging, hour per hour (pound for pound). Making all of these micro decisions, think about the impact of your code, the readability, the correctness. It is _at least_ two times harder and more draining than anything else I do, even when I'm in a flow state and the actual work is fun, more fun than all of the other tasks. And I agree: It is the most important thing. I mean all of the other stuff is basically there to support the core task that solves your problems: producing working software (except if it isn't but then you have political problems). There are seemingly infinite dimensions for improvement as well, tradeoffs such as performance, efficiency, robustness, usability, leverage, creativity...

chriswarbo 4y ago

> any safety checks put into the competing language will have a runtime cost, which often is unacceptable This is completely wrong. The best counterexample is probably ATS http://www.ats-lang.org http://www.ats-lang.org which is compatible with C, yet also features dependent types (allowing us to prove arbitrary statements about our programs, and check them at compile time) and linear type (allowing us to precisely track resource usage; similar to Rust) A good example is http://ats-lang.sourceforge.net/DOCUMENT/ATS2CAIRO/HTML/c36.html http://ats-lang.sourceforge.net/DOCUMENT/ATS2CAIRO/HTML/c36.... which uses the Cairo graphics library, and ends with the following: > It may seem that using cairo functions in ATS is nearly identical to using them in C (modulo syntatical difference). However, what happens at the level of typechecking in ATS is far more sophisticated than in C. In particular, linear types are assigned to cairo objects (such as contexts, surfaces, patterns, font faces, etc.) in ATS to allow them to be tracked statically, that is, at compile-time, preventing potential mismanagement of such objects. For instance, if the following line: val () = cairo_surface_destroy (sf) // a type error if omitted > is removed from the program in tutprog_hello.dats, then a type-error message is issued at compile-time to indicate that the resource sf is not properly freed. A message as such can be of great value in practice for correcting potential memory leaks that may otherwise readily go unnoticed. ATS is a programming language that distinguishes itself in its practical and effective support for precise resource management.

manholio 4y ago

Rust is not only a C++ alternative, it's a C alternative too. You don't have to have methods in your structs or use generics, traits, closures, interators etc. You won't be able to use the standard library, but it's doable.

sylware 4y ago

C has already a syntax way too rich. ISO should fix and remove from the syntax. Yes, break backward compatibility starting from "c24". Let's go in a fantasy world where we have a B+ language which should have been C: remove typedef/_generic/typeof/restrict/enum/etc, well all those horrible things. Only one loop statement, loop {}, no switch ofc. Only sized/signed core types with properly sized/signed literals: ub/sb or u8/s8 with integer literals like 123ub/123sb, sw/sd..., udw/sdw... , uqw/sqw..., fdw/1.23fdw (f32), fqw/1.23fqw (f64) (for some hardware ymm/xmm/zmm with fancy literals, sorry I am not aware of the fine details of the C/CPP lexer). Ofc, no integer promotion and no implicit cast (void* would still not require any cast). Compile-time and runtime cast (not like with that horrible c++ syntax), same thing for consts (even though nowadays it is the the compiler which detects real compile-time constants), yes you may have to "static const" your literals. Oh, and for the C preprocessor, do fix that variadic-args function-like macro for good (I wonder if gcc the way is not better than c++ ISO way). Without all that, it should be "reasonable" for a small team of average-skilled or an individual to write a naive compiler until they don't forget they can hit a goto at any line. And they are those who say "but feature A is cheap to implement"... 1 million cheap features later... well, you get the picture. The really hard part for ISO was to keep C actually "cheap" to implement, this is where they are failing hard. As for the gcc extension based C dialect for kernel developement, no salvation here, C is really too alien (or even B+). Namely the little ISA abstraction is not "enough", so either the kernel goes full "slow" with plain C and assembly (_not_ inline assembly ofc), or full assembly on all of its fast-paths which would require proper binary defined specs (I am currently researching how bad this could be). I do believe the open source communities have the strength to maintain parallel assembly _significant_ code bases (which do the same thing), big monolithic corpos... not so sure...

tpoacher 4y ago

After many years in this field, I am convinced we don't need a better "C" at all. We need better "C education".

selfmodruntime 4y ago
I tend to disagree at this notion. I've used C for almost a decade now and I've seen many developers who were far more talented than me make similar mistakes all the time. Some problems require solutions which are unable to be solved in C in a safe way.

xorvoid 4y ago

The article misses a really big item. I’ve programmed in C for 20+ years and then recently switched to rust. When fellow C programmers ask me how Rust is going, I say “it’s modern” and “it’s consistent”. What I mean by that unlike C, Rust doesn’t have 50 years of baggage: string functions that handle null termination all differently, complicated implicit promotion rules, null-terminated strings that haven’t been a good idea for decades, apis that we’re completely busted by posix threads but still exist, functions that cannot be used safely that still exist, code snippet examples with horribly broken unsafe code that beginners copy-paste, dubious and bad type-based aliasing, rampant use of UB, etc etc etc Sadly Rust is not a better C. Maybe it’ll grow into one some day. Today it’s a better C++. Sadly I’d still chose C to do C’s job. All I want from “better C” is to fix the obviously bad problems from C’s history. Or rather, maybe that’s the committee’s job. At any rate: it’s embarrassing that we’re still so dependent on a language that’s so broken. And it’s sad that there doesn’t seem to be a path forward.

mtlmtlmtlmtl 4y ago
When I discovered strsep was a thing I was genuinely a bit mad that I'd been "tricked" into using strtok all this time. Since then I never just look up a function in the standard library reference. It's a fair chance its API is far from ideal, especially in string.h
kaba0 4y ago
What is C’s job, when would you use it for a green field project? Not trying to start a flame war, genuinely curious as I see less and less need for C, other than maintaining all those existing code bases.
- cartoonfoxes 4y ago
  When working with the huge amounts of embedded silicon that is supported by C libraries and toolchains only.