> why would you be better equipped to write a library for some domain-specific purpose than the original author?
This is how you avoid growing as a programmer.
How to not rewrite it in Rust
51–60 of 231 posts
Re: How to not rewrite it in Rust
#52Earlier quoted context omitted.
All of Rust's complexity for strings comes out of complexity due to UTF-8. Well, a tiny bit comes from the fact that Rust has pointers too, but most of it is UTF-8. Did you happen to read the book? We cover strings early because this is a common pain point. Also, if you have something more detailed than "get strings out of libraries", I can give better advice. It's tough to tell what the actual issue is.
Like this: use sha2::{Sha256, Digest}; fn main() { let mut hasher = Sha256::new(); hasher.input(b"hello world"); let result = hasher.result(); ?? } How do I get a string with the hash value? Which chapter of which book should I read?
I'm well versed in Rust but I think you might need to use
str::from_utf8(result.as_slice())
https://docs.rs/generic-array/0.8.2/generic_array/struct.Gen...
Re: How to not rewrite it in Rust
#53Earlier quoted context omitted.
> In another language you'd risk having a pointer to invalid memory when the function returns if the pointer escapes the function, and so it is advised to use pointers to objects on the stack sparingly if at all. Just a nitpick, this is only true for non-garbage-collected (or refcounted) languages. :-)
In garbage collected languages, are there any objects on the stack? I’m not familiar with GC implementations, but at least theoretically everything is allocated on the heap. Maybe some implementations keep things on the stack as an optimization?
Escape analysis is a common optimization for GCed languages.
e: Also, many languages allow the user create user-defined value types, which are copied rather than referenced. Variables containing these can be stack-allocated.
Re: How to not rewrite it in Rust
#54This article is wonderful and I hope as a setup for second article, "How to Rewrite it in Rust"! > However at best, the temptation to RiiR is unproductive > A much better alternative is to reuse the original library and just publish a safe interface to it. Just as models are a lower dimensional representation of a more complex problem, [1] I have to re-iterate that there are no truth(ism)s in software and as in all e…
I would like to add my 2 cents, TBH I don't see a future where RIIR every piece of software would make sense, and I think you sort of put it in there somewhere in your comments. But yes I do see that for many it would and for those, RIIR would IMHO be an incremental process of oxidizing your project to the point that there's nothing left but Rust. Writing something from scratch and waiting for it to finish is the big…
> TBH I don't see a future where RIIR every piece of software would make sense
It doesn't necessarily have to be Rust, and it's a process that may take decades. But I really do think that absolutely everything should be rewritten in a memory-safe language (i.e. not C/C++).
The vast majority of security issues are either stupid misconfigurations or memory-safety issues. And currently most security initiatives are undermined by the fact that they're resting on insecure foundations. Imagine if our computing platforms were truly secure. It would be a revolution, and IMO it's a revolution that's coming.
Re: How to not rewrite it in Rust
#55"A much better alternative is to reuse the original library and just publish a safe interface to it." I think I must reject the premise a bit, unless I misunderstand how Rust works. If you write a safe wrapper around unsafe code, is it not still the case, that if the unsafe code bombs out, it will take the safe Rust down with it, engulfed in shared flames? (Unless you spawn unsafe code in its separate process or some…
A lot of the time, the danger with unsafe code is doing a thing like passing a null pointer into a function that can’t handle null pointers, or using something before it is instantiated. So the interface should force those things not to happen (with the type system or a constructor or...). This doesn’t prevent the c code from being buggy, but it makes it much easier to use, since you can ensure that you’re maintaining the invariants.
Re: How to not rewrite it in Rust
#56Earlier quoted context omitted.
As mentioned by others, you need to convert the bytes to a String. `Sha2` provides a helper function for that: `hasher.result_str()`. EDIT: sorry I don't know which docs I was looking at, I can't find it in the current version.
This is helpful but in general what is a problem of having strings and trivial functions to convert something (like bytes) to strings? Maybe I am missing the point.
Because converting a type to a string isn't trivial. It needs to be defined for that type.
Rust does have a pair of traits that can be used, Display [1] and Debug [2]. Display must be implemented manually by the author of a type, while Debug can be automatically derived if all the members of a type implement Debug. Like this:
#[derive(Debug)]
struct Foo {
}
Re: How to not rewrite it in Rust
#57Earlier quoted context omitted.
Like this: use sha2::{Sha256, Digest}; fn main() { let mut hasher = Sha256::new(); hasher.input(b"hello world"); let result = hasher.result(); ?? } How do I get a string with the hash value? Which chapter of which book should I read?
I'm well versed in Rust but I think you might need to use str::from_utf8(result.as_slice()) https://docs.rs/generic-array/0.8.2/generic_array/struct.Gen... https://doc.rust-lang.org/std/str/fn.from_utf8.html
That would be correct if the bytes were a string encoded in utf-8, but that's probably not the case for the output of a hash function.
Re: How to not rewrite it in Rust
#58Earlier quoted context omitted.
That's not true. If you build from a dist tarball, you do not need auto tools installed. You usually do if you build from a git repo, however.
How/why is a dist tarball not exactly the same as a zipped up git tree?
Same as a npm package is usually js code and doesn't require you to run the typescript compiler, a dist tarball shouldn't require you to run autotools but just contain their output.
Re: How to not rewrite it in Rust
#59This article is wonderful and I hope as a setup for second article, "How to Rewrite it in Rust"! > However at best, the temptation to RiiR is unproductive > A much better alternative is to reuse the original library and just publish a safe interface to it. Just as models are a lower dimensional representation of a more complex problem, [1] I have to re-iterate that there are no truth(ism)s in software and as in all e…
At least in what concerns C++ there are several ways to try its safety instead of bearing the cost of a full rewrite.
Using standard library types, actually integrating sanitizers into CI, enable bounds checking (even on release builds) and above all avoid C style coding.
Naturally this doesn't work out for third party libraries that one doesn't have control over.
So from a business point of view it boils down how much one is willing to spend re-writing the world vs improving parts of it.
Re: How to not rewrite it in Rust
#60Earlier quoted context omitted.
I would like to add my 2 cents, TBH I don't see a future where RIIR every piece of software would make sense, and I think you sort of put it in there somewhere in your comments. But yes I do see that for many it would and for those, RIIR would IMHO be an incremental process of oxidizing your project to the point that there's nothing left but Rust. Writing something from scratch and waiting for it to finish is the big…
> TBH I don't see a future where RIIR every piece of software would make sense It doesn't necessarily have to be Rust, and it's a process that may take decades. But I really do think that absolutely everything should be rewritten in a memory-safe language (i.e. not C/C++). The vast majority of security issues are either stupid misconfigurations or memory-safety issues. And currently most security initiatives are unde…
Yep, on my domain it has been Java and .NET.