1. 32

  2. 10

    While Ted may usually write safe C, it’s a serious problem for the world, as we are constantly reminded. The thing I want from Rust is to change the incentive structure for anyone writing memory-safety-sensitive high-performance infrastructure. I hate that C and C++ have been so justifiable for use in drivers, tcp stacks, cryptography libraries and overlay networks, rendering engines, etc… I want the problem space that these tools apply to to shrivel up dramatically. Humans simply can’t be expected to produce safe things using them.

    1. 8

      I think it’s pretty disingenuous to suggest that engineers cannot be expected to write high quality C. Sure, there are a bunch of practices in C that lead to mistakes, like manipulating raw char *-style strings. This can be easy to stuff up, so use a library that handles the memory management and various manipulations. If you’re doing a lot of pointer arithmetic you should probably rethink the data structures (and associated library routines) that you’re using. Don’t be afraid to malloc(3C) the correct amount of memory, rather than play games with static buffers on the stack that will absolutely surely always be big enough. The CERT C Coding Standard has a lot of excellent advice within.

      In the illumos kernel, we have various library routines to manage self-describing, debuggable linked lists and AVL trees. Our debugger, mdb, has excellent support for locating, inspecting and walking every data structure in the kernel or a C-based userland application or library. We have both in-kernel and userland support for debuggable, auditable C memory allocation with detection of heap corruption (double frees, use-after-frees, etc) and leaks.

      I appreciate that C is not for everybody, but there is a fine ecosystem of C tooling out there that has not just stood the test of time, but been improving the whole way. There is a quote attributed to Andrew Koenig: “I once knew someone who could write PDP-8 assembly language in any language.” There will always be code of varying levels of quality, good and bad; though it is often tempting to blame the tooling, it would be nice not to throw out the baby with the bathwater.

      1. 7

        In fact, I suggested that some people can write safe C. There are also ways you can use a jointer without chopping off your fingers, but you still see plenty of professionals who use them every day walking around without one or two of them. What I’m saying is that in the real world of commonly used infrastructure, a lot of unacceptable bugs still happen. I am also not suggesting we declare year zero. I just hope that Rust changes the choice-space for widely deployed infrastructure in a way that makes us meaningfully safer.

      2. 2

        You probably could have had a lot of what you ask for ten years ago with ccured. Negligible overheard, reducible to zero with some programmer assistance, and a much clearer migration path for existing software than rewriting everything.

        1. 8

          ccured did runtime checks. Rust and similar languages (ATS) do compile-time checks. There’s a large performance benefit to compile-time checking, and, because some aspects of C (such as, “Does this string terminate?”) are inherently non-checkable at runtime, there’s also a security benefit over things like ccured.

          1. 2

            According to the paper, ccured could eliminate most of the runtime checks. Basically, safe code would run fast, but unsafe code would run a little slower. That seems a reasonable compromise to me vs refusing to compile unsafe code entirely. Reduces upfront developer effort, but allows iterative improvement where necessary.

      3. 6

        The arguement here is that the success of a language depends on it solving some specific problem and doing it well. Here are the examples:

        • C: “The portable assembler.” Oh yeah.
        • C++: A million things (?) including “better meta programming, mostly templates and to a lesser extent native support for class methods vs structs filled with function pointers.” Not sure this fits the “specific problem” criteria, but okay.
        • Java: “memory management and safety,” and having “a huge standard library.” Cool.
        • Go: “transparent concurrency support with solid runtime support.” Yeah, sounds good.
        • Rust:

          I have a harder time identifying exactly what Rust is for, because it’s been a moving target. Unlike Go, but more like D, the promise of Rust is not a specific solution, but simply betterness. Memory safety could qualify as a targeted problem, though historically that’s been a tough sell on its own.

        Complete zero-cost, compile time memory safety is not good enough on its own? How about for web browsers, where C++ allows for countless security exploits? There is a very specific use case here:

        Mozilla intends to use Rust as a platform for prototyping experimental browser architectures.

        1. 5

          Memory safety is a feature users want, not developers. :)

          Imagine a compiler/language called wurst. It’s just like rust, in fact wurst can compile any valid rust program and will generate the same code. The only difference is that wurst doesn’t do safety checking. It’s like wrapping unsafe around everything. So some invalid rust programs will happen to be compiled by wurst. Otherwise, wurst has whatever language features rust has.

          Let’s consider the transitive migration choices here.

          C vs wurst. I already know C. wurst has some cool features. Maybe it lets me write some applications that would be really difficult in C, maybe not. (That’s the big question.) Generally, though, in order to switch languages I need to have the thought “I can’t imagine doing this in X…”.

          wurst vs rust. It seems like an obvious choice that rust is better, but as stated, rust doesn’t let me create any program I can’t create in wurst. Anything possible in rust is obviously equally possible in wurst.

          To really boil it down, the question is “How much typing will this save me?”

          Please note, I’m not arguing against memory safety. I’m not saying Rust is a bad idea. Just practically speaking, “keystrokes saved” seems like a historically important metric. That’s an observation, not a recommendation (and it’s possible to see things differently, too).

          1. 9

            “keystrokes saved” seems like a historically important metric

            The extreme popularity of Java and C# would seem to suggest otherwise.

            In any case, my view (as a non-contributor) on “what Rust is for” is that it’s building a low-level/high-performance (“systems” to some extent, though I think the term is mostly a misnomer brought about by the C/C++ split) with modern features and advances in PL theory. To that end, it’s got stuff like algebraic types, type inference, type classes, etc.—many of the developments which have heretofore primarily been seen in so-called “academic” languages like Haskell and ML

            Memory safety’s not actually my favorite feature of Rust. (It’s a pain in the ass, to be honest, though being forced to be correct usually is.) It’s everything else that increases the expressiveness and metaprogramming abilities of the language. So in your hypothetical situation, I would still choose wurst over C, because it’s got language features I want and like. And at that point, the only reason not to use Rust is that I want to (or am too lazy not to) have memory errors in my programs.

        2. 3

          FWIW, this wasn’t really intended to convince anyone of anything. I was musing about languages and wrote down some thoughts. You don’t have to agree or disagree; though this being the internet, maybe you do. :)

          1. 0
            1. Concurrent
            2. Stack Based
            3. Fast
            4. Macros
            5. Small memory consumption
            6. FFI to C and C++
            7. Indirect Dispatch
            8. Industrial strength Profiler / Debugger
            9. Open Source
            10. Guaranteed Backwards compatibility
            11. Unsafe
            12. Energy friendly
            13. Faster compiler than go

            Meet x86 :)