tamnd

Sorry you felt that way.

Which parts did you feel were missing or didn't live up to the title? What kind of points or examples would have made it feel more worthwhile to you?

I see it a bit differently. Zig's toolchain is self-contained: one binary gives you the compiler, build system, cross-compilers, and a package manager. It doesnt depend on the system toolchain, which makes builds reproducible and easy to move between machines.

C's ecosystem is the opposite. It is modular, built from separate tools like GCC, ld, Make, and apt. You compose them externally.

And it could be used as drop in replacement for gcc/clang

https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

> [2] the best I've seen is to run within a Docker container with that glibc version installed.

Agreed. I will revise that section tomorrow. Also, for compiling Go with CGO enabled, using Docker is the only reliable way to produce a binary correctly linked against glibc, especially when working with RHEL.

Yes, I wrote that because of the interesting discussion here, not because of the article content.

> I'm sure I'm not alone - after decades - already knowing far too much about C, so that any article I'm likely to read either I'm like "No, that's wrong and I even understand why you thought that, but it's still wrong" or I just nod along and sigh.

If you have some spare time, I would really like to hear more about your experiences. It sounds like you have worked with C for a long time, and that kind of insight is hard to find now.

Most people around me started with JavaScript or TypeScript as their first language, and for many, that is still all they know. I mean no disrespect, it is just how things are today. It would be great to hear how your view of programming has changed over the years and what lessons from C still matter in your work today.

Thanks for sharing your thoughts. I have never deployed any production C code and I would not choose C for professional work either, but learning it, with all its rough edges, has made me a better engineer. It helps me understand how things really work under the hood. No pain, no gain.

Maybe I am biased, but for professional work, I stay with Go. I have built large distributed data systems that handle hundreds of millions of business transactions daily, and Go has been steady and reliable for that scale. Its simplicity, strong concurrency model, and easy deployment make it practical for production systems. I still enjoy exploring Zig and Rust in my spare time, but for shipping real systems, Go continues to get the job done without getting in the way.

and my favorites:

   - https://daniel.haxx.se/blog/2025/04/07/writing-c-for-curl/
   - https://www.sqlite.org/whyc.html

Here is the link for you: https://github.com/little-book-of/c/blob/main/articles/zig-i...

I hope next month I will have more time to write deep dives into the internals of SQLite, PostgreSQL, Redis and maybe curl, all written in C.

I started learning C again for one simple reason: to understand the Linux kernel. You cannot do that without knowing C, and soon you end up learning about GCC, linkers, and how programs really run.

Once I spent time with it, I saw how many smart ideas from the kernel could be used anywhere. the initcall system that runs modules in order, the way structs with function pointers create flexible drivers, the use of macros to build type-safe lists and so on.

https://www.collabora.com/news-and-blog/blog/2020/07/14/intr...

For real work, though, life is short. I use Go.

Have you tried C23, especially its new Unicode support? It really surprised me after returning to C more than ten years later.

You can now write wide and UTF-8 string literals directly:

    char8_t* s = u8"こんにちは";
    char16_t* t = u"Привет";
    char32_t* ustr = U"你好";

It just works across compilers, no special libraries or hacks needed.

C still feels like C, but cleaner, safer, and more consistent.

Oh, and I just submitted a link to my article about C. I am pretty sure no one will click it.

Articles about C never get much traffic, but that is fine. I wrote it because I care about how things really work, not because I expect it to trend. If even a few people read it and see the beauty in the old language that still runs the world, that is enough.

I have learned that too. If you write about C, almost no one clicks. It is not new, it is not flashy, and it does not promise easy results. Yet almost everything still runs on it. The quiet parts of computing rarely get attention, even though they keep everything working.

I still write about C anyway. It may not trend, but it lasts.

Zig is so cool, but C is cooler.

I like how Zig feels clear and simple to start with. I like that it gives one toolchain and makes cross compilation easy. I like that it helps people see how systems programming can feel approachable again.

I also like that C has done these things for many years. I can use different tools, link libraries, and trust that it will still work. I can depend on standards that keep improving while staying familiar.

I think Zig is exciting for what it adds today. I think C is cooler because it has proved itself everywhere and still runs the world.

> Could you elaborate a bit on this?

Please correct me if I am wrong, I have not touched this subject in a long time and only have some intuition. Here is how I understand it:

A manifold is a kind of space that looks flat when you zoom in close enough. The surface of a sphere or a doughnut is a 2D manifold, and the space we live in is a 3D manifold. A Calabi Yau is one of these spaces but with more dimensions and extra symmetry that makes it very special.

In geometry there are several ways to describe curvature. The most complete one is the Riemann curvature tensor, which contains all the information about how space bends. If you take a specific kind of average of that, you get the Ricci curvature tensor. Ricci curvature tells you how the size of small regions in space changes compared to what would happen in flat space.

Imagine a tiny ball floating in this curved space. If the Ricci curvature is positive, nearby paths tend to come together and the ball’s volume becomes smaller than it would in flat space. If the Ricci curvature is negative, nearby paths move apart and the ball’s volume grows larger. If the Ricci curvature is zero, the ball keeps the same volume overall. So when I said “the space does not stretch or shrink overall” I was describing this situation: the Ricci curvature is zero, which means the space does not expand or contract on average compared to flat space.

The space can still have complicated twists and bends. Ricci curvature only measures a certain type of curvature related to volume change. Even if the Ricci tensor is zero, there can still be other kinds of curvature present. The curvature balances out is just an intuitive way to express that the volume effects cancel when you take the average that defines Ricci curvature. It does not mean the space has matching regions of positive and negative curvature in a literal sense, but rather that the mathematical combination producing Ricci curvature sums to zero.

Noe back to definition: A Calabi-Yau manifold is defined as compact (finite in size), complex), and Kähler (it has a compatible geometric and complex structure), with a first Chern class equal to zero. Yau’s theorem proves that such a space always has a way to measure distances so that its Ricci curvature is exactly zero. So when I said “the curvature balances out perfectly so the space does not stretch or shrink overall” I meant it as an intuitive description of this Ricci flat property. The space is not flat like a sheet of paper, but its internal geometry is perfectly balanced in the sense that there is no net expansion or contraction of space.

> Do you know if there's any experimental evidence of this?

As my knowledge, there is no direct evidence that Calabi Yau manifolds describe real extra dimensions. In string theory, these shapes are used because they fit the math and preserve symmetries like supersymmetry. Experiments have not found signs of extra dimensions or supersymmetric particles, so Calabi Yau manifolds remain a beautiful theoretical idea, not something confirmed by observation.

That's a great suggestion. I actually started with Topological Manifolds before moving on to Introduction to Smooth Manifolds and it really helped build a solid foundation.

I havent read Loring Tus books before but let me look at them since I have been wanting to revisit the topic with a clearer and more relaxed approach.

I learned about Calabi Yau manifolds a long time ago and have forgotten most of the details, but I still remember how hard the topic felt. A Calabi Yau manifold is a special kind of geometric space that is smooth curved and very symmetrical. You can think of it as a shape that looks flat when you zoom in close but can twist and fold in complex ways when you look at the whole thing.

What makes Calabi Yau manifolds special is that their curvature balances out perfectly so the space does not stretch or shrink overall.

In physics especially in string theory Calabi Yau manifolds are used to describe extra hidden dimensions of the universe beyond the three we can see. The shape of a Calabi Yau manifold affects how particles and forces behave which is why both mathematicians and physicists study them.

I first learned about manifolds through Introduction to Smooth Manifolds by John M. Lee. The book is dense but beautifully structured, guiding you from basic topology to smooth maps and tangent spaces with clear logic. It demands focus, yet every definition builds toward a deeper picture of how geometry works beneath the surface. Highly recommended.

After finishing this book, I think extracting the Go code into a ready-to-use data structures and algorithms library could be a nice idea. I feel confident writing production-grade Go code, so it would be interesting to shape the examples into something practical and reusable beyond just learning exercises.

Before generics, Go sorting usually looked like this:

type ByValue []int

func (a ByValue) Len() int { return len(a) } func (a ByValue) Swap(i, j int) { a[i], a[j] = a[j], a[i] } func (a ByValue) Less(i, j int) bool { return a[i] < a[j] }

sort.Sort(ByValue(a))

It worked fine but felt a bit awkward for small programs. After Go 1.18, you can do it directly with generics:

s := []int{3, 1, 4, 1, 5, 9} slices.Sort(s)

Much simpler and expressive, yet still type safe. I really like how Go kept it minimal without adding too many abstractions.

Thanks for the very well written and detailed explanation! I think from your comment I finally see a clearer path to a better implementation. Based on my own experience, I will probably start by writing it in Go first (that is the language I can think in most naturally), and then try to reason about how to make an idiomatic C version afterward, which will be interesting since I have not really written C in about 15 years.

I am not an expert but have been learning RISC-V Assembly in my backlog for some years now. https://riscv-programming.org/

Feels like what x86 could have been if it started clean.

So I will stick with C. Recently, when I updated my very old knowledge, I noticed that C23 is actually pretty nice. It adds proper Unicode support, typeof and constexpr style keywords, improved atomics, and even better support for inline functions and generics.

That is also why in TAOCP, Don Knuth used MIX (and later MMIX) to keep the book language agnostic and timeless. Before Knuth's birthday next year, I am hoping to finish most of the exercises in TAOCP.

For assembly, by any chance, do you like the "pink shirt" book? It is one of my all-time favorites! I learned so much from it back in the day. Sadly, I lost my copy somewhere along the way :(

https://deprogrammaticaipsum.com/peter-norton/

Was the very first edition of Sedgewick's Algorithms written in Pascal? I heard that but never actually saw that version myself.

Your comment brought back an old memory for me. My first programming language in high school was Turbo Pascal. That IDE was amazing: instant compilation, the blue screen TUI, F1 for inline help, a surprisingly good debugger, and it just felt so smooth and fast back then. No internet needed, no AI assistance, just pure focus and curiosity. Oh, how I really miss those days :)

Another reason for writing the book is that many developers see "algorithms" as something only needed for FAANG interviews, not for real work. For beginners and even seniors, learning algorithms often just means doing LeetCode problems, which most people dislike but feel forced to do.

I want to change that view and show that algorithms are beautiful and useful beyond interviews. They appear everywhere, from compilers to databases to the Linux kernel, where I found many interesting data structures worth exploring. (i will share more about this topic later)

I hope to share more of these insights and connect with others who enjoy discussing real world algorithm design, which is what I love most about the Hacker News community (except for the occasional trolls that show up from time to time).

For more context, I actually used The Algorithms as a reference when working on my own programming language, Mochi, which includes around 150–300 algorithms (I don't remember exactly) implemented directly in Mochi. These are then transpiled to over 25 programming languages such as C, Haskell, Java, Go, Scala, and more: https://github.com/mochilang/mochi/tree/main/tests/algorithm...

The VM and transpiler were originally implemented by hand, and later I used Codex to help polish the code. The generated output works, though it is a bit messy in places. Hopefully, after finishing a few books, I can return to the project with more experience and add better use cases for it.

Those algorithms implement so random to me, with lack of explanation, no test cases, no formal proof, and often inconsistent naming or structure across languages. Many repositories like TheAlgorithms are great collections, but they feel more like code dumps than true learning resources. You can find an implementation of Dijkstra or QuickSort, but often there is no context: why it works, how to prove it correct, what the complexity is, or how to test it against edge cases. For someone who wants to learn algorithms deeply, that missing layer of reasoning and validation is critical.

No organization for learners either. It jumps straight into implementations without a logical flow from fundamentals. I want to build something more structured: start from the very foundation (like data structures, recursion, and complexity analysis), then move to classical algorithms (search, sort, graph, dynamic programming), and eventually extend to database internals, optimization, and even machine learning or AI algorithms. Basically, a single consistent roadmap from beginner to researcher level, where every algorithm connects to the next and builds intuition step by step.

Another very good resource for beginners is https://www.hello-algo.com. At first, i actually wanted to contribute there, since it explains algorithms visually and in simple language. But it mostly covers the basics and stops before more advanced or applied topics. I want to go deeper and treat algorithms as both code and theory, with mathematical rigor and formal proofs where possible. That is something I really liked about Introduction to Algorithms (CLRS) and of course The Art of Computer Programming (TAOCP) by Knuth. They combine reasoning, math, and practice. My goal is to make something in that spirit, but more practical and modern, bridging the gap between academic books and messy open source repos.

I hope the next generation learns to love "C" and Algorithms again. I have rediscovered my appreciation for C recently, even though Go is my main professional programming language.