[withoutboats]

This is the sort of really impressively shallow and baseless analysis that makes Hacker News so enjoyable to read.

These two blog posts have really nothing to do with one another, are describing unrelated problems with unrelated things, sharing only the fact that they both have to do with the Rust language and both describe something as difficult (but meaning pretty different things by the word) and you draw a conclusion that "Rust is not a language to 'get things done.'"

I don't know how to prove that Rust is "a language to 'get things done'" - this seems like an almost meaningless qualifier - but many people (including me) are getting things done using Rust every day.

[electrograv]

I actually find that Rust is far more productive overall, when accounting for debugging time (or lack thereof) vs other languages!

It is precisely because Rust makes it difficult to implement a lot of bad ideas, that I find myself spending a tiny fraction of my time debugging Rust applications vs C/C++/others (including even high level GC languages).

I love that Rust encourages inherently reliable code, while also not stopping you from writing "unsafe" blocks in the (rare) cases where they're necessary. In fact, in every case so far where I thought 'maybe I should try an unsafe block', I started to realize that implementing this idea or data structure was actually riddled with hard memory management problems, or race conditions, etc. that Rust was preventing from even being possible at all.

P.S. Of course there's a steep learning curve to Rust at first, but it's not fair to count that against Rust -- unless you also weigh against C++ all the years it takes to really master it. IMO, Rust's learning curve is far less steep and painful than C++, it's just that many of us are biased and comfortable having already climbed the C++ learning cliff (so we tend to forget it is there, and how bad it is).

[antaviana]

I did a basic test Rust program: load to strings certain files in a zip file. The first file in the archive happened to be UTF-16 instead of UFT-8 so a vanilla read_to_string for the file in the archive did not do the trick. I googled a bit and it seemed that, in order to be efficient, had to be done with unsafe code. Maybe I was very unlucky, but I was surprised that 5 minutes after trying rust for the very first time I had to use unsafe code.

[steveklabnik]

Why not https://doc.rust-lang.org/std/string/struct.String.html#meth... ?

[antaviana]

I did not find a trivial way to go from the Vec<u8> returned by read_to_end to some kind of u16 container. Everything I found in Google involved unsafe code. Probably a function read_to_end returning a Vec<u16> would have been great.

[steveklabnik]

Ah yeah. It's tricky, but it also doesn't require unsafe: https://play.rust-lang.org/?gist=e261ed324a022ac82bb88adcee1...

I'm sure there's a package that makes this easy, but this took me about ten minutes to toss together from scratch.

[drbawb]

Agh! Chunks is what I was looking for! I was trying to whip up an example[1] and was positive I had used a pair-wise iterator before. The best I came up w/ was zipping two iterators of the hi/lo bytes. -- I feel the parent's pain, because this is coming from someone who has been programming Rust since it had green threads and `~ / @` pointers.

I love Rustdoc, but I really wish it wasn't so obtuse when it came to casually browsing the various iterator traits. Perhaps Steve, for the benefit of myself and thread parent, you could point us to some better-edited literature for the various iterator methods?

P.S: just wanted to add, if I were faced w/ this issue in production code, I likely would've just reached for the excellent byteorder[2] crate. It's so useful for "bit twiddling" like this.

[1]: https://play.rust-lang.org/?gist=4b4ff7263d9744caeb8bacd4c0d...

[2]: https://docs.rs/byteorder/1.2.6/byteorder/trait.ReadBytesExt...

[antaviana]

Ok, thanks I see. I suppose that it was a bit too much for a stackoverflow-prone noob like me, with only 5 minutes of rust flight time.