I stopped everything and started writing C again

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.

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.

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.

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/...

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.

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.

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.

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.

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

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?

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.

> 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/

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

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.

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

Just pick the right projects and the language shines.

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.

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.

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

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.

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?

> 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.

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?

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.

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.

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

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

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.

> 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...

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.

> 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/

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.

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 =)

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

"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.

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.

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.

I've read through your website and thinking processes.

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

504 Gateway Timeout

Archived at https://archive.is/zIZ8S

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

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

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.

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

> 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.

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.

> 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.