It takes a while to get used to and I was also still learning, but over time it changes how you code into a much safer style. With other non garbage collected languages you were left to find out much later, maybe years later and end up with insecure code that crashes occasionally and very difficult to debug and fix.
If you need to clone an array to copy a variable, that seems like it could be good for code security but takes extra cpu power and important array don’t become too long.
Only thing I found was this but others probably know alot more. I have spent many 50-100 hours with general dynamic arrays, global\local variables and threading in VB and Python, but my knowledge is limited in coding. So what I write may not be of use but I try until some other coding wizard comes along.
Also try youtube\ it was a life saver through college. It becomes so easy to learn when you can watch an expert show and talk about complex things.
Are you referring to structs & struct fields here? eg:
struct Foo {
bar: String,
some_other_data: String,
}
fn main() {
let foo = Foo {
bar: "bar".to_string(),
some_other_data: "1337".to_string(),
};
// we take out `bar`
let _bar = foo.bar;
// this fails, that's because we took out `bar` and ended
// up with an incomplete `Foo`.
consume_foo(foo);
// this works after commenting out the previous line. rust
// knows that `foo.bar` is gone, but `foo.some_other_data`
// is still there
println!("some_other_data: {}", foo.some_other_data);
}
fn consume_foo(_foo: Foo) {}
You can clone the object, but not the variable.
hmm? If a type is not clonable, then you can’t clone a struct that contains that type neither.
Or even GC langs. Rust has some other nice safety features like preventing race-conditions & safe multi-threading. Don’t event need to mention how unsafe javascript & php are…
Yes, I think that would be a great example.
And then _bar needs to be consumed twice as well, which prompts me to take out foo.bar in the first place because I’m used to assigning local variables for struct fields when used more than once.
What’s the general approach to this scenario?
Then you need to borrow the field instead of moving it:
// we borrow `bar`
let _bar = &foo.bar
// and later again
println!("same_data: {}", &foo.bar);
Thank @happybeing for the valuable information.
Announcing Rust 1.56.0 and Rust 2021
https://doc.rust-lang.org/edition-guide/rust-2021/index.html
Certainly.
300k satoshi should be easily attainable if you have the skills.
Looks like Jack is also getting on the train.
I’ve just completed a Redbin format for serde. Now I can transfer values (function arguments and return values) easily in my Red ↔ Safenet ffi bindings project. Learned a lot about Rust. Everyone feel free to review the code and drop me an issue or PR :-), thanks.
I’m thinking of using vdash soon (an terminal GUI app for those running a Safe Network Node) so if anyone fancies working with me to update vdash and learn a bit of Rust with my support let me know. It’s a good way to learn programming or a new language.
I always learned by taking existing code and modifying it to do what I want, so it’s a good opportunity to scratch that itch. And when that code is being used by others there’s a real buzz.
Topic about vdash:
I don’t have time now, but I want to learn Rust properly later. Thx (‘고마워요.’) @happybeing
Any time!
Ten chars
In case anyone is interested in a free online Rust course this, just tweeted by a friend:
…and just got stuck :-/
Now I’m working on implementing deserialization into &str
(needed for deserialization of arguments like Option<&Path>
in Safe::connect
) and ran into a lifetime problem (error E0495). Please, if anybody could help me with this, will have my gratitude to the end of my life! I’ve spent 4 days on it already :-/
it’s in separate branch: GitHub - loziniak/redbin at str_de2
I’m not sure I can exactly explain where the problem is, but I’ve tried to clean everything up, so if you run cargo test
, there is only the mentioned error left (repeated in 3 places).
Damn you @happybeing, I have not slept since yesterday cos this Replit
WTF is wrong here?
cargo run --bin combiner
Compiling fcc-rust-in-replit v0.1.0 (/home/runner/Rust-in-Replit)
warning: unused import: `ImageFormat`
--> combiner/src/main.rs:6:39
|
6 | use image::{io::Reader, DynamicImage, ImageFormat};
| ^^^^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
error[E0308]: mismatched types
--> combiner/src/main.rs:17:10
|
13 | fn find_image_from_path(path: String) -> DynamicImage {
| ------------ expected `DynamicImage` because of return type
...
17 | return (image, image_format);
| ^^^^^^^^^^^^^^^^^^^^^ expected enum `DynamicImage`, found tuple
|
= note: expected enum `DynamicImage`
found tuple `(DynamicImage, ImageFormat)`
error: aborting due to previous error; 1 warning emitted
For more information about this error, try `rustc --explain E0308`.
error: could not compile `fcc-rust-in-replit`
Does this deserve a wee award for Most Unhelpful Error Msg Ever?
13 | fn find_image_from_path(path: String) -> DynamicImage {
| ------------ expected `DynamicImage` because of return type
The error is saying what you are returning is not DynamicImage
but something else. What you are returning is the tuple return (image, image_format);
So you need to change the return type or change what you are returning.
The lesson instructions are
LESSON #32
You have learnt about the empty tuple type (). Now, you will use a tuple to return multiple values. Unlike other types, a tuple can contain more than one type.
// The Vec type can only contain one type.
let my_vec = vec![1u8, 2u16, 3u32];
// Tuples can contain multiple types.
let my_tuple = (1u8, 2u16, 3u32);
Task: From find_image_from_path, return a tuple containing the DynamicImage and ImageFormat of the image, in that order.
Run cargo test --bin combiner to see if you correctly completed the task.
When you are done, type the following for the next lesson:
$ fcc 33
fn find_image_from_path(path: String) -> (DynamicImage, ImageFormat) {
let image_reader = Reader::open(path).unwrap();
let image_format = image_reader.format().unwrap();
let image = image_reader.decode().unwrap();
return (image, image_format);
}
passes the tests but panics later so its progress Thanks David
Once I work my way through this another few dozen times, the syntax will hopefully start to stick with me but its a sair fecht…
It’s just some contextual info about the expected return type. The real error is in line 17.
Unstuck: Trouble with lifetimes in serde format implementation - help - The Rust Programming Language Forum
Turned out it’s not possible to do what I wanted, because Redbin string encoding is not compatible with UTF-8, so I implemented only for ASCII: