One year of C
It’s now nearly a year that I started writing non-trivial amounts of C code again (the first sokol_gfx.h commit was on the 14-Jul-2017), so I guess it’s time for a little retrospective.
In the beginning it was more of an experiment: I wanted to see how much I would miss some of the more useful C++ features (for instance namespaces, functi0n overloading, ‘simple’ template code for containers, …), and whether it is possible to write non-trivial codebases in C without going mad.
Here are all the github projects I wrote in C:
sokol: a slowly growing set of platform-abstraction headers
sokol-samples - examples for Sokol
chips - 8-bit chip emulators
chips-test - tests and examples for the chip- emulators, including some complete home computer emulators (minus sound)
All in all these are around 32k lines of code (not including 3rd party code like flextGL and HandmadeMath). I think I wrote more C code in the recent 10 months than any other language.
So one thing seems to be clear: yes, it’s possible to write a non-trivial amount of C code that does something useful without going mad (and it’s even quite enjoyable I might add).
Here’s a few things I learned:
Pick the right language for a problem
This is part of a decade-long personal transformation: instead of trying to solve every problem with a single language (in my case: C++), and become an entrenched ‘C++ expert’, it is much more enjoyable and productive to learn a few different languages and pick a language that naturally fits a problem. Putting C back into my language toolbox was a good decision for problems where C++ was overkill (although I didn’t realize that C++ is overkill for many problems before I started writing C again). C fits into a multilanguage toolbox better than C++ because integrating C with other languages is usually much simpler than trying the same with C++.
Here’s what my current language toolbox looks like:
python: for cross-platform shell-scr1pting stuff, command-line tools where performance doesn’t matter, or generally glueing together several tools and applications (e.g. tools like Maya or Blender are python-scr1ptable, I wish more UI application were)
Typescr1pt: for anything web-front-end related and where more than a few lines of Javascr1pt is needed
C: my first choice now for writing libraries and any sort of ‘building blocks’ code
C++: simple ‘Orthodox C++’ is still useful for bigger code bases, and of course when depending on other code that’s written in C++ (like Dear ImGui or SoLoud). I have no intention to go ‘all Modern C++’ though. Picking the right language subset is even more important than in the past.
These are my bread-and-butter languages where I have written the most code in, unfortunately I didn’t have much need for Go yet, I would use this for anything running on a server backend. I’m also keeping an eye on a number of small ‘better C’ languages that are starting to appear, like Nim, Zig or Ion. Personally I think these small language are much more exciting than big oil tankers like Rust or Swift.
I guess the paradox here is that it’s better to have a shallow knowledge of multiple simple languages than a deep knowledge of a single complex language
C is a perfect match for WebAssembly
What caught me a bit by surprise is how much smaller WebAssembly demos written in C are when compared to similar demos written in C++.
For instance the sokol-gfx triangle sample is a 22 KByte download (9 KB WASM, and 12.9 KB JS, all compressed). Before that I was quite convinced that an emscr1pten WebAssembly demo using WebGL can’t go below around 90 KByte (compressed) (also see this blog post).
https://floooh.github.io/2018/06/02/one-year-of-c.html 
რა განსხვავებაა, C# და C++ შორის?
