Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Friday November 10 2017, @06:23PM   Printer-friendly
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.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Insightful) by bob_super on Friday November 10 2017, @07:39PM (6 children)

    by bob_super (1357) on Friday November 10 2017, @07:39PM (#595296)

    More to the point:
    > "relentless cycling of Moore’s Law had driven the cost of compute cycles cheap enough to make the runtime overhead of a language like Perl a non-issue".

    My battery doesn't like the way you think.
    My server's customers, always bitching about more throughput and less latency, do not like the way you think.

    Sure, for an AC-connected personal computing device doing human-scale stuff, go ahead and use the easier language. The rest of us have to deal with Intel/AMD no longer bumping clock speeds up.

    Starting Score:    1  point
    Moderation   +3  
       Insightful=1, Interesting=1, Informative=1, Total=3
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 3, Interesting) by Grishnakh on Friday November 10 2017, @11:07PM (4 children)

    by Grishnakh (2831) on Friday November 10 2017, @11:07PM (#595395)

    Totally wrong.

    Python and Electron are all the rage now, so it is clear that performance is no longer important to either developers or users. If your server's customers cared about throughput and latency, they'd be demanding that everything be written in C++ or similar. Are they? Didn't think so. Tell them to shut up about those things until they're ready to change.

    • (Score: 1, Insightful) by Anonymous Coward on Friday November 10 2017, @11:22PM

      by Anonymous Coward on Friday November 10 2017, @11:22PM (#595402)

      The bean counters see only the need to get to market first.

      They'll gnash their teeth in frustration when it comes time to scale; that's when they'll demand the performance of an industrial language such as C++, which is what everybody will agree should have been the initial implementation.

    • (Score: 2) by bob_super on Friday November 10 2017, @11:28PM (2 children)

      by bob_super (1357) on Friday November 10 2017, @11:28PM (#595407)

      > If your server's customers cared about throughput and latency, they'd be demanding
      > that everything be written in C++ or similar. Are they? Didn't think so.

      It's cute how you're telling yourself a nice story that matches the conclusion you want to reach. Which soundtrack did you put in the background?

      Some of us have to design against specs, because our customers have system requirements to meet in order to make money with our products. The actual language doesn't matter, as long as the specs are met, on time and on budget. Can we meet the spec with the overhead, and can we find all the supporting code in $fashionable_language? Will we be able to provide the ten years of support? How long will it take to figure those questions out?

      • (Score: 1, Informative) by Anonymous Coward on Friday November 10 2017, @11:57PM (1 child)

        by Anonymous Coward on Friday November 10 2017, @11:57PM (#595409)

        To indicate that you are quoting someone, use the "<blockquote>…</blockquote>" construct.

        You know what? Maybe this is why all software sucks ass; you people just don't give a fuck about doing things "correctly".

  • (Score: 2) by forkazoo on Saturday November 11 2017, @12:51AM

    by forkazoo (2561) on Saturday November 11 2017, @12:51AM (#595422)

    90% of the performance problem on that hypothetical laggy server with performance problems comes from something like 1-2 % of the code that it needs to run.

    Sure, some part of it needs to be native code, but the nightly cron job that cleans up /tmp at 3:00 am doesn't need to be hand-tuned assembly. A shell script will work just as well, and doing it in the easiest way possible will free up developer resources to focus on that 1-2% of the code on the box that is actually going to cause you trouble.