5 ms·
> To release compression code in a non-safe language is risky enough At the moment, what's their real alternative? Rust is the only memory-safe language I can
by johncolanduoni 10y ago
> To release compression code in a non-safe language is risky enough
At the moment, what's their real alternative? Rust is the only memory-safe language I can think of that could hope to meet their performance requirements, but even the Rust runtime would be a lot of overhead for this application.
That said, I agree this isn't acceptable C code for something that runs on untrusted data while using tons of pointer arithmetic.
- pilif 10y agoYou're right about C. C in general, I would find acceptable, because, yes, there aren't that many good alternatives around for this kind of code. But there's nothing stopping you from writing readable C code. That's where my concerns come from.
- deleted 10y ago[deleted]
- msvalkon 10y agoI don't really understand where the downvotes come from? I find the readability concerns legitimate, and would like to understand why compression algorithm developers feel like this is OK? Is it just the math heavy background? Can't think of any real benefits to this style.
- throwaway2048 10y agoIf you don't understand the underlying mathematical algorithms its using, no amount of explicit varible names are going to help you. If you do, the concise structure makes things straightforward. The code is not meant to be read alone and understood, the papers published along with it need to be understood first.
- rimantas 10y agoExactly. Not all code can be understandable to layman with zero effort.
- dang 10y agoI suspect the downvotes are because code readability is a complex, subtle topic that often gets reduced to flamewars by people who are sure they know ‘the’ right way to do things. Code readability is relative to the reader, the programming language, and the conventions of a codebase. That's a lot of things to be relative to! Knowing that ought to put speed bumps on the way to dismissing code one isn't familiar with. I remember having a reaction years ago on seeing some of P.J. Plauger's C++ standard library code. I think I burst out laughing and said I'd fire anyone who wrote code like that for me. Years of subsequent experience have brought multiple layers of understanding how wrong I was.
- vertex-four 10y agoWhich bits of the Rust runtime(?) do you think are too high overhead for this?
- chillydawg 10y agoI suspect any runtime, at all, would be too much overhead.
- vertex-four 10y agoThere isn't a Rust runtime, though, in the sense that you seem to be implying. There's a standard library, which is what I assumed they meant.
- johncolanduoni 10y agoYes, I was using it to describe the standard library. C and C++ are both described as having a runtime, and Rust has one in the same sense. In any case I would consider the code needed for handling stack unwinding to be worthy of the name runtime (small though it may be). I understand it doesn't have a runtime in the way a JIT'ed or GC'ed language has a runtime, but it's a runtime nonetheless.
- jdub 10y agoThis C code doesn't use the C library. Code like this in Rust wouldn't engage with any part of the Rust standard library either. There's no runtime work to be done, in either language.
- johncolanduoni 10y agoThere is still an overhead in terms of executable size, unless you use #![no_std]. This environment is not easy to code in; it doesn't even have heap allocation.
- johncolanduoni 10y agoUsing rust 1.9.0, an empty (save for a function that adds two u32s) standalone dynamic library built in release mode on OS X is 1.6 MB. A static library is a whopping 2.4 MB. The comparable number for C are 4K and 800 bytes respectively. Asking every client of the compression library to pull in that much overhead would likely make it rather unpopular. Until Rust gets better at eliminating unnecessary parts of the runtime when a program doesn't use it (something like GCC's gc-sections), it's not going to be feasible for small libraries to be written in it.
- deleted 10y ago[deleted]
- 72deluxe 10y agoMay I ask what is not memory safe about C++ in this situation? I am talking C++11, not the widespread C++98 stuff we find everywhere. Or why not use local variables that are guaranteed to be cleaned up? I suspect Apple would have an alternative to write this in Swift, but that would probably have speed implications (I am guessing).
- PeCaN 10y ago> At the moment, what's their real alternative? Ada? Chapel? ATS? D if you avoid the GC? > That said, I agree this isn't acceptable C code for something that runs on untrusted data while using tons of pointer arithmetic. Why not? It's not the prettiest code ever, but it gets the point across of what's going on.