1. 1

  2. 1

    Argh. Let me just point out the thing I dislike about design-by-committee languages. This is what happens. You see a library that everybody uses, and you think “I guess that library is REALLY what our language is about.” What do you do? You make that library standard. Seems simple. We had pthread, openmp, etc… and now those are going to be simply C. (As an aside the name C11 is really funny.)

    In one way, this is good… more people will do the right thing maybe? (if it wasn’t so difficult in the first place.) In another, it makes adopting C on a new platform really hard and thus building new platforms really hard.

    Basically… we are getting away from C’s simple values. These things should be done in a library. That library may be a C-environment language (python, ruby, perl… all C-environment derived languages.) It’s just too hard to use this stuff as it is without new forms of expression. Nobody is going to get this right, and we have no good means of debugging them. In the end it comes down to this: why would you add concurrency and thread-safety foo in a language that isn’t even type-safe?! :)

    What we deserve is a replacement for C altogether. Something with veeeery small syntax, static analysis, and proper type-checking. After thinking about it for months, I’d say rust without any of its libraries or assumed memory models (and thus without managed boxes,) where data is assumed immutable and side-effects discouraged.

    Oh, and your kernel should not have any locks. It’s 2013, c'mon.