SoylentNews is people
SoylentNews
from the C,-C-Rust,-C-Rust-Go,-Go-Rust-Go! dept.
In which ESR pontificates on the future while reflecting on the past.
I was thinking a couple of days ago about the new wave of systems languages now challenging C for its place at the top of the systems-programming heap – Go and Rust, in particular. I reached a startling realization – I have 35 years of experience in C. I write C code pretty much every week, but I can no longer remember when I last started a new project in C!
...
I started to program just a few years before the explosive spread of C swamped assembler and pretty much every other compiled language out of mainstream existence. I'd put that transition between about 1982 and 1985. Before that, there were multiple compiled languages vying for a working programmer's attention, with no clear leader among them; after, most of the minor ones were simply wiped out. The majors (FORTRAN, Pascal, COBOL) were either confined to legacy code, retreated to single-platform fortresses, or simply ran on inertia under increasing pressure from C around the edges of their domains.Then it stayed that way for nearly thirty years. Yes, there was motion in applications programming; Java, Perl, Python, and various less successful contenders. Early on these affected what I did very little, in large part because their runtime overhead was too high for practicality on the hardware of the time. Then, of course, there was the lock-in effect of C's success; to link to any of the vast mass of pre-existing C you had to write new code in C (several scripting languages tried to break that barrier, but only Python would have significant success at it).
One to RTFA rather than summarize. Don't worry, this isn't just ESR writing about how great ESR is.
(Score: 5, Informative) by Thexalon on Friday November 10 2017, @07:51PM
Also, to write those higher-level things properly, sometimes you need to be able to dive into C. A couple of examples:
- I worked on some fairly high-level business code at a Fortune 1000 company for nearly 5 years. Most of it was in Python, which worked just fine. But we had to interface with a 3rd party that didn't have a Python library but did have a C library. So we took advantage of Python's C interface capabilities [python.org], wrote a wrapper around that C library in C, and were in business. And yes, sometimes we had to go mucking around in that C wrapper as the 3rd party's C library evolved.
- I worked on a PHP-based website for a while, and one of the key behind-the-scenes processes had a bug where it was periodically seg-faulting, and eventually the server would be out of actively running interpreter processes. With nothing being reported at the PHP level, I had to go digging through with some stracing and reading interpreter code until we located what the interpreter was doing that caused the problem (specifically, pointers to non-scalar default arguments that were modified over the course of a function were persisting between calls to that function, so all of a sudden we'd get pointers off to nowhere in particular).
- Occasionally when compiling system software from C source, I've come across situations where I needed to create a patch to make the thing work with an unusual distro setup, which I couldn't have done had I not been familiar with C (and yes, I send the patch upstream when it makes sense).
The only thing that stops a bad guy with a compiler is a good guy with a compiler.