251–260 of 313 posts
I just don't feel like rust can replace C/C++, because the syntax is not simple enough. Rust has a lot of cool things, but to me syntax simplicity is more important. Maybe I have a hard time adapting myself to rust? Maybe my brain is too much "wired" to a C style syntax. It still seems that to me, C-style syntax is just better. I would rather prefer a C++-like language that breaks down from backward compatibility wit…
I just don't feel like rust can replace C/C++, because the syntax is not simple enough. Rust has a lot of cool things, but to me syntax simplicity is more important. Maybe I have a hard time adapting myself to rust? Maybe my brain is too much "wired" to a C style syntax. It still seems that to me, C-style syntax is just better. I would rather prefer a C++-like language that breaks down from backward compatibility wit…
Anyway, what is "not simple" about Rust's syntax?
Serialization will always be slow for obvious reasons, that's why binary protocols and messages started to emerge (HTTP/2, gRPC) instead of serializing/deserializing everything to JSON and back.
Earlier quoted context omitted.
I agree that in many cases a much simpler API would suffice, but it strikes me as odd to suggest adding a convenient but insufficient-for-security API to the same standard library that protects HashMap against DoS.
(past edit window) This was written with hostility I don’t feel. Sorry Raph!
Earlier quoted context omitted.
There are libraries that are maintained by the project itself, but are not part of the standard library, yes.
Is there a list of these somewhere? Crates.io doesn’t appear to let me sort by author.
Earlier quoted context omitted.
Not really. Rust supports 8 bit microcontrollers. Lot's of libraries, including parts of the standard library make no sense on these kind of platforms. The standard library and 3rd party crates generally have excellent compatibility across mainstream platforms.
So do Basic, Ada, Pascal, C and C++ as well, and yet they have richer standard libraries, with deployment profiles.
In other words, not all functions in the stdlib of Ada, Pascal, C and C++ can be used in all possible target environments? Sounds like a failure to quality gate those standard libraries.
Earlier quoted context omitted.
The API you describe, IIUC, can’t be serviced faithfully on the OSes targeted by std while being backed by real entropy.
But the std hashmap implementation[0] already depends on a PRNG via the rand crate[1], and thus OS random (for the initial seed). So it's in the standard library even if you can't use it directly. Which is what makes me think this is an API issue, not an implementation one. [0]: https://doc.rust-lang.org/std/collections/hash_map/struct.Ra... [1]: https://docs.rs/rand/0.7.0/rand/rngs/struct.ThreadRng.html
Earlier quoted context omitted.
SHA2 is not designed to be used as a RNG. SHA3 might be a little bit better with its "streaming" modes, but there are many far better and faster ways to get random bits.
It doesn't have to be the absolute fastest, it just has to work. What is far better and faster than SHA3? And while SHA2 wasn't designed for that use, it's easy to make simple and provably correct constructs that turn a secure hash into a secure RNG.
Earlier quoted context omitted.
The request here is for a simpler API. I and many others would be more than happy to get a function that returns a random u64. No traits, no crippling commitments to a specific API design.
The API you describe, IIUC, can’t be serviced faithfully on the OSes targeted by std while being backed by real entropy.
How many people would use a Rust cloud compiler? Suppose it cuts build time from 5 minutes to 30 seconds.... Technically, a transparently mirrored file system, a strong compiler cluster (memory, cores, etc). And some predictive ML. But you end up with a binary-equivalent (verifiable) output. Any thoughts ?
Not sure how the buisness model for a cloud compiler would work, but I would be interested.