Rust’s worst feature

This seems not even close to the worst feature of rust - this seems like it needs some more design work and baking. Like lots of things.<p>The amount of hyperbole in this article makes it a bit hard to take the author all that seriously.<p>Is there evidence more baking won&#x27;t happen? While i have my loves and hates about rust, it definitely always felt like they had a pretty thorough&#x2F;careful process for additions like this. If you go constructively into the threads and offer some concerns, you will usually get some reasonable response.<p>(All processes of course, fail, so this is not always true, but it&#x27;s mostly true)<p>While i think it&#x27;s fine to write rants on blogs, and don&#x27;t feel like everyone has a responsibility to file bugs or whatever before they write a rant about it, if you actually want to see this &quot;worst feature&quot; fixed, this probably won&#x27;t help very much.<p>(IE You don&#x27;t <i>have</i> to be constructive, or even helpful, but if you <i>want</i> to be constructive or helpful, this ain&#x27;t how you do it)

The more pertinent question to me is can we implement some new static analysis that understands buffer re-use and can hoist buffer initialization outside the loop? Rather than make the programmer write obfuscated code for efficiency, it is usually better to have the compiler do the heavy lifting.<p>P.S. Also, folks, don&#x27;t re-use buffers without zeroing unless you absolutely need the performance and know what you&#x27;re doing.

Maybe Rust needs another type of reference that&#x27;s exclusive write only? Right now there&#x27;s RO (&amp;T) and exclusive RW (&amp;mut T) but WO is missing.<p>Having a WO reference would allow these read_buf APIs to express they only write and never read so the uninitialized memory is safe to pass directly.

&gt; Even an obvious optimisation of moving the buffer declaration outside of the loop isn’t available to the compiler.<p>Why? Can&#x27;t the programmer just do this himself?

I think the answer is that in a case when you need that speed, you hoist the stack allocation &amp; zeroing and unsafe that buffer in the loop if need be. Test well. I am a huge Rust fan but also it is actually possible to write correct unsafe code.<p>If I am interacting with from IO space, I would much rather write the interaction code myself for the machine at hand than farm it out to an array of third party crates. ::shrug::<p>getting the machinery to let it properly be hoisted smoothly and safely would be nice, but it isn&#x27;t required.<p>personally I think rust macros are very painful and the &quot;worst feature&quot;, but that&#x27;s speaking as someone who did a fair bit of Common Lisp.

&gt; While replacing the array of zeros by an array of uninitialised values may work in specific circumstances, the code is unsound. Change to the compiler, its options, modification of unrelated parts of the code or using the function for a different Read trait implementation may break the program in unpredictable ways.<p>Why? It seems the only thing on that list that will cause UB is using the function with a different reader (one that inspects the uninitialized bytes). Why would any of the other listed possible changes break it?

This API has basically been adopted from Tokio. Like most of Rust buffer types, it&#x27;s &quot;not bad&quot; to use as a caller and &quot;awkward&quot; to use as a consumer.<p>The pain of paying for buffer init is real, however. The last two projects have both seen perf hits from it.

If this is mainly useful for working with plain&#x2F;uninterpreted byte arrays, then I wonder why we can&#x27;t just do `[u8; N]::with_noinit()` method instead of doing the multi-line plus unsafe things listed in the article.<p>Is the main point that things like `slice_freeze_mut` could also be used for slices of e.g. `struct Coordinate { x: u32, y: u32, z: u32 }`?<p>It would obviously not work for f64 things, since there also not all bit-patterns are valid.

Why is it that the frozen semantics are actually needed? Is there no way to represent what people actually want here - memory that is entirely uninitialised, for which tautology might be false, until written? I.e. something that&#x27;s a bit like MaybeUninit but more so?

Do some Rust types have invalid object representation or trap representation? On SysV x86_64 bool only has two valid representations in memory, the rest are trap representations.<p>So for an array of bools (if Rust matches SysV) freeze wouldn&#x27;t be sound, even without the madvise problem.

I am not yet a Rust programmer but - is it not typical to have a small collection of unsafe functions, carefully reviewed, that in this case seem like they might be easier to maintain than some of these convoluted type-based workarounds?

The selling point of Rust was that it protects programmers from doing dangerous things.

what does the term &quot;nightly&quot; mean in this context?

I&#x27;m not a Rust person (give me Lisp any day), but this stuck out to me:<p>&gt; <i>A motivated programmer can try adding necessary support to actively maintained packages [...] but what if one is stuck at an older version of the crate or deals with apparently abandoned crates</i><p>One could maybe do some programming? I mean, hell, if most of the work has already been done for you, then what&#x27;s holding you back? Besides, why would you want to use outdated, bug-ridden libraries filled with vulnerabilities instead of something well-maintained?