DEV Community: Anshuman Khanna

C the right way to program part 2

Anshuman Khanna — Sun, 13 Jul 2025 21:42:05 +0000

I have been learning C and it has come to my notice that there are a lot of good things about C that modern languages seemed to have ditched and they are just better in C. Let's go over them one by one.

Errors as values

In languages like JavaScript and Python we have try-catch or try-except block that is used to handle errors which seems smart to do until you realise how badly it scales. Creating a block doesn't make sense for every function that can error and not creating multiple blocks would lead you to have bad error handling.

Seeing this problem, languages like Go & Zig have introduced a magical thing called errors as values and I want you to sense my sarcasm as I am saying this.

Let's see how C handles errors straight up by using the linux man pages.

Let's look at another example but this time something more epic.

Why is this more epic? Because there are functions like this and you never know about them because your language hides everything and all you know is that the function failed.

Every error in C is a value that is returned from the function and it is invalid value that can't be used. By doing this, we don't need any fancy underlying system. This makes it simple for even the compiler. Do you know why?

Imagine if you have to return a fancy error that screams that I am an error, you'll probably have to do something like this (using zig as an example):

const IntOutput = struct {
    type: enum {
        Error,
        Ok,
    },
    value: union {
        success: i32,
        failure: i32,
    },
};

Now we have predefined errors in Zig and you'll probably not have to write errors like this because there is better syntax for this in Zig and the code above is just to show how the language works internally. When your function throws an error, this is how the program knows that it has throwed an error, using a union.

This is clearly a lot more work compared to just returning a value and knowing what the error is.

Pointers and References

For this one, let me test you first. You have to tell in the snippet below whether this function body is using the variable coordinate as a reference or value.

struct Coordinates {
    int x;
    int y;
};

// function body start
{
    // coordinate is of type Coordinates
    coordinate.x += 1;
    some_other_function(coordinate);
    // rest of the body
}

If I don't show you the function's arguments, you can never know, whether this function is modifying the original coordinate or a copy of it. By seeing the first line you may assume that we must be using reference since we are updating the coordinate, but as you see the second line, now you may think that maybe this update is just for this second function. You can never know without seeing the function argument.

Let's C the same code in C.

typedef struct {
    int x;
    int y;
} Coordinates;

// function body start
{
    // coordinate is of type Coordinates
    coordinate -> x += 1; // if it a reference
    coordinate.x = 1; if it a value

    some_other_function(coordinate); // if coordinate is a reference and both functions use reference, or if it's a value and both functions use value
    some_other_function(*coordinate); // if coordinate is a reference and this function wants value
    some_other_function(&coordinate); // if coordinate is a value and this function wants a reference
}

This is so much more clear. In every line of use, I know if the variable is a value or a reference. C is so ridiculously clear about each and every operation. Now, Rust does kind of make it better because when you are passing the function argument you have to pass it using & if you are passing a reference, but in the function body itself, it's the same as C++.

Dynamic languages are even worse which just always pass a reference and never actually allow you to pass value which is annoying when you have to do it.

Generics

Now we enter a serious domain. C supports generics using void * which basically means that it doesn't support generics and it just telling you to handle everything by yourself. Experts will argue that C23 has _Generic, which as far as I have seen is overloading and not generics. I could do what that does with enum and union. I haven't used it in any code yet and I don't know when I will.

But C not having generics like in some languages like TypeScript is actually very awesome. Generics can often make you lazy because you write a small piece of code that has no type information and hence can not be optimized at compile time and if you really think very hard about it, maybe, you didn't need it.

Supporting any type makes the support for any one type, weak. You don't realize the cost of this generic function running because it was so easy to type.

C made me realize, my software doesn't need to solve 100 problems, it just needs to solve 1 million cases of 1 problem.

I don't need to write a generic that can support any type, when in my code the generic function will only ever interact with at max 3 types. I can write an overloaded code for those three types (which is still kind of a problem but I have a love hate relationship with overloading so I'll let it go).

Async / await is the bane of software

I first want you to notice that this is the only title with a personal comment, this is how serious I am about this one. Let's see why.

Tell me, is this TypeScript code, sync or async:

const result = await fetch("i_hate_promises.ai")
console.log(result);

Some people are going to say, this is asynchronous code as we have used await. But the whole point of asynchronous is to do it later, but I did it instantly, until the fetch doesn't return, the thread is blocked (i.e. the program is stopped) which clearly means this is a synchronous piece of code.

This is the issue number 1, even though the code is synchronous, it looks asynchronous because of the await keyword. This is so confusing. This is how most people write code and they think they are using asynchronous programming, no, you are still working in synchronous domain, because the thread is blocked when you use await.

Issue number 2, which is even greater. await doesn't stop the runtime from creating a promise. fetch() is not going to be executed in async clearly, it is returning and the output is used, until then, the thread is blocked, so why are you creating a promise object, just skip that and return the actual value. Instead, fetch() returns a promise, await then extracts the output from this promise and destroys this promise. You created an object and destroyed in the next millisecond. Why was that object created when it was never required?

In C, you have none of this because to do async, you have to implement an async specific to your issue. You will not create any redundant objects, by default, everything is going to block and that's the behavior you actually want most of the time.

I am not saying use C for everything, but clearly the modern languages have some wrong ideas about how things need to be done and it's half because the creators made it too easy for you and half because no one questions this.

Understand this, try C, follow me.

Note: This is a raw article, I am not going to reread or edit it, so if you find any faults in it, just create a PR.

Your software is lying to you

Anshuman Khanna — Sat, 31 May 2025 19:46:56 +0000

A very nice thing about our modern languages is that they abstract a lot of the stuff that used to be done manually. However, they didn't automate it, the abstracted it and that's an issue that you don't realize.

Now firstly, let's make the difference clear and why it matters.

Let's say I have to allocate memory in a program. This is how C does it:

    int* arr = (int *) malloc(size * sizeof(int));

    if (arr == NULL) {
        // at this point *errno* is populated which can be seen using this.
        printf("Error occured during allocation: %s\n", strerr(errno));

        // This error is most probably: ENOMEM which means that there is no memory to allocate.
    }

Now, if I study C, I will learn that memory allocation can fail and this is the error it returns. Moreover, I also learn why does this error happen. It is because your hardware has two kinds of limits. The first limit is a soft limit that your kernel enforces and then there is a hard limit that is the ceiling of your soft limit. So, what I learn is that kernel allows us to allocate memory in soft limit -> [0, hard limit].

Now let's see what does Python do:

    a = []

This is what you would do because this is what the Python docs tell you to do. Now let's see what you actually need to do.

try:
    my_list = [0] * size
except MemoryError:
    print(f"Error: Could not allocate a list of size {size}. Ran out of memory!")

print(my_list)

But will Python tell you this? NO. Why not? Because it hides all this from you to give an illusion of simplicity until one day that you get a crash and have to manually go down the rabbit hole trashing your years of knowledge.

The same is true for any language that let's you do dynamic memory allocation without realizing that it's dynamic memory allocation.

malloc() in C is an automation of assigning data which is harder to do in Assembly. It still tells you the risk and doesn't hide them. Python dynamic allocation is an abstraction that doesn't tell you anything.

Now it's not just about dynamic memory allocation, it's about any dynamic behavior that you can think of. Dynamic behavior is not something that can be optimized very easily because there isn't much information about how to optimize it.

The only way to optimize dynamic behavior is that you provide information, as much information as possible. That's why we have static types in languages. However, someone seeing all the dynamic behavior thought what if we could have a language with types at compile time but not at runtime and which completely makes having types useless.

Type annotated languages like Python3 or languages with non-static typed targets like TypeScript compiling to JavaScript are even bigger liars. You are writing types but there's no real point to it. In the compiled output, your types don't exist.

So you added types to make it easier for you to code but it made no change to the performance of the code (unless you make that change) because the machine will still run the code with the same level of optimizations as before as it is still getting the same dynamic code at runtime.

Last point, Fancy APIs. Many modern languages have Fancy APIs that make it easy to do stuff such as creating a web server because it takes care of a lot of things that you had to manually previously.

As good as it may feel. But let's say you made a web server in JS, you don't know anything about an HTTP server even now. You don't know what all it had to do under the hood so that you can write your code. You don't know what the machine actually did because all you see is your Fancy API.

I am not hating on these features. These are good features and their existence matters when you just want to get the work done. My point is that you must understand what your software is doing under the hood for you instead of just thinking in the way your software wants you to. That way you'll be independent of the software.

Note: This is a raw article, I am not going to reread or edit it, so if you find any faults in it, just create a PR.

Why JavaScript? Actually it's ECMAScript

Anshuman Khanna — Mon, 26 May 2025 18:18:30 +0000

It was a sunny day, Phineas and Ferb were in their backyard under the only tree when suddenly Phineas asks Ferb.

"Ferb if JavaScript has weird behaviors, is loosely typed, and has so many glitchy stuff in it, then why did it win? Why do all browsers run JavaScript?"

"Actually, JavaScript doesn't run the world, it's ECMAScript."

"What?"

Yeah so you don't know JavaScript because you never questioned, why did browsers chose this lame excuse of a language with it's weird falsy expressions, random floating point arithmetic and loosely typed behavior as their standard?

Let's understand this, shall we?

In 1995, Netscape was the most popular browser and Brendan Eich had created JavaScript so that the browser had the ability to interactivity easily to HTML.

Microsoft seeing this, wanted to do the same and reverse engineered JavaScript to create JScript (copy my homework but don't make it obvious eh?).

This led to browser wars, which were resolved by European Computers Manufacturers Association, by introducing some standards and JavaScript and JScript became dialects of that.

In some form that was the end of JavaScript because this was ECMAScript, ruled and governed by ECMA.

A popular phrasing you may have heard is "var is an ES5 feature and let and const were introduced in ES6". Yeah so you can probably guess what ES here stands for right?

The name JavaScript still kept going on because of ... Java which was believe me when I say it, the most popular language at that time. Actually Netscape wanted to use Java but weren't able to because of its complexity.

JavaScript won because at that time they would accept anything cross platform and easy and it was both of those. Until one day someone (Ryan Dahl) thought what if we used this not in browsers but in the backend and created Node.js.

Not the worst idea, I mean he clearly supports it till date ... oh wait, he doesn't and created Deno that now encourages TypeScript and also has added support for WASM.

Note: This is a raw article, I am not going to reread or edit it, so if you find any faults in it, just create a PR.

C the right way to program

Anshuman Khanna — Fri, 23 May 2025 14:06:10 +0000

Hey, so I have been going deeper into the rabbit hole of knowing what's underneath my program. I used to main JavaScript and went to TypeScript because I hate programming without types. But I soon got to know TypeScript is just an illusion of types.

This led me to finding the next perfect language that can be used in the backend and I started digging...

My first thought was going to Rust. It was famous, it was fast and best of all it was the first language that I was using that was truly type-safe. I had worked in C++ but after getting some thrashing in the reddit server of Rust I got to know that C/C++ aren't type-safe.

And I did go to Rust. I also went to Golang. I tried both languages just for the heck of it. Trying them both made me realize they are useless for me because these languages are birthed by professionals who transcended from C/C++. I would be repeating my mistake of instantly switching to TypeScript without completing JavaScript and later realizing my faults if I switched to Rust/Golang without knowing C/C++.

Now it's not like I didn't know C/C++. I had done both languages fairly...lazily...

I used C++ for DSA which is what most people use it for anyways because I guess that's what Bjarne Stroustrup imagined his hardwork would be boiled down to. But I had never used C seriously for anything.

Now I wanted to.

So I did that.

I started learning how to create a HTTP server in C. This has changed my perspective on how coding should be.

C is a procedural programming language. I tried to make it OOP, but soon realized that it didn't made sense. C is often criticized for it's lack of generics, memory safety issues and as I said, problems with type-safety. But actually, none of those issues are really issues. Those are as is commonly known skill issues.

C has simple syntax. Almost everything is explicit. You allocate memory, you have to check if there are any errors, you have to type cast things to make them understandable for compiler.

Yes it is a lot of stuff to do when you just want to write code but that's not my point. The point is you must know what is happening when you do something. In C almost nothing happens automatically and you are doing it. The same way in your language full of syntactic sugar, are you sure you know what all is happening?

For example, creating an enumerate function in C.

typedef struct {
    size_t index;
    void* val;
} EnumeratedArray;

EnumeratedArray* enumerate(void* arr, const size_t size) {
    if (size == 0) {
        return NULL;
    }

    const size_t elem_size = sizeof(arr[0]);
    EnumeratedArray* result = malloc(size * sizeof(EnumeratedArray));

    for (size_t index = 0; index < size; ++index) {
        result[index] = (EnumeratedArray) { index, (char *) arr + index * elem_size };
    }

    return result;
}

I know exactly what's happening in this function, I know how everything works on the machine.

Do you need to know all this? No. Does it help to know this when you have to improve the performance of the application? Yes.

Summary: Don't code blindly, know your code, know your machine because that's where the code runs.

Note: This is a raw article, I am not going to reread or edit it, so if you find any faults in it, just create a PR.

The problem with Open Source, in 2025

Anshuman Khanna — Wed, 14 May 2025 17:56:57 +0000

Name 5 Open Source tools that you use, you can't say Git or VS code. Most people can't name anything now. They forget their browser (if chromium) and their mobile software (if android). But let's remove that as well. Name 5 Open Source tools that you actually use daily that aren't the standard.

GSOC is not a good thing, it used to be, but now it's the worst thing for open source in my belief.

Now that I have made 2 very hot takes. I'd like to share my story to explain them.

I started development approximately 1 year back in March 2024. I was a 3rd year BTech student, who only knew C++ and somewhat DSA. I couldn't develop anything. Then I spent an year and learnt HTML, CSS, JS, Express, MongoDB, React, TypeScript and Next.js. Also learnt tools like Git and Postman. Did I become a good developer? Depends on who you ask.

I made a project for a college completely solo. It was their grievance portal. Made it in Next.js, made it as securely as possible. I made a CLI in TS. I also made an AI project in Next.js in just 6 hours which was my college minor project.

I am not a good developer. I am not even decent developer according to me.

This is pointless. Because I wanted to do open source and I couldn't...

I tried to take part in some open source project for GSOC but I just couldn't do it.

I joined two projects. I connected with people. I picked up issues. I understood the issues. But I never felt like I wanted to fix them. Every time I used to sit to fix them, I started making something of my own with the knowledge I got from that repository.

This was strange. I was coding, but I just didn't feel like coding for those other people. A tool I have no information about and the entire task is to fix the given issue. How do you make something better when you don't use it?

Now the tools I took part in were: A JS framework and a chat application. Both were pretty awesome projects. But I used React and I hadn't learnt everything in it, I had barely learnt it before switching to Next.js, which again I had not learnt a lot. And why would I need a chat application? My friends weren't gonna use this slack like app.

So I was supposed to fix something, I had never used. I wasn't motivated to do it. And this is where most software engineers make a grave mistake. They don't use the tool themselves, they just fix it. They'll always submit PRs but never create issues.

You guys have killed Open Source and made it a job.

It is my belief that open source is not about the product but more about the community, more about the power. You think Linus Torvalds created Git so that he could get a job? He created it because he needed it. Later when people realized it has scalability issues, they came and fixed it because they needed that tool.

But this didn't mean I quit being near Open Source, I instead fixed the problem. The problem was that I wasn't motivated to work on something I would never use (and also not get any incentive for it, like you know a salary).

I started using Open Source more and more. My IDE is Neovim, which is completely community dominated and involves no corporation with the ability to make it's extension market place inaccessible if my agentic AI version of their IDE has huge valuation.

I am shifting to Linux (I use Arch btw) but that's mostly because Windows is so bad and slow.

I keep forking OS tools and reading about them. I don't have the need to use all those tools but I stay aware about them more than I was before. If one day, I do need to use them, I'll always have the sense of security that if I want to I could change this software.

If you are doing open source because you want to be in GSOC or LFX and you never think about making your own tools better, I would say, don't do it. Just do a job instead.

My 5 Open Source Tools (that I know about or use):

Gh Github Official CLI
TT Terminal Typing Test
OBS Studio Screen Recording tool for streaming and more
Link Cleaner The name describes itself
UIX A JS Framework like React with pure reactivity unlike React

Yeah, I know you guys just realized that you could be contributing to Node.js and that Github has a CLI tool.

Hopefully now you'll do Open Source and not a job.

Note: This is a raw article, I am not going to reread or edit it, so if you find any faults in it, just create a PR.