Rust: Not So Great For Codec Implementing
Some of the complaints are perfectly fair (compile time, powerful but unwieldy macros). Other complaints seem a bit odder to me:<p>&gt;<i>While overall built-in testing capabilities in Rust are good (file it under good things too), the fact that benchmarking is available only for limbo nightly Rust is annoying;</i><p>Okay, but what are you comparing it against? Neither C or C++ have builtin benchmarking or even tests.<p>&gt;<i>If you care about systems programming and safety you’d have at least one or two functions to convert type into a smaller one (e.g. i16&#x2F;u16 -&gt; u8) and&#x2F;or check whether the result fits.</i><p>I don&#x27;t understand this one at all. What&#x27;s wrong with &quot;as&quot;? And if you need a checked conversion just write a small wrapper function? Again, if you&#x27;re comparing to C or C++ I&#x27;d argue that Rust&#x27;s semantic are friendlier and a lot less error prone at the cost of increased verbosity. C will implicitly cast and promote integer types without asking any questions, Rust makes it explicit.<p>I understand C promotion rules and I&#x27;ve still managed to get it wrong on occasions, to the point where I now force myself to make all casts explicit in C like I would in Rust. At least this way the intent is obvious, as I think it should be.<p>&gt;<i>Also the tuple assignments. I’d like to be able to assign multiple variables from a tuple but it’s not possible now. And maybe it would be nice to be able to declare several variables with one let;</i><p>So unless I&#x27;m missing something something like:<p><pre><code>    let (a, _, b) = (1, 2, 3)
</code></pre>
&gt;<i>Same for function calling—why does bitread.seek(bitread.tell() - 42); fail borrow check while let pos = bitread.tell() - 42; bitread.seek(pos);</i><p>Yeah, that&#x27;s always been a minor annoyance of mine too. I intuitively think that<p><pre><code>    a(b());
</code></pre>
should be treated like<p><pre><code>    let tmp = b();
    a(tmp);
</code></pre>
That is b() would terminate and release its borrows before a is even considered and &quot;tmp&quot; would live until the end of the block.<p>I&#x27;m guessing that there must be a good reason why it isn&#x27;t so however.<p>Note that in C and C++ parameter evaluation order is unspecified so calling functions with potential side effects in parameter lists should be done very carefully. The compiler won&#x27;t ever stop you though, don&#x27;t worry. I&#x27;m sure the foot will grow back eventually.<p>&gt;<i>Borrow checker and arrays.</i> [...]<p>Now this whole section feels a lot like &quot;I&#x27;m trying to code in Rust like in C and it doesn&#x27;t work and it frustrates me&quot;. Which is fair, messing around with arrays in C is a lot easier than Rust, there&#x27;s no doubt about that. C also makes it massively easier to spectacularly shoot yourself in the foot if you mess up.<p>Yes, if you need uninitialized arrays and these sorts of things you need to use unsafe. But that&#x27;s mostly optimization and you probably don&#x27;t want to start implementing your codec with that type of code. After all maybe the compiler will be clever enough to see what you&#x27;re doing with the buffer and not actually run the init code. And if it doesn&#x27;t you&#x27;re free to add the unsafe code later, once your codec works, you have good tests and it&#x27;s time to optimize more aggressively.<p>&gt;And that’s why C is still the best language for systems programming—it still lets you to do what you mean (the problem is that most programmers don’t really know what they mean)<p>Ah, so after the Sufficiently Smart Compiler we have the Sufficiently Smart Coder. That seems like quite a definitive claim for somebody who didn&#x27;t know about &quot;split_at_mut&quot; in Rust a few lines earlier. Maybe the author should experiment a bit more with the language before making bold statements like these?<p>It&#x27;s not rare to find security vulnerabilities in codecs and they tend to be extremely exposed. Maybe it&#x27;s worth the hassle of making array manipulation slightly less convenient for the sake of security?<p>&gt;type keyword. Since it’s a keyword it can’t be used as a variable name and many objects have type, you know.<p>All languages have reserved keywords, that&#x27;s strictly in bikeshed territory. Of course when you get to a new language with a new set of reserved keyword you have to learn new habits. You never name anything &quot;struct&quot;, &quot;class&quot;, &quot;switch&quot; or &quot;break&quot; in C or C++ because you&#x27;re used to have these keywords removed. Rust lets me name variables &quot;class&quot; but not &quot;type&quot;. Oh well.<p>&gt;Not being able to combine if let with some other condition (those nested conditions tend to accumulate rather fast)<p>I tend to agree with this one, although I guess it could become messy quickly if you mix refutable lets with regular boolean conditions.