Hello everyone.
I'd like to discuss a topic that has sparked endless debates among developers for years:
What programming language should you choose for a serious project?
Throughout my career, I've worked with C, Assembly, Go, and spent a considerable amount of time exploring modern languages such as Rust and C++. The more experience I gain, the more convinced I become that there is no perfect programming language. Every language has its own strengths and weaknesses.
Despite that, I deliberately chose Go as the foundation of my primary project: ForgeZero.
ForgeZero is a cross-platform build orchestration tool written in Go, with carefully optimized performance-critical components implemented in Plan 9 Assembly to minimize runtime overhead and eliminate unnecessary allocations.
At first glance, it might seem logical that after working with C and Assembly, the next step should be Rust or modern C++, since they are widely considered the future of systems programming.
Rust
Rust solves an impressive number of memory safety problems.
Its ownership model and borrow checker force developers to think about lifetimes and resource management before the code even compiles.
However, safety comes at a cost.
There are moments when it feels like the language dictates your architecture rather than the other way around. In large projects, satisfying the borrow checker can sometimes consume more time than solving the original problem itself.
Even with Rust's strict guarantees, bugs still exist. No language can eliminate every possible programming mistake.
Personally, I also find large Rust codebases relatively difficult to read. The amount of syntax and abstractions often makes understanding unfamiliar code slower than it should be.
C++
C++ is an incredibly powerful language.
Unfortunately, that power comes with enormous complexity.
Templates, metaprogramming, concepts, multiple paradigms, countless coding styles, and dozens of ways to solve the same problem can make maintaining large codebases challenging.
Sometimes reading someone else's C++ project feels less like software engineering and more like an archaeological expedition.
C
C remains one of the greatest programming languages ever created.
It provides maximum control over the system, minimal abstractions, and extremely predictable performance, making it an outstanding choice for low-level development.
The downside, however, is responsibility.
Every pointer, every allocation, and every memory access becomes your responsibility. Bugs such as use-after-free, buffer overflows, or segmentation faults can be devastating.
And perhaps even more importantly, building large software systems in C requires an enormous investment of engineering time.
Had ForgeZero been written entirely in C, both development and long-term maintenance would have been significantly more expensive.
Why Go?
Go occupies a very unique position.
It is simple enough that new contributors can understand a codebase within days, while still being powerful enough to build serious production-grade software.
Goroutines, channels, built-in concurrency, and a minimalistic syntax allow developers to focus on solving problems instead of fighting the language.
Of course, Go has its own limitations.
The runtime, garbage collector, and automatic memory management make it a poor choice for operating system kernels, drivers, or extremely low-level software.
Yet the common belief that Go cannot deliver high performance is simply incorrect.
With careful architecture, proper escape analysis, object pooling, and manual optimization of performance-critical paths, it is entirely possible to achieve nearly zero allocations where they actually matter.
That is exactly the direction ForgeZero takes.
For me, Go represents an excellent balance between development speed, maintainability, readability, and performance.
It is not perfect.
But it allows me to build complex tooling faster than most alternatives without sacrificing quality.
That is why, after all these years, I still choose Go.
Am I Betraying C?
Absolutely not.
C shaped me as a software engineer, and I still consider it one of the greatest programming languages ever designed.
In fact, one of ForgeZero's goals is to make C development easier, improving build workflows and project management for both newcomers and experienced engineers.
Go may be my primary language today, but that does not mean abandoning C.
A huge portion of modern software infrastructure still depends on it.
Operating system kernels, drivers, networking libraries, embedded software, and countless system components have been built and refined in C for decades.
Many developers now discuss Rust's introduction into the Linux kernel and the future of systems programming.
But realistically, no major company or open-source project is going to rewrite millions of lines of stable legacy C code overnight simply because a newer language exists.
Large migrations take years—sometimes decades—and happen gradually.
For that reason alone, C will remain relevant for a very long time.
And personally, I still use it whenever it is the right tool for the job.
Recently, while training a small neural network on my home machine, I encountered an interesting problem.
The hardware is far from modern: an eight-core CPU from 2014 paired with a GTX 1060 6GB (Pascal architecture). Although training was performed on the GPU through PyTorch, the CPU was still under significant thermal stress.
Instead of building a monitoring solution in Python or deploying heavyweight background services, I wrote a small daemon in C that continuously monitored CPU temperature and automatically terminated non-essential processes once critical thresholds were reached.
Could I have written the same utility in Go?
Absolutely.
But for this particular low-level task, C was simply the better tool.
No runtime, minimal dependencies, tiny resource usage, and complete control over the operating system.
That is exactly why I never claim that Go should replace C.
Quite the opposite.
I believe that Go + C + Assembly is an incredibly powerful combination.
Go excels at infrastructure, CLI applications, automation, backend services, and distributed systems.
C remains unmatched for systems programming and direct interaction with operating system internals.
Assembly is invaluable when every CPU cycle matters and maximum optimization is required.
A good engineer should choose the right tool for the problem—not the trendiest language on social media.
My Advice for Beginners
If I had to start my programming journey again, I would begin with C.
Not because it is the "best" language, but because it forces you to understand how computers actually work.
How memory is organized.
How the stack and the heap operate.
How pointers behave.
How a compiler transforms source code into assembly instructions and eventually into machine code executed by the processor.
Once those fundamentals become clear, learning Go, Rust, C++, Java, or almost any other language becomes dramatically easier.
You stop memorizing syntax and start understanding software engineering.
So my advice is simple:
Don't be afraid of low-level programming.
Even if your future career revolves around web services or cloud infrastructure, understanding what happens beneath the abstractions will make you a far stronger engineer.
Programming languages come and go.
Fundamental computer science knowledge stays with you forever.
