My two cents: If strings are a significant feature of your application, C is not the right implementation language for you.
I say that as someone who likes C and these days writes more of it than anything else. C's niche is systems programming and embedded, areas where strings are secondary at best.
dboon · 1d ago
I actually disagree, against conventional wisdom.
If it’s string manipulation, my formatting library is as ergonomic as, say, Python (plus or minus some sugar). You move format arguments from inside the string to explicitly arguments, but for short strings this isn’t worst and for long strings the builder API is way better
And if it’s performance…of course Python can be performant, but it’s at least one order of magnitude easier to understand and debug the performance characteristics of the C program.
Like I said in the article, having allocators which obviate the need for granular memory management completely changes what C code can be ergonomically
I say that as someone who likes C and these days writes more of it than anything else. C's niche is systems programming and embedded, areas where strings are secondary at best.
If it’s string manipulation, my formatting library is as ergonomic as, say, Python (plus or minus some sugar). You move format arguments from inside the string to explicitly arguments, but for short strings this isn’t worst and for long strings the builder API is way better
And if it’s performance…of course Python can be performant, but it’s at least one order of magnitude easier to understand and debug the performance characteristics of the C program.
Like I said in the article, having allocators which obviate the need for granular memory management completely changes what C code can be ergonomically
Thanks for reading!