For my own projects I use C because I know it, but also because I know and trust the ecosystem. I seem to have developed something of a software-survivalist mentality, so I like to know that I can build my project five years from now without worrying about whether some remotely-hosted dependency isn't there any more. (I'm not claiming that newer, more trendy languages necessarily fail this test - just that I don't know and trust their ecosystems well enough to be sure.)
C also has the advantage that there are many, many different compilers targeting many, many, /many/ different architectures. My own favourite is VBCC, which is lightweight enough that I was able to write my own backend for my own toy CPU project, and even build the entire toolchain - assembler, linker and compiler - under AmigaOS.
I think the remotely hosted dependency problem and ecosystem thing is not that big of a deal all the time, but if the project involves atypical OS and architectures, then C makes sense. I think it’s still possible to do these in other languages, but that’s just another familiarity gap to add to the existing set.
For the remotely hosted dependency thing, I think it’s pretty easy to vendor dependencies in most realistic C contenders, and a really simple litmus test is just yanking your network cable and doing a fresh build.
The ecosystem thing can be a bigger deal, but again it really depends on the problem domain. There are lots of high quality, non-C libraries for C to always be a clear winner. I think it’s more important to take a step back and make sure whatever language you pick is well suited to the task, rather than assuming any individual one will always be. Knowing multiple languages is handy for this, since that’s more ecosystems that you can pick from, rather than just tying yourself to a single one.
> The ecosystem thing can be a bigger deal, but again it really depends on the problem domain.
Yes, absolutely - and of course C isn't immune to ecosystem problems, either. I remember the pain of working with GNU autotools back in the mid 2000s - in fact it's probably that experience (plus trying to use bleeding-edge tools written in Python!) that left me so cautious about external dependencies today.
Out of curiosity, when you considered the compilers to use for your CPU project, did you look at pcc? And if so, how would you say vbcc compares, in terms of ease of porting to a new arch?
I looked at a number of different options (http://retroramblings.net/?p=1277) but didn't spend a great deal of time looking at pcc. I was amazed to discover how many different options there were, actually!
VBCC's backend interface is well documented, which helps a lot - and there's a skeleton "generic RISC" backend which is trivial to copy and use as a starting point - I found it very useful to be able to tweak a working backend and observe how the generated code changes, while I was getting a feel for how it all hangs together.
VBCC does have an unusual license, however - commercial usage requires permission from the author.
C also has the advantage that there are many, many different compilers targeting many, many, /many/ different architectures. My own favourite is VBCC, which is lightweight enough that I was able to write my own backend for my own toy CPU project, and even build the entire toolchain - assembler, linker and compiler - under AmigaOS.