What's your C migration plan?

You know what I've learned over the years? While many people are very bad about writing C, I'm pretty good at it. So C is not a bad language; there are just a lot of bad programmers around using it.<p>(And if you're wondering how to write good C? Make object ownership explicit. Never have malloc and free more than a page of code apart. Don't expose data structures as API. Make errors put your routine into a defined state that the caller can understand. Use bstrings instead of cstrings.<p>And although I don't write much C++, the more I learn about it, the more I believe it's possible to write good C++. Most people won't spend the time to write good software, and when you do that in C or C++ it's an absolute disaster. But if you go slowly, plan, think, exercise care, and review your work regularly, you can get good code that runs fast.<p>You can write a safe Haskell application in 10x less time than you can write a safe C++ application, though.)

This is just nonsense. C is perfect for what it is supposed to do: systems programming, the kind of software you write when creating operating systems, debuggers, and device drivers. It will hardly ever stop being useful for these tasks.<p>People that make this kind of complaint were using C for the wrong type of software. If you want to write a web application in C you just need to reevaluate your tool set.

I doubt that the tech industry will ever move completely away from C. (I had a friend who was doing graduate work in physics and he was required to do all his work in Fortran, believe it or not, so old languages do stick around).<p>For "mainstream" (read: enterprise) software, yes, C may fall out of favor, but it's a great language and here to stay.<p>There are just too many cases where C is the right tool for the right job and it would be silly to use a different language.<p>I'm thinking particularly of embedded software. While languages like Lua are great for embedded scripting, they still need something to script against.<p>So, C isn't going anywhere and I expect that 100 years from now it will still be a worthwhile language to program in.<p>(Also, C is very much the Latin of modern programming. Learning it helps your understanding of so many other things. In case you're curious, Lisp is Greek and I mean that affectionately).

C is the best thing we have that's truly cross platform and has consistent performance everywhere without any company to claim ownership of it.<p>Until that changes, C is here to stay.

The nice thing about an article like this is that anyone who is receptive to it truly shouldn't be writing C code, and anyone who should be writing C code is (in almost all likelihood) not receptive to it.

As a game developer this post is rather amusing. I have far more questions about what happens behind the scenes on the python line than the C line.

It really depends on what you are writing. If you're trying to write the next great startup web app then, yeah, use python or ruby or perl--C is probably too finicky for the fast pace of a web startup. But if you're writing systemd (an "init" replacement) you'd be the object of ridicule if you wrote it in any of those languages.

I've been recently using Python more rather than Java, and I find myself writing C more than ever. I always seem to find some speed/memory issue in my programs that when rewritten in C goes away. Maybe I'm just not proficient enough in Python to avoid them yet. I would say its still a net gain over raw C.

What this can possibly mean? Because C is everywhere. It is in the code that runs the VM of your favorite language. It is in most compilers. It provides basic system services. Why should we have a plan to migrate from something that is everywhere?

But I don't want to use his language, I want to hack on it with him. To see how he solves problems. So, C.<p>Unless its something like Factor, where most of the implementation is written in Factor.

Changing languages will not save you from security holes, only change the kind of mistakes you have to worry about. Only knowing how to write secure code can save you from security holes. You cannot ignore how computers work, no matter how many layers of abstraction and libraries you pile on in an effort to shield yourself from reality.

It's fitting that his site is timing out.

I am unable to load the article. Is there a mirror?

My suspicion is that this is not a C programmer at all. Claiming that you've "written loads of it" certainly lends the author a cloak of credibility, but I don't buy it.<p>"This one, you really can't tell."<p>A competent C programmer can absolutely discern what is happening... more importantly, though, is that the two examples don't do the same thing.<p>I stopped reading at that point.

The author of that (badly timed, btw) post probably does not know that Python is implemented in C.