I stopped everything and started writing C again

https://www.kmx.io/blog/why-stopped-everything-and-started-writing-C-again

by dvrj101 • 1 year ago

404 366 1 year ago

kmx.io

OutOfHere• 1 year ago

The point is that much of the defensive programming you would have to do in C is unnecessary and automatic in Rust.

guappa• 1 year ago

There's much more to defensive programming than avoiding double frees and overflows.

desdenova2• 1 year ago

much != all

IshKebab• 1 year ago

Yeah and Rust enables much more defensive programming than just avoiding double frees and overflows.

elif• 1 year ago

So this is a journey where starting in ruby, going through an SICP phase, and then eventually compromising that it isn't viable. it kinda seems like C is just the personal compromise of trying to maintain nerdiness rather than any specific performance needs.

I think it's a pretty normal pattern I've seen (and been though) of learning-oriented development rather than thoughtful engineering.

But personally, AI coding has pushed me full circle back to ruby. Who wants to mentally interpret generated C code which could have optimisations and could also have fancy looking bugs. Why would anyone want to try disambiguating those when they could just read ruby like English?

dkersten2• 1 year ago

But personally, AI coding has pushed me full circle back to ruby.

This happened to me too. I’m using Python in a project right now purely because it’s easier for the AI to generate and easier for me to verify. AI coding saves me a lot of time, but the code is such low quality there’s no way I’d ever trust it to generate C.

somewhereoutth• 1 year ago

AI coding saves me a lot of time, but the code is such low quality

Given that low quality code is perhaps the biggest time-sink relating to our work, I'm struggling to reconcile these statements?

codr715• 1 year ago

Because Ruby can't handle most of the problems C is used for?

Because they're implementing Ruby, for example?

kqr7• 1 year ago

I started programming with C a long time ago, and even now, every few months, I dream of going back to those roots. It was so simple. You wrote code, you knew roughly which instructions it translated to, and there you went!

Then I try actually going through the motions of writing a production-grade application in C and I realise why I left it behind all those years ago. There's just so much stuff one has to do on one's own, with no support from the computer. So many things that one has to get just right for it to work across edge cases and in the face of adversarial users.

If I had to pick up a low-level language today, it'd likely be Ada. Similar to C, but with much more help from the compiler with all sorts of things.

anta402• 1 year ago

Don't forget Pascal is still alive.

wruza2• 1 year ago

From what I remember about Ada, it is basically Pascal for rockets.

bayindirh• 1 year ago

Also, COBOL and FORTRAN. FORTRAN is still being developed and one of the languages supported as first class citizen by MPI.

There's a big cloud of hype at the bleeding edge, but if you dare to look beyond that cloud, there are many boring and well matured technologies doing fine.

graycat• 1 year ago

When Ada was first announced, I rushed to read about it -- sounded good. But so far, never had access to it.

So, now, after a long time, Ada is starting to catch on???

When Ada was first announced, back then, my favorite language was PL/I, mostly on CP67/CMS, i.e., IBM's first effort at interactive computing with a virtual machine on an IBM 360 instruction set. Wrote a little code to illustrate digital Fourier calculations, digital filtering, and power spectral estimation (statistics from the book by Blackman and Tukey). Showed the work to a Navy guy at the JHU/APL and, thus, got "sole source" on a bid for some such software. Later wrote some more PL/I to have 'compatible' replacements for three of the routines in the IBM SSP (scientific subroutine package) -- converted 2 from O(n^2) to O(n log(n)) and the third got better numerical accuracy from some Ford and Fulkerson work. Then wrote some code for the first fleet scheduling at FedEx -- the BOD had been worried that the scheduling would be too difficult, some equity funding was at stake, and my code satisfied the BOD, opened the funding, and saved FedEx. Later wrote some code that saved a big part of IBM's AI software YES/L1. Gee, liked PL/I!

When I started on the FedEx code, was still at Georgetown (teaching computing in the business school and working in the computer center) and in my appartment. So, called the local IBM office and ordered the PL/I Reference, Program Guide, and Execution Logic manuals. Soon they arrived, for free, via a local IBM sales rep highly curious why someone would want those manuals -- sign of something big?

Now? Microsoft's .NET. On Windows, why not??

pjmlp3• 1 year ago

So, now, after a long time, Ada is starting to catch on???

Money and hardware requirements.

Finally there is a mature open source compiler, and our machines are light years beyond those beefy workstations required for Ada compilers in the 1980's.

phicoh6• 1 year ago

I recently started re-reading "Programming in Ada" by J.G.P. Barnes about the original Ada. In my opinion, it was not that good of a language. Plenty of ways to trigger undefined behavior.

Where C was clearly designed to be a practical language with feedback from implementing an operating system in C. Ada lacked that kind of practical experience. And it shows.

I don't know anything about modern day Ada, but I can see why it didn't catch on in the Unix world.

saati• 1 year ago

You wrote code, you knew roughly which instructions it translated to, and there you went!

This must have been a very very long time ago, with optimizing compilers you don't really know even if they will emit any instructions.

kqr7• 1 year ago

On x86-type machines, you still have a decent chance, because the instructions themselves are so complicated and high-level. It's not that C is close to the metal, it's that the metal has come up to nearly the level of C!

I wouldn't dare guess what a compiler does to a RISC target.

(But yes, this was back in the early-to-mid 2000s I think. Whether that is a long time ago I don't know.)

pjmlp3• 1 year ago

Yeah, back in the MS-DOS and Amiga glory days when C compilers were dumb, and anyone writing Assembly by hand could easily outperform them.

C source files for demoscene and games were glorified macro assemblers full of inline assembly.

postexitus• 1 year ago

Thanks for the reference to Amiga. Every random reference to my beloved computer fills me with joy.

dan_quixote• 1 year ago

Similar to C, but with much more help from the compiler with all sorts of things.

Is that not the problem rust was created to solve?

kelnos11• 1 year ago

Rust is more like C++ (though still not really) than like C. Rust is a complete re-imagination of what a systems language could be.

kqr7• 1 year ago

Indeed. I'm still not entirely sure why Rust was created when we have Ada, but if I had to guess it's mainly because Rust has slightly more advanced tricks for safe memory management, and to some degree because Rust has curly braces.

jancsika• 1 year ago

I started programming with C a long time ago, and even now, every few months, I dream of going back to those roots. It was so simple. You wrote code, you knew roughly which instructions it translated to, and there you went!

Related-- I'm curious what percentage of Rust newbies "fighting the borrow checker" is due to the compiler being insufficiently sophisticated vs. the newbie not realizing they're trying to get Rust to compile a memory error.

phicoh6• 1 year ago

If you come from C to Rust to basically have to rewire your brain. There are some corner cases that are wrong in Rust, but mostly you have to get used to a completely new way of thinking about object lifetimes and references to objects.

MaulingMonkey• 1 year ago

I certainly spent most (95%+?) of my "fighting the borrow checker" time writing code I would never try to write in C++. A simple example is strings: I'd spend a lot of time trying to get a &str to work instead of a String::clone, where in equivalent C++ code I'd never use std::string_view over std::string - not because it would be a memory error to do so in my code as it stood, but because it'd be nearly impossible to keep it memory safe with code reviews and C++'s limited static analysis tooling.

This was made all the worse by the fact that I frequently, eventually, succeeded in "winning". I would write unnecessary and unprofiled "micro-optimizations" that I was confident were safe and would remain safe in Rust, that I'd never dare try to maintain in C++.

Eventually I mellowed out and started .clone()ing when I would deep copy in C++. Thus ended my fight with the borrow checker.

wolvesechoes• 1 year ago

Not everything can be proved at compile-time, so necessarily Rust is going to complain about things that you know can be done safely in that specific context.

For example some tree structures are famously PITA in Rust. Yes, possible, but PITA nonetheless.

uecker• 1 year ago

C compilers got a lot better though and sanitizers and analyzers can also easily catch a lot of mistakes.

willtemperley• 1 year ago

Writing user-facing applications in Swift and dropping to C and C++ when required seems to give the best of both worlds.

For me the main benefit of C and C++ is the availability of excellent and often irreplaceable libraries. With a little bridging work, these tend to just work with Swift.

jeroenhd• 1 year ago

Swift seems like an excellent language, but I can't shake the feeling that it's just not worth learning unless you're writing code on and for Apple's ecosystem.

m463• 1 year ago

no support from the computer

There are a lot of things that are so USEFUL, but maddening.

C is one. make is another.

They serve a really valid purpose, but because they are stable, they have also not evolved at all.

from your ada example, I love package and package body. C has function prototypes but it is almost meaningless.

everyone seems to think C++ is C grown=up, but I don't really like it. It is more like systemd. People accept it but don't love it.

lqet• 1 year ago

I fully understand that sentiment. For several years now, I have also felt the strong urge to develop something in pure C. My main language is C++, but I have noticed over and over again that I really enjoy using the old C libraries - the interfaces are just so simple and basic, there is no fluff. When I develop methods in pure C, I always enjoy that I can concentrate 100% on algorithmic aspects instead of architectural decisions which I only have to decide on because of the complexity of the language (C++, Rust). To me, C is so attractive because it is so powerful, yet so simple that you can hold all the language features in your head without difficulty.

I also like that C forces me to do stuff myself. It doesn't hide the magic and complexity. Also, my typical experience is that if you have to write your standard data structures on your own, you not only learn much more, but you also quickly see possibly performance improvements for your specific use case, that would have otherwise been hidden below several layers of library abstractions.

This has put me in a strange situation: everyone around me is always trying to use the latest feature of the newest C++ version, while I increasingly try to get rid of C++ features. A typical example I have encountered several times now is people using elaborate setups with std::string_view to avoid string copying, while exactly the same functionality could've been achieved by fewer code, using just a simple raw const char* pointer.

chronogram• 1 year ago

Variety is good. I got so used to working in pure C and older C++ that for a personal project I just started writing in C, until I realised that I don't have to consider other people and compatibility, so I had a lot of fun trying new things.

brucehoult5• 1 year ago

Try doing C with a garbage collector ... it's very liberating.

Do `#include <gc.h>` then just use `GC_malloc()` instead of `malloc()` and never free. And add `-lgc` to linking. It's already there on most systems these days, lots of things use it.

You can add some efficiency by `GC_free()` in cases where you're really really sure, but it's entirely optional, and adds a lot of danger. Using `GC_malloc_atomic()` also adds efficiency, especially for large objects, if you know for sure there will be no pointers in that object (e.g. a string, buffer, image etc).

There are weak pointers if you need them. And you can add finalizers for those rare cases where you need to close a file or network connection or something when an object is GCd, rather than knowing programmatically when to do it.

But simply using `GC_malloc()` instead of `malloc()` gets you a long long way.

You can also build Boehm GC as a full transparent `malloc()` replacement, and replacing `operator new()` in C++ too.

dlisboa• 1 year ago

Which GC is that you’re using in these examples?

kokada3• 1 year ago

I think one of the nice things about C is that since the language was not designed to abstract e.g.: heap is that it is really easy to replace manual memory management with GC or any other approach to manage memory, because most APIs expects to be called with `malloc()` when heap allocation is needed.

I think the only other language that has a similar property is Zig.

enriquto4• 1 year ago

Try doing C with a garbage collector ... it's very liberating.
Do `#include <gc.h>` then just use `GC_malloc()` instead of `malloc()` and never free.

Even more liberating (and dangerous!): do not even malloc, just use variable length-arrays:

    void f(float *y, float *x, int n)
    {
            float t[n];  // temporary array, destroyed at the end of scope
            ...
    }

This style forces you to alloc the memory at the outermost scope where it is visible, which is a nice thing in itself (even if you use malloc).

DeathArrow3• 1 year ago

Try doing C with a garbage collector ... it's very liberating.

Doing that means that I lose some speed and I will have to wait for GC collection.

Then why shouldn't I use C# which is more productive and has libraries and frameworks that comes with batteries included that help me build functionality fast.

I thought that one of the main points of using C is speed.

bsenftner4• 1 year ago

About 16 years ago I started working with a tech company that used "C++ as C", meaning they used a C++ compiler but wrote pretty much everything in C, with the exception of using classes, but more like Python data classes, with no polymorphism or inheritance, only composition. Their classes were not to hide, but to encapsulate. Over time, some C++ features were allowed, like lambdas, but in general we wrote data classed C - and it screamed, it was so fast. We did all our own memory management, yes, using C style mallocs, and the knowledge of what all the memory was doing significantly aided our optimizations, as we targeted to be running with on cache data and code as much as possible. The results were market leading, and the company's facial recognition continually lands in the top 5 algorithms at the annual NIST FR Vendor test.

zaphirplane• 1 year ago

Sounds like they know what they are doing. How is using c++ with only data classes different from using c with struct

hliyan2• 1 year ago

Funnily enough, 16 years ago, I too was in exactly this type of company. C++, using classes, inheritance only for receiving callbacks, most attributes were public (developers were supposed to know how not to piss outside the bowl), pthreads with mutexed in-memory queues for concurrency, no design patterns (yes we used globals instead of Singleton) etc. So blazingly fast we were measuring latencies in sub 100-microseconds. Now, when modern developers say something is "blazingly fast" when it's sub-second, I can only shake my head in disbelief.

drwu• 1 year ago

Also fast to compile!

zelphirkalt2• 1 year ago

This however, is an implementation strategy, that most business/"enterprise" developers will fight to the teeth, because they believe, that OOP is the only workable way to create abstractions and that any successful project must have inheritance in it. They never learned another way.

Actually Rust goes a long way towards a similar strategy, by avoiding inheritance and instead relying on structs and traits. That already avoids a lot of BS programming. I am very glad they threw out inheritance and classes. Great design decision right there. I wish FP was made more convenient/possible in Rust though.

rossant• 1 year ago

I completely agree with this sentiment. That's why I wrote Datoviz [1] almost entirely in C. I use C++ only when necessary, such as when relying on a C++ dependency or working with slightly more complex data structures. But I love C’s simplicity. Without OOP, architectural decisions become straightforward: what data should go in my structs, and what functions do I need? That’s it.

The most inconvenient aspect for me is manual memory management, but it’s not too bad as long as you’re not dealing with text or complex data structures.

[1] https://datoviz.org/

maccard• 1 year ago

A typical example I have encountered several times now is people using elaborate setups with std::string_view to avoid string copying, while exactly the same functionality could've been achieved by fewer code, using just a simple raw const char* pointer.

C++ can avoid string copies by passing `const string&` instead of by value. Presumably you're also passing around a subset of the string, and you're doing bounds and null checks, e.g.

    const char* Buf = "Hello World" ;
    print_hello(Buf, 6);

string_view is just a char* + len; which is what you should be passing around anyway.

Funnily enough, the problem with string view is actually C api's, and this problem exists in C. Here's a perfect example: (I'm using fopen, but pretty much every C api has this problem).

    FILE* open_file_from_substr(const char* start, int len)
    {
        return fopen(start);
    }

    void open_files()
    {
        const char* buf = "file1.txt file2.txt file3.txt";

        for (int i = 0; i += 10; ++i) // my math might be off here, apologies
        {

            open_file_from_substr(buf + i, buf + i + 10); // nope.
        }
    }

> When I develop methods in pure C, I always enjoy that I can concentrate 100% on algorithmic aspects instead of architectural decisions which I only have to decide on because of the complexity of the language

I agree this is true when you develop _methods_, but I think this falls apart when you design programs. I find that you spend as much time thinking about memory management and pointer safety as you do algorithmic aspects, and not in a good way. Meanwhile, with C++, go and Rust, I think about lifetimes, ownership and data flow.

wruza2• 1 year ago

I also like that C forces me to do stuff myself

I never liked that you have to choose between this and C++ though. C could use some automation, but that's C++ in "C with classes" mode. The sad thing is, you can't convince other people to use this mode, so all you have is either raw C interfaces which you have to wrap yourself, or C++ interfaces which require galaxy brain to fully grasp.

I remember growing really tired of "add member - add initializer - add finalizer - sweep and recheck finalizers" loop. Or calculating lifetime orders in your mind. If you ask which single word my mind associates with C, it will be "routine".

C++ would be amazing if its culture wasn't so obsessed with needless complexity. We had a local joke back then: every C++ programmer writes heaps of C++ code to pretend that the final page of code is not C++.

chasd00• 1 year ago

Most of the embedded world is still C, if you want to write C that's probably the place to find a community.

zafka• 1 year ago

I agree with this sentiment. My first gig was telecom, and I wrote in a pascal like language called CHILL, but found out my forte was debugging and patching and ended up doing a fair amount of assembly code that would get applied to live systems. The decade plus I spent in medical devices, I used C and assembly. The thing is, if you own all the code and actually understand what it is supposed to do, you can write safe code.

hgs32• 1 year ago

Agreed. C, Go, Python, and Lua are my go-to languages because of their simplicity. It's unfortunate, but in my opinion, most mainstream languages are needlessly complex.

In my experience, whether it's software architecture or programming language design, it's easy to make things complicated, but it takes vision and discipline to keep them simple.

pansa22• 1 year ago

C, Go, Python, and Lua are my go-to languages because of their simplicity

One of these things is not like the others! Python's complexity has been increasing rapidly (e.g. walrus operator, match statement, increasingly baroque type hints) - has this put you off the language at all?

DeathArrow3• 1 year ago

I like the idea of using C++ as C. I began disliking OOP, inheritance and encapsulation, heavy usage of GoF patterns and even SOLID. They promise easy to understand, easy to follow, easy to maintain, easy to change, easy to extend code and a good productivity but the effect is contrary, most of the times.

I like functional programming and procedural programming. Fits better to how I think about code. Code is something that takes data and spits data. Code shouldn't be forced into emulating some real life concepts.

TurboHaskal• 1 year ago

This reads like a cautionary tale about getting nerdsniped, without a happy ending.

wolfspaw• 1 year ago

" I was gaining a lot of money with Ruby on Rails

Then, I decided to move to Common Lisp and start gaining less and less money

Then, I decided to move to C and got Nerd Snipped "

Well, atleast he seems more happy xD

C is cool though

CrimsonCape• 1 year ago

Yeah, I think every programmer experiences the "I should write a language" moment when the solution to the problem is abstracted to be the language itself.

codr715• 1 year ago

I think every programmer should at some point write their own language.

pmontra• 1 year ago

504 Gateway Timeout

Archived at https://archive.is/zIZ8S

contificate• 1 year ago

I sometimes write C recreationally. The real problem I have with it is that it's overly laborious for the boring parts (e.g. spelling out inductive datatypes). If you imagine that a large amount of writing a compiler (or similar) in C amounts to juggling tagged unions (allocating, pattern matching over, etc.), it's very tiring to write the same boilerplate again and again. I've considered writing a generator to alleviate much of the tedium, but haven't bothered to do it yet. I've also considered developing C projects by appealing to an embeddable language for prototyping (like Python, Lua, Scheme, etc.), and then committing the implementation to C after I'm content with it (otherwise, the burden of implementation is simply too high).

It's difficult because I do believe there's an aesthetic appeal in doing certain one-off projects in C: compiled size, speed of compilation, the sense of accomplishment, etc. but a lot of it is just tedious grunt work.

anymouse123456• 1 year ago

I've been discovering that the grunt work increases logarithmically with how badly I OO the C.

When I simplify and think in terms of streams, it starts getting nice and tidy.

ManBeardPc• 1 year ago

C was my first language and I quickly wrote my first console apps and a small game with Allegro. It feels incredibly simple in some aspects. I wouldn’t want to go back though. The build tools and managing dependencies feels outdated, somehow there is always a problem somewhere. Includes and the macro system feels crude. It’s easy to invoke undefined behavior and only realizing later because a different compiler version or flag now optimizes differently. Zig is my new C, includes a C compiler and I can just import C headers and use it without wrapper. Comptime is awesome. Build tool, dependency management and testing included. Cross compilation is easy. Just looks like a modern version of C. If you can live with a language that is still in development I would strongly suggest to take a look.

Otherwise I use Go if a GC is acceptable and I want a simple language or Rust if I really need performance and safety.

randomNumber72• 1 year ago

Despite what some people religiously think about programming languages, imo C was so successful because it is practical.

Yes it is unsafe and you can do absurd things. But it also doesn't get in the way of just doing what you want to do.

bamboozled2• 1 year ago

Sounds a bit like perl but at a lower level ?

high_priest• 1 year ago

Sounds a bit like JavaScript, but at a tower level?

TingPing• 1 year ago

I wouldn’t compare them, C is very simple.

ThinkBeat• 1 year ago

You can certainly do entirely absurd things in Perl. But it is a lot easier / safer work with. You get / can get a wealth of information when you the wrong thing in Perl.

With C segmentation fault is not always easy to pinpoint.

However the tooling for C, with sone if the IDEs out there you can set breakpoints/ walk through the code in a debugger, spot more errors during compile time.

There is a debugger included with Perk but after trying to use it a few times I have given up on it.

Give me C and Visual Studio when I need debugging.

On the positive side, shooting yourself in the foot with C is a common occurrence.

I have never had a segmentation fault in Perl. Nor have I had any problems managing the memory, the garbage collector appears to work well. (at least for my needs)

ycuser2• 1 year ago

I don't think C was successful. It still is! What other language from the 70s is still under the top 5 languages?

https://www.tiobe.com/tiobe-index/

Horffupolde• 1 year ago

SQL, Lisp.

zerr• 1 year ago

No, it's because of Unix and AT&T monopoly.

relaxing4• 1 year ago

How was AT&T’s monopoly a driver? It’s not like they forced anyone to use UNIX.

dboreham• 1 year ago

Monopoly of the long distance telephone call market??

anta402• 1 year ago

If you want to do microcontroller/embedded, I think C it still the overall best choice, supported by vendors. Rust and Ada are probably slowly catching up.

markus_zhang• 1 year ago

C, or more precisely a constrained C++ is my go to language for side projects.

Just pick the right projects and the language shines.

codr715• 1 year ago

I've tried, but never succeeded in doing that; the complexity eventually seeps in through the cracks.

C++'s stdlib contains a lot of convenient features, writing them myself and pretending they aren't there is very difficult.

Disabling exceptions is possible, but will come back to bite you the second you want to pull in external code.

You also lose some of the flexibility of C, unions become more complicated, struct offsets/C style polymorphism isn't even possible if I remember correctly.

I love the idea though :)

ryandrake• 1 year ago

C++'s stdlib contains a lot of convenient features, writing them myself and pretending they aren't there is very difficult.

I've never understood the motivation behind writing something in C++, but avoiding the standard library. Sure, it's possible to do, but to me, they are inseparable. The basic data types and algorithms provided by the standard library are major reasons to choose the language. They are relatively lightweight and memory-efficient. They are easy to include and link into your program. They are well understood by other C++ programmers--no training required. Throughout my career, I've had to work in places where they had a "No Standard Library" rule, but that just meant they implemented their own, and in all cases the custom library was worse. (Also, none of the companies could articulate a reason for why they chose to re-implement the standard library poorly--It was always blamed on some graybeard who left the company decades ago.)

Choosing C++ without the standard library seems like going skiing, but deliberately using only one ski.

keepamovin• 1 year ago

The author's github profile: https://github.com/thodg

The way he writes about his work in this article, I think he's a true master. Very impressive to see people with such passion and skill.

kuon• 1 year ago

Try zig, it is C with a bit of polish.

sgt2• 1 year ago

Why zig and not Rust? Just to throw the question out there :-)

kelnos11• 1 year ago

Zig is a much simpler language than Rust. I'm a big Rust fan, but Rust is not even close to a drop-in replacement for C. It has a steep learning curve, and often requires thinking about and architecting your program much differently from how you might if you were using C.

For a C programmer, learning and becoming productive in Zig should be a much easier proposition than doing the same for Rust. You're not going to get the same safety guarantees you'd get with Rust, but the world is full of trade offs, and this is just one of them.

nyrikki2• 1 year ago

For me, where linked lists, graphs and other structures are a common need, zig gives me slices and deferred frees.

Rust is double expensive in this case. You have to memorize the borrow checker and be responsible for all the potential undefined behavior with unsafe code.

But I am not a super human systems programmer. Perhaps if I was the calculus would change. But personally when I have to drop down below a GC language, it is pretty close to the hardware.

Zig simply solves more of my personal pain points... but if rust matures in ways that help those I'll consider it again.

sramsay• 1 year ago

it is C with a bit of polish.

I am fast becoming a Zig zealot.

What I've discovered is that while it does regularize some of the syntax of C, the really noticeable thing about Zig is that it feels like C with all the stuff I (and everyone else) always end up building on my own built into the language: various allocators, error types, some basic safety guardrails, and so forth.

You can get clever with it if you want -- comptime is very, very powerful -- but it doesn't have strong opinions about how clever you should be. And as with C, you end up using most of the language most of the time.

I don't know if this is the actual criterion for feature inclusion and exclusion among the Zig devs, but it feels something like "Is this in C, or do C hackers regularly create this because C doesn't have it?" Allocators? Yes. Error unions? Yes. Pattern matching facilities? Not so much. ADTs? Uh, maybe really stupid ones? Generics, eh . . . sometimes people hack that together when it feels really necessary, but mostly they don't.

Something like this, it seems to me, results in features Zig has, features Zig will never have, and features that are enabled by comptime. And it's keeping the language small, elegant, and practical. I'm a big time C fan, and I love it.

__turbobrew__2• 1 year ago

and so forth

forth, you say?

codedokode6• 1 year ago

I saw mentions of Zig here often, so I decided to look at the docs to see what features it has. I had to scroll through all the docs only to find myself disappointed by the fact that Zig doesn't help with memory management in any way and advices to use comments and careful coding instead. And what adds to the disappointment is that its plus/minus operators do not catch overflow. If I wanted undefined behaviour, I could just use C/C++ as no language can compete with them in this regard.

somethingor• 1 year ago

plus/minus operators do not catch overflow

They do (in Debug and ReleaseSafe modes)

tromp• 1 year ago

Here's what kc3 code looks like (taken from [1]):

    def route = fn (request) {
      if (request.method == GET ||
          request.method == HEAD) do
        locale = "en"
        slash = if Str.ends_with?(request.url, "/") do "" else "/" end
        path_html = "./pages#{request.url}#{slash}index.#{locale}.html"
        if File.exists?(path_html) do
          show_html(path_html, request.url)
        else
          path_md = "./pages#{request.url}#{slash}index.#{locale}.md"
          if File.exists?(path_md) do
            show_md(path_md, request.url)
          else
            path_md = "./pages#{request.url}.#{locale}.md"
            if File.exists?(path_md) do
              show_md(path_md, request.url)
            end
          end
        end
      end
    }

[1] https://git.kmx.io/kc3-lang/kc3/_tree/master/httpd/page/app/...

cgh• 1 year ago

Yeah, I'm not sure a lot of people read the article. This isn't really a back to basics, going back to C, forgoing complexity type of article, but instead it's about developing a new programming language called KC3 to make use of ideas he originally developed in Lisp.

jkhdigital• 1 year ago

The author mentions being deeply inspired and influenced by Jose Valim; I guess this means (approximately) that KC3 is to C as Elixir is to Erlang?

relistan3• 1 year ago

Maybe early return isn’t allowed in that language, but it sure would make that a heck of a lot easier to read.

FrustratedMonky• 1 year ago

Maybe the moral here is learning Lisp made him a better C programmer.

Could he have jumped right into C and had amazing results, if not for the Journey learning Lisp and changing how he thought of programming.

Maybe learning Lisp is how to learn to program. Then other languages become better by virtue of how someone structures the logic.

codr715• 1 year ago

I would definitely recommend any programmer to learn both Lisp and C at some point.

csimai• 1 year ago

I've read through your website and thinking processes.

Your work is genius! I hope KC3 can be adopted widely, there is great potential.

wvh• 1 year ago

Going from mid-90s assembly to full stack dev/sec/ops, getting back to just a simple Borland editor with C or assembly code sounds like a lovely dream.

Your brain works a certain way, but you're forced to evolve into the nightmare half-done complex stacks we run these days, and it's just not the same job any more.

bArray• 1 year ago

Virtual machines still suck a lot of CPU and bandwidth for nothing but emulation. Containers in Linux with cgroups are still full of RCE (remote command execution) and priviledge escalation. New ones are discovered each year. The first report I got on those listed 10 or more RCE + PE (remote root on the machine). Remote root can also escape VMs probably also.

A proper virtual machine is extremely difficult to break out of (but it can still happen [1]). Containers are a lot easier to break out of. I virtual machines were more efficient in either CPU or RAM, I would want to use them more, but it's the worst of both.

[1] https://www.zerodayinitiative.com/advisories/ZDI-23-982/

rainmaking• 1 year ago

I like Nim- compiles to C so you get similarly close to the instructions and you can use a lot of high level features if you want to, but you can also stay close to the metal.

kelnos11• 1 year ago

I'm kinda in the opposite camp. After doing a bunch of VB in my tweens and teens, I learned Java, C, and C++ in college, settling on mostly C for personal and professional projects. I became a core developer of Xfce and worked on that for 5 years.

Then I moved into backend development, where I was doing all Java, Scala, and Python. It was... dare I say... easy! Sure, these kinds of languages bring with them other problems, but I loved batteries-included standard libraries, build systems that could automatically fetch dependencies -- and oh my, such huge communities with open-source libraries for nearly anything I could imagine needing. Even if most of the build systems (maven, sbt, gradle, pip, etc.) have lots of rough edges, at least they exist.

Fast forward 12 years, and I find myself getting back in to Xfce. Ugh. C is such a pain in the ass. I keep reinventing wheels, because even if there's a third-party library, most of the time it's not packaged on many of the distros/OSes our users use. Memory leaks, NULL pointer dereferences, use-after-free, data races, terrible concurrency primitives, no tuples, no generics, primitive type system... I hate it.

I've been using Rust for other projects, and despite it being an objectively more difficult language to learn and use, I'm still much more productive in Rust than in C.

kstrauser2• 1 year ago

I think Rust is harder to learn, but once you grok it, I don't think it's harder to use, or at least to use correctly. It's hard to write correct C because the standard tooling doesn't give you much help beyond `-Wall`. Rust's normal error messages are delightfully helpful. For example, I just wrote some bad code and got:

    --> src/main.rs:45:34
     |
  45 |         actions.append(&mut func(opt.selected));
     |                             ---- ^^^^^^^^^^^^ expected `&str`, found `String`
     |                             |
     |                             arguments to this function are incorrect
     |
  help: consider borrowing here
     |
  45 |         actions.append(&mut func(&opt.selected));
     |

I even had to cheat a little to get that far, because my editor used rust-analyzer to flag the error before I had the chance to build the code.

Also, I highly recommend getting into the habit of running `cargo clippy` regularly. It's a wonderful tool for catching non-idiomatic code. I learned a lot from its suggestions on how I could improve my work.

kelnos11• 1 year ago

I think Rust is harder to learn, but once you grok it, I don't think it's harder to use, or at least to use correctly. It's hard to write correct C because the standard tooling doesn't give you much help beyond `-Wall`.

When I say Rust is harder to use (even after learning it decently well), what I mean is that it's still easier to write a pile of C code and get it to compile than it is to write a pile of Rust code and get it to compile.

The important difference is that the easier-written C code will have a bunch of bugs in it than the Rust code will. I think that's what I mean when I say Rust is harder to use, but I'm more productive in it: I have to do so much less debugging when writing Rust, and writing and debugging C code is more difficult and takes up more time than writing the Rust code (and doing whatever less debugging is necessary there).

Also, I highly recommend getting into the habit of running `cargo clippy` regularly. It's a wonderful tool for catching non-idiomatic code.

That's a great tip, and I usually forget to do so. On a couple of my personal projects, I have a CI step that fails the build if there are any clippy messages, but I don't use it for most of my personal projects. I do have a `cargo fmt --check` in my pre-commit hooks, but I should add clippy to that as well.

epidemian• 1 year ago

Also, I highly recommend getting into the habit of running `cargo clippy` regularly.

You can also have that hooked up to the editor, just like `cargo check` errors. I find this to be quite useful, because i hace a hard time getting into habits, especially for thing that i'm not forced to do in some way. It's important that those Clippy lints are shown as soft warnings instead of hard errors though, as otherwise they'd be too distracting at times.

crabbone2• 1 year ago

* Rust errors can be equally unhelpful. Also, the error you posted is hands down awful. It doesn't tell you what went wrong, and it's excessively naive to rely on compiler to offer a correct fix in all but the most trivial cases. When errors happen, it's a consequence of an impasse, a logical contradiction: two mutually exclusive arguments have been made: a file was assumed to exist, but was also assumed not to exist -- this is what's at the core of the error. The idiotic error that Rust compiler gave you doesn't say what were the assumptions, it just, essentially, tells you "here's the error, deal with it".

* In Rust, you will have to deal with a lot of unnecessary errors. The language is designed to make its users create a host of auxiliary entities: results, options, futures, tasks and so on. Instead of dealing with the "interesting" domain objects, the user of the language is mired in the "intricate interplay" between objects she doesn't care about. This is, in general, a woe of languages with extensive type systems, but in Rust it's a woe on a whole new level. Every program becomes a Sisyphean struggle to wrangle through all those unnecessary objects to finally get to write the actual code. Interestingly though, there's a tendency in a lot of programmers to like solving these useless problems instead of dealing with the objectives of their program (often because those objectives are boring or because programmers don't understand them, or because they have no influence over them).

mountainriver2• 1 year ago

Agree, Rust is quite hard to learn, but now that I know it I have a hard time writing anything else. It really gives you the best of a lot of worlds.

Granted I can still crank out a python program faster, that kinda works but god forbid you need to scale it or use any sort of concurrency at all.

seba_dos1• 1 year ago

It's hard to write correct C because the standard tooling doesn't give you much help beyond `-Wall`

I won't disagree that correct C is harder to write, but it's not 2005 anymore and standard tooling gives you access to things like asan, msan, ubsan, tsan, clang-tidy...

eikenberry• 1 year ago

Have you looked at Zig? It is often termed a modern C where Rust is the modern C++. Seems like a good fit.

harrison_clarke• 1 year ago

i never really understand why these get compared. i wouldn't expect that much overlap in the audiences

zig seems like someone wanted something between C and "the good parts" of C++, with the generations of cruft scrubbed out

rust seems like someone wanted a haskell-flavoured replacement for C++, and memory-safety

i would expect "zig for C++" to look more like D or Carbon than rust. and i'd expect "rust for C" to have memory safety and regions, and probably steal a few ocaml features

kelnos11• 1 year ago

I have, and I do find Zig impressive, but it doesn't go far enough for me. I don't want a "better C", I want a better systems language that can also scale up for other uses.

I like strong, featureful type systems and functional programming; Zig doesn't really fit the bill for me there. Rust is missing a few things I want (like higher-kinded types; GATs don't go far enough for me), but it's incredible how they've managed to build so many zero- and low-cost abstractions and make Rust feel like quite a high-level language sometimes.

jandrewrogers3• 1 year ago

Rust is not a modern C++, their core models are pretty different. Both Rust and C++ can do things the other can’t do. C++ is a more focused on low-level hyper-optimized systems programming, Rust is a bit higher level and has stronger guardrails but with performance closer to a classic systems language.

I do think Zig is a worthy successor to C and isn’t trying to be C++. I programmed in C for a long time and Zig has a long list of sensible features I wish C had back then. If C had been like Zig I might never have left C.

rat87• 1 year ago

Almost everyone wants to claim to be modern c and not modern C++ because everyone shit on C++

If anyone is the modern c++ its D. They have template metaprogramming while rust has generics and macros.

Rust doesn't have constructors or classes or overloading. I believe its type system is based on Hindley–Milner like ML or Haskell and traits are similar to Haskell type classes. Enums are like tagged Union/sum types in functional programming and rust uses Error/Option types like them. I believe rust macros were inspired by Scheme. And finally a lot of what makes it unique was inspired by Cyclone (an obscure excitemenal language that tried to be a safer C) and other obscure research languages.

I guess rust has RAII that's one major similar to c++. An there's probably some similarities in low level memory access abstraction patterns.

But I'd describe rust as more of an imperative non GC offshoot of MLs then a modern c++ evolution.

Sysreq2• 1 year ago

I will say the more recent additions to C++ at least have solved many of my long standing issues with that C-variant. Most of it was stuff that was long overdue. Like string formatting or a thread safe println. But even some of the stuff I didn’t think I would love has been amazing. Modules. Modules bro. Game changer. I’m all in. Honestly C++ is my go to for anything that isn’t just throw away again. Python will always be king of the single use scripts.

klysm• 1 year ago

The problem is that they are _additions_, C++ has such absurd sprawl. The interactions between everything in this massive sprawl is quite difficult to grasp

kelnos11• 1 year ago

I lost interest in keeping up with C++'s advances more than a decade ago.

The problem is that I want a language where things are safe by default. Many of the newer stuff added in C++ makes things safe, perhaps even to the level of Rust's guarantees -- but that's only if you use only these new things, and never -- even by accident -- use any of the older patterns.

I'd rather just learn a language without all that baggage.

BuckRogers• 1 year ago

That is very interesting. You have quite the resume too. While I've dabbled in nearly everything, I'm a day to day pro C# developer and I absolutely love it. I've never been upset or had a complaint. If I were forced off for some reason, I'd just go to Typescript. I can't imagine using C. Perhaps with some form of AI valgrind. The problems C solved are just not relevant any longer, and it remains entrenched in 2025. Rust with AI analysis will be amazing to see the results of.

tartoran2• 1 year ago

It depends on problem domain. If you're writing kernel level code or device drivers you wouldn't use C# or typescript.

codr715• 1 year ago

It looks to me like C is still very relevant, and isn't going anywhere anytime soon.

I realize a lot of people don't want to use it; and that's fine, don't use it.

samiv2• 1 year ago

The biggest problem with C is that doesn't even have enough features to help you build the features and abstractions you need and want.

For example with C++ the language offers enough functionality that you can create abstractions at any level, from low level bit manipulation to high level features such as automatic memory management, high level data objects etc.

With C you can never escape the low level details. Cursed to crawl.

ChrisMarshallNY3• 1 year ago

Just FYI.

Back in 1994/95, I wrote an API, in C, that was a communication interface. We had to use C, because it was the only language that had binary/link compatibility between compilers (the ones that we used).

We designed what I call "false object pattern." It used a C struct to simulate a dynamic object, complete with function pointers (that could be replaced, in implementation), and that gave us a "sorta/kinda" vtable.

Worked a charm. They were still using it, 25 years later.

That said, I don't really miss working at that level. I have been writing almost exclusively in Swift, since 2014.

gtirloni• 1 year ago

Of course you can. It's quite the opposite actually. The downside is that in C you have to code a bunch of abstractions _yourself_. See how large projects like the Linux kernel make extensive use of macros to implement an object system.

sim7c003• 1 year ago

so confused by this one. C is the most free to build systems and abstractions. it doesnt lock you down into any paradigm so you can build your own....

you can abstract away perfectly fine low level details and use your own high level constructs to build what you want in a memory safe way...

high level daya objects?

sure it doesnt have garbage collection, so it motivates you not to leave garbage laying around for some slow background process to collect.

actually you can build this in C you just do not want to...

you can give all your objects reference counters and build abstractions to use that, you can implement 'smart pointers' if u want, and have threads do garbage collection if u want... why not? what exactly is stopping you?

maybe its less convenient to go that route. but impossible? nope.

connect GDB to your c++ program and see how it works... its not like c++ suddenly doesnt become machine code. and c translates perfectly fine to machine code...

WalterBright8• 1 year ago

Memory leaks, NULL pointer dereferences, use-after-free

I suffered writing those for many years. I finally simply learned not to do them anymore. Sort of like there's a grain of sand on the bottom of my foot and the skin just sort of entombed it in a callous.

kelnos11• 1 year ago

I've seen you make these kinds of comments before on other articles. Please stop. Not everyone is perfect and can forevermore avoid making any mistakes. I strongly suspect your opinion of your skill here is overinflated. Even if it isn't, and you really are that good, everyone cannot be in the top 0.00001% of all programmers out there, so your suggestion to "simply" learn not to make mistakes is useless.

This all just comes off incredibly arrogant, if I'm being honest.

usamoi• 1 year ago

This is actually quite easy to achieve, as long as you cannot realize your own mistakes.

quchen• 1 year ago

Thank you for your work on XFCE. It's been the best WM/UI for me for over a decade.

jakogut• 1 year ago

Similarly, I went from writing a lot of C to Python, and I appreciate both of them for almost opposite reasons. I ended up finding I like Cython quite a bit, even though the syntax leaves much to be desired. The power, performance, and flexibility of C combined with the batteries included nature of Python is a match made in heaven.

You're also still very much free to write either language purely, and "glue" them together easily using Cython.

mrheosuper3• 1 year ago

I Really want to use Rust. But Rust has so many std functions that kind of abstracting how does it work under the hood

For Ex: I still has no idea what clone() does, how does it interact with memory, on heap or stack , does it create a new instance, or just modify metadata of that object. Sometime creating a new instance is a big no-no because it takes a lot of memory.

Same thing with "ownership transfer", is variable freed at that moment, etc.

I bet i could find answers on internet, but rust has like 500 std functions, so the task is tedious

jpc05• 1 year ago

What is your current language of choice, both C and C++ have the same problems as what you just described.

Regarding ownership transfer it is even worse in C, what if you forget, after moving an object out of a variable, to set that variable to NULL, then free that variable, that's a use after free. At least in C++ you have move semantics although it is still error prone. In rust it's a compiler error.

Copy and Clone is the same, and both are opt-in for your own types, by default the only options are move or reference for your own types, in C and C++ by default it is copy, which again leads to use after free in the situations you complained about.

I feel if these are your complaints you will actually benefit from spending some time in Rust.

If your preferred language is higher level languages with GC that is reference by default I encourage you to try any of the systems level programming languages, the things you complain about are things that are important for a language to have constructs for, reference semabtics by default causes many issues, and becomes untenable in the parallel world we live in.

doublerabbit• 1 year ago

Lately I've been paying interest in D being from PERL/TCL background. Rust, Python, Go just feel tainted to me.

https://dlang.org

tealpod• 1 year ago

Dlang is a clean langauge. Unfortunately it never got the attention it deserves.

cryptonector2• 1 year ago

But TFA is not writing in C. TFA is writing in a language that compiles to C.

ein0p• 1 year ago

At this point one should choose a C-like subset of Rust, if they have this particular urge. A lot fewer rakes under the leaves.

WhereIsTheTruth• 1 year ago

I'm on the same boat, i now use exclusively C, and D (with the -betterC flag) for my own projects

I refuse to touch anything else, but i keep an eye on the new languages that are being worked on, Zig for example

henning• 1 year ago

Defensive programming all the way : all bugs are reduced to zero right from the start

Has it been fuzzed? Have you had someone who is very good at finding bugs in C code look at it carefully? It is understandable if the answer to one or both is "no". But we should be careful about the claims we make about code.

Yie1cho2• 1 year ago

he may be good at C but not that good. no one's that good. and this stupid overconfidence leads to sec holes.

fungiblecog• 1 year ago

So nobody would use code written in common lisp... but they will use code written in an entirely new language.... right...

codr715• 1 year ago

I love Common Lisp, but I would definitely think twice before implementing anything I want other people to use on their machines in it. A tiny C executable is pretty nimble in comparison to anything you'll get out of Common Lisp.

vindarel• 1 year ago

I understand, it isn't that bad though: a web app of mine with dozens of dependencies and all templates and static assets is 35MB with SBCL and core compression (that includes the compiler and debugger, useful to connect to a running app and exploring its state (or even hot reloading code)). I suppose that's in the ballpark of a growing Go application. LispWorks has a tree shaker that builds a hello world in 5MB.

tmtvl• 1 year ago

Eh, you can just distribute a .lisp file as though it were a ruby or perl script. CL is faster than the usual scripting languages, but admittedly not as fast as C or Rust.

Yie1cho2• 1 year ago

"and all was bounds-checked at memory cost but the results were awesome. Defensive programming all the way : all bugs are reduced to zero right from the start."

a bit LOL, isn't it?

also the part about terraform, ansible and the other stuff.

ternaryoperator• 1 year ago

In the abstract, the simplicity of C has a definite appeal. However, pragmatically, the sense that I am mowing the lawn with a pair of scissors gets tiring quickly.

BirAdam• 1 year ago

Linux/UNIX distributions are essentially C development environments, and their package managers are basically C language package managers… so, you needn’t do everything yourself, just grab the source packages.

ustad• 1 year ago

Tools should enable creativity and problem-solving, not become problems themselves. The best languages fade into the background, becoming almost invisible as you express your solution. When the language constantly demands center stage, something has gone fundamentally wrong with its design philosophy.

codedokode6• 1 year ago

Writing code in C is very unpleasant, verbose and repetative. For example, if I want to have a structure in C and have a way to print its contents, or free its memory and memory of nested structures, or clone it recursively, it is very difficult to make automatically. I found only two options: either write complicated macros to define the structure and functions (feels like writing a C++ compiler from scratch), or define structure in Python and generate the C code from it.

I looked at C++, but it seems that despite being more feature-rich, it also cannot auto-generate functions/methods for working with structures?

Also returning errors with dynamically allocated strings (and freeing them) makes functions bloated.

Also Gnome infrastructure (GObject, GTK and friends) requires writing so much code that I feel sorry for people writing Gnome.

Also, how do you install dependencies in C? How do you lock a specific version (or range of versions) of a dependency with specific build options, for example?

codr715• 1 year ago

Simplify.

If you try to write the same complicated mess in C as you would in any other language it's going to hurt.

Not having a package manager can be a blessing, depends on your perspective.

int_19h15• 1 year ago

There's no amount of simplification that'll free you from the need to manually check and handle/propagate errors or deallocate resources in C. You might be able to reduce the amount of code you need to write, but it's still several lines of C versus one line of something else - and if you make a mistake or even forget something in those several lines, things will often compile and run fine, but you'll have memory leaks or sporadic crashes.

neuroelectron• 1 year ago

What's with the toggle grid at the bottom of the article? Is it just a fidget toy?

moron4hire2• 1 year ago

About a year ago, I had gotten fed up with what felt like overlyb strict context requirements basically giving me to abandon years of work and thought I'd try my hand at C++ again.

I wanted to do this on Linux, because I my main laptop is a Linux machine after my children confiscated my Windows laptop to play Minecraft with the only decent GPU in the house.

And I just couldn't get past the tooling. I could not get through to anything that felt like a build setup that I'd be able to replicate in my own.

On Windows, using Visual Studio, it's not that bad. It's a little annoying compared to a .NET project, and there are a lot more settings to worry about, but at the end of the day VS makes the two but very different from each other.

I actually didn't understand that until I tried to write C++ on Linux. I thought C++ on Windows was worlds different than C#. But now I've seen the light.

I honestly don't know how people do development with on Linux. Make, Cmake, all of that stuff, is so bad.

IDK, maybe someone will come along and tell me, "oh, no, do this and you'll have no problems". I hope so. But without that, what a disgusting waste of time C and C++ is on Linux.

edye• 1 year ago

I find make, cmake, and the other stuff annoying also. For personal stuff I just use a build.sh file. For debugging I use gf2, which is a gdb frontend. Hopefully raddebugger gets ported to linux soon. One nice tool I like on linux for prototyping is the tiny c compiler, because it compiles 7x faster than gcc or clang. It is also much faster than the visual studio compiler. I remember trying to get the tiny c compiler to work on windows; it can compile things, but I couldn't get it to generate pdb files for debug info.

moron4hire2• 1 year ago

Wow, I'm surprised you were able to make out what I was saying through all those drunk smartphone keyboard typos (it's the keyboard that was drunk, not me, no sir).

I just don't understand why people want to live like that in C++ land. It almost feels like masochism. Especially considering VC++ basically "just works" in comparison. Why do Linux users hate DevEx so much?

davidwf2• 1 year ago

The last time I was writing C professionally I used ceedling (https://www.throwtheswitch.org/ceedling) and I highly recommend it. I hate cmake too. :-)

teleforce• 1 year ago

Garbage collectors suck, and all my Common Lisp projects have very limited applications just because of the garbage collector.

If only a very tiny fraction of the resources effort, research, time, money etc of all ML/AI funds are directed for the best design of high performance GC, it will make a software world a much better place. The fact that we have a very few books dedicated on GC design and thousands of books now dedicated on AI/ML, it is quite telling.

For real-world example and analogy, automotive industry dedicated their resources on the best design of high performance automatic transmission and now it has a faster auto transmission than manual for rally and racing. For normal driving auto is what the default and available now, most of the cars do not sell in manual transmission version.

Linux is written in C, OpenBSD is written in C, GTK+ is object-oriented pure C, GNOME is written in C. Most of the Linux desktop apps are actually written in plain old C. So why try harder ? I know C

C is the lingua-franca of all other programming languages including Python, Julia, Rust, etc. Period.

D language has already bite the bullet and made C built-in by natively supporting it. Genius.

D language also has GC by default for more sane and intuitive programming, it's your call. It also one of the fastest compilation time and execution time languages in existence.

From the KC3 language website, "KC3 is a programming language with meta-programmation and a graph database embedded into the language."

Why you want to have a graph database embedded into the language? Just support associative array built-in since it has been proven to be the basis of all common data representations of spreadsheet, SQL, NoSQL, matrices, Graph database, etc.

[1] Associative Array Model of SQL, NoSQL, and NewSQL Databases:

https://arxiv.org/pdf/1606.05797

[2] Mathematics of Big Data: Spreadsheets, Databases, Matrices, and Graphs:

https://mitpress.mit.edu/9780262038393/mathematics-of-big-da...

cryptonector2• 1 year ago

It was supposed to be a short mission I thought I could learn Common Lisp in ten days and hack a quick server management protocol. I ended up writing throw-away Common Lisp code that generated C for a fully-fledged ASN.1 parser and query system for a custom Common Lisp to C SNMP server.

I believe it. And I'd love to see it and hack on it, if it were open source.

This whole kc3 thing looks pretty interesting to me. I agree with the premise. It's really just another super-C that's not C++, but that's a pretty good idea for a lot of things because the C ABI is just so omnipresent.

mistyvales• 1 year ago

What's the best way to learn C? Any good modern book recommendations, or sites?

Lyngbakr• 1 year ago

There's a second edition of the legendary K&R book¹ to get you started.

¹https://www.amazon.com/Programming-Language-2nd-Brian-Kernig...

armitron2• 1 year ago

See my previous comment, anyone learning C from K&R should not be writing C period.

That book is legendary only in the magnitude of financial damages it (directly and indirectly) enabled, caused by people who read it and thought that they could now write C.

davidwf2• 1 year ago

I highly recommend Zed Shaw's "Learn C the Hard Way": https://learncodethehardway.org/c/

I worked through this and felt well-prepared to actually use C in anger when I had to.

armitron2• 1 year ago

Terrible overall and entirely wrong in multiple places. If you learn C from this book, you should't be writing C.

The last bit is also true for K&R The C Programming Language (avoid at all costs).

You're better off with:

- Modern C (whatever edition is current)

- Seacord's Effective C: Introduction to professional C programming

- C Programming: Modern Approach 2nd edition (bible)

lemonwaterlime• 1 year ago

I second "Modern C" by Jen Gustedt.

- Get the `cdecl` tool to build intuition about function signatures. What does "int( * ( *foo)(void))[3]" mean?

- Write it yourself.

- Be disciplined. Develop good hygiene with compiler flags, memory/address checks, and even fuzzing.

- Read good source code such as the linux kernel. This is an amusing header file from the git source code that defines some banned functions. This is wisdom if you choose to follow it: https://github.com/git/git/blob/master/banned.h

- Push the language to its limits. Play with memory and data structures. Inspect everything. This book "Data-Oriented Design" by Richard Fabien is a great to explore as well. It's about organizing your data for efficient processing.

DeathArrow3• 1 year ago

I still think in the right tool for the job. Trying to write some web application in C will drive me mad. Also will trying to write some low level stuff in Java.

Tractor8626• 1 year ago

Nothing make sense.

What is your killer app? What CL has to do with no one running it? What problem you had with garbage collectors? Why is C is the only option? Are you sure all those RCEs because of VMs and containers and not because it all written in C? "There are no security implications of running KC3 code" - are you sure?

daitangio• 1 year ago

Java was created to solve some frequent troubles you have in C-code.

I do not want to be rude, but C has some error-prone syntax: if you forget a *, you will be in trouble. If you do 1 byte offset error on an array in the stack, you get erratic behavior, core dump if you are lucky.

Buffer overlflows also poses security risks.

try...catch was not present on C, and it is one of the most powerful addition of C++ for code structuring.

Thread management/async programming without support from the language (which is fine, but if you see Erlang or Java, they have far more support for thread monitors).

Said that, there are very high quality library in C (pthreads, memory management and protection, lib-eventio etc) which can overcome most of its limit but... it is still error-prone

intrasight• 1 year ago

I learned computer engineering bottom-up and top-down. Bottom-up as a teen reading books and manuals. Since no one I knew had an actual computer in 1979, like Ada Lovelace, I built the computers in my mind, LOL. Then in college I did some top-down too by writing C and then compiling to assembly and then compiling to machine code.

we also had to build a CPU from discrete bit-slice components and then program it. One of the most time intensive courses I took at CMU. Do computer engineers still have to do that?

I would certainly encourage all computer engineers, and perhaps even software engineers, to learn the "full stack".

But as to programming and C, I haven't done that in almost 30 years. It would be an interesting experiment to see how much of that skill if any I still possess.

aadhavans• 1 year ago

For those who like C because of the simplicity, I can wholeheartedly recommend Go. It's replaced C as my go-to for personal CLI projects - while it is more complex than C, the core language features fit in my head pretty well. Add to that the excellent tooling, primitive OOP and clean syntax, and it's a damn good replacement.

le-mark• 1 year ago

GLib is a general-purpose, portable utility library, which provides many useful data types, macros, type conversions, string utilities, file utilities, a mainloop abstraction, and so on.

Glib is c batteries included library I really like. Does anyone have any others they prefer?

https://docs.gtk.org/glib/

cassepipe• 1 year ago

I did come back to C after some years. I liked it because it made me suffer but in the I prevailed so I felt good about it. Now that I am back at it I remember all the pain of trying to enforce abstractions at compile-time with the C preprocessor. I am now considering Zig or suicide.

gatane• 1 year ago

C++ has long compilation times, when you have long code base.

account-5• 1 year ago

Is this about C or Common Lisp? I'm confused the title suggest C but common lisp appears to be what the article is about.

las_balas_tres• 1 year ago

I started writing C code again because i started using gstreamer and needed to write a modem plugin for ModemManager. This meant i had to get familiar with glib. Even thought the learning curve has been steep it been worth and I am really enjoying writing in C again, even going so far as to refactor some existing code of mine use glib and make it GObject based. The end goal here is to use gir to use my code from scriptable languages like python.

Sunspark• 1 year ago

Without reading the comments here, I read the blog entry first.

After I finished I was puzzled, "what is the author trying to communicate to the reader here?"

As near as I can determine, enough people weren't using the author's program/utility because it was written in a language that hasn't been blessed by the crowd? It is hinted at that there might be issues involving memory consumption.

The author does not write lessons learned or share statistics of user uptake after the re-write.

No new functionality was gained, presumably this exercise was done as practice reps because the author could do it and had time.

No argument was made that the author has seen the light and now only C from this point on.

sim7c003• 1 year ago

love this sentiment. i tried a lot of languages after C, and am also back to C. it does force me to pencil out all kinds of stuff rather than relying on third party code or compiler error help, but i find that delightful. good upfront coding on a piece of paper, slowly (compared to other langs) implementing it, and diligently testing because you know its very needed in C. it forces you to do things right, and if you do you get an ultimate reward. blazin fast , well behaved code.

yes, my life is still full of segfaults as many segfaults as ignorance and impatience. so its delightful because it helps me overcome those 2 things, slowly and steadily =)

bob1029• 1 year ago

who can write a strategy game with thousands of units each having their own vision of the world, without having a garbage collector running like hell

Even in ecosystems where you don't have a way to opt-out of GC, there are strategies for dramatically minimizing the impact. Just because you have some aspects of the product rely on it should not be fatal unless we are being a bit hyperbolic about the purity of tech. If your allocation rate is <1 megabyte per minute and you are expressly forcing GC to run along the grain of the allocations (i.e., after each frame or sim tick), then it is exceedingly unlikely you will experience the canonical multiple-second, stop-the-world GC boogeyman.

Additionally, I don't think this is a fair take on how an RTS game would be engineered in practice. Each unit should be part of a big contiguous array in memory somewhere. The collection of garbage can be made largely irrelevant in the scenario of managing game state if you are willing to employ approximately the same approach you'd use in many other languages. Nothing stops you from newing up a 2 gig byte array and handing out spans to consumers just because you have GC turned on.

I stopped everything and started writing C again

Related Stories