If you follow semantic versioning rules (https://semver.org/) there is actual semantic difference between major version 0 and major version 1 and above.
A bit ballsy to release the 1.0.0 version immediately, isn’t it? :)
Other than that, kudos for sharing with the world, surely it will come useful for someone. Hell, I might even use it for things like host maintenance cronjobs instead of lock files.
Rust Error Handling and Rust in General is still a big black box for me yet to be unveiled :D
Conceptually, error handling in Rust is incredibly simple: if a function can fail, its return type is an enum of either the result of the function (in case of success) or a description of the error that happened. This enum is called Result. See:
You don't. You can 100% handle errors without any additional dependencies, and probably you should be doing that in the beginning. The crates simply add a little bit of syntactic sugar to simplify some boilerplate that you'll have to start writing as soon as your error handling gets sufficiently complex.
Not saying that your return type is bad, but in general you might be interested in crates thiserror and anyhow that simplify error handling.
51 .timeout(Duration::new(60, 0))
Duration::from_mins(1) would be much more readable.
66 panic!("{}", err);
You should almost never panic. Your function already returns a Result<>, so you should be using that for error handling.
70 } else {
71 // HTTP Status is not 200
Not Rust specific, but usually I recommend to handle errors first, and return from the function early. This way you reduce cognitive load on the reader, and reduce nesting of if-blocks.
150 let mut parts = line.splitn(2, '\t');
There's a convenient method to split in two substrings that you could have used:
let (mac_address, vendor_organization) = line.split_once('\t').unwrap_or(("", ""));
That’s a very interesting thought! I was thinking of writing my own Rust data type that would automatically upgrade to big integer, similarly to the int type in Python.
I can probably improve this a lot, but I was afraid I'll be too lazy after getting this far, so posting as is. Still, lmk if you have any suggestions :)
I’ll cover item 1: start by writing a document, describing what you want to achieve: what do you mean by package, what do you mean by package manager, what features you want to have, what features you do not want to have, how you’re going to build and distribute the packages.
The reason why this is important is that a) this will be a useful reference for the implementation, b) you will learn a lot about the subject matter by trying to answer these questions, and c) you’ll learn to write such documents which is a very useful skill.
Computer science is just mathematics, you can do it with pen and paper. The actual IT jobs where you don't have to touch windows are plentiful, although it might be a bit of a red flag if you're vehemently refusing to touch some specific software (be it windows, or any other program, or programming language).
ah that’s just because i needed rounding towards infinity and not towards zero. In other words i wanted -10/100 to be -1 and not zero. But i couldn’t figure it out on the spot, so i just made it never negative :)
If you follow semantic versioning rules (https://semver.org/) there is actual semantic difference between major version 0 and major version 1 and above.
A bit ballsy to release the 1.0.0 version immediately, isn’t it? :)
Other than that, kudos for sharing with the world, surely it will come useful for someone. Hell, I might even use it for things like host maintenance cronjobs instead of lock files.
Yep, exactly. You can actually look at their source code, it should be very good for learning.
Conceptually, error handling in Rust is incredibly simple: if a function can fail, its return type is an enum of either the result of the function (in case of success) or a description of the error that happened. This enum is called Result. See:
You don't. You can 100% handle errors without any additional dependencies, and probably you should be doing that in the beginning. The crates simply add a little bit of syntactic sugar to simplify some boilerplate that you'll have to start writing as soon as your error handling gets sufficiently complex.
Welcome to Rust, I hope you enjoyed learning and using it :)
One major advice would be to run
cargo clippy, which gives a lot of helpful hints. Apart from that I also have some feedback.These comments should be doc-comments (
///) so thatcargo docpicks them up.Not saying that your return type is bad, but in general you might be interested in crates
thiserrorandanyhowthat simplify error handling.Duration::from_mins(1)would be much more readable.You should almost never panic. Your function already returns a Result<>, so you should be using that for error handling.
Not Rust specific, but usually I recommend to handle errors first, and return from the function early. This way you reduce cognitive load on the reader, and reduce nesting of if-blocks.
There's a convenient method to split in two substrings that you could have used:
I would probably write a regular expression that replaces all contiguous whitespace with a single space instead.
Aren't you trimming this new line off in line 181?
This is somewhat inefficient, since you'll be allocating and copying your string here.
That’s a very interesting thought! I was thinking of writing my own Rust data type that would automatically upgrade to big integer, similarly to the int type in Python.
Just needs a bit of formal languages theory, but otherwise the algorithm is fairly simple. Here’s my code if you decide to look at it at some point: https://github.com/hades/aoc2015/blob/master/dec19.cc
https://en.wikipedia.org/wiki/Earley_parser
Christmas, I guess :) (I just pick a random colour each time a roll is removed)
Day 4: https://lgbt.earth/i/web/post/903630253957573252
Day 7 (zoom to full screen): https://lgbt.earth/i/web/post/903381501524320591
I can probably improve this a lot, but I was afraid I'll be too lazy after getting this far, so posting as is. Still, lmk if you have any suggestions :)
That's day 7, right?
Apart from day 4 not much to visualise so far this year :/
I’ll cover item 1: start by writing a document, describing what you want to achieve: what do you mean by package, what do you mean by package manager, what features you want to have, what features you do not want to have, how you’re going to build and distribute the packages.
The reason why this is important is that a) this will be a useful reference for the implementation, b) you will learn a lot about the subject matter by trying to answer these questions, and c) you’ll learn to write such documents which is a very useful skill.
it all fit in int64 tho, so could be worse
I love the easter egg jokes you add to your code :)
Computer science is just mathematics, you can do it with pen and paper. The actual IT jobs where you don't have to touch windows are plentiful, although it might be a bit of a red flag if you're vehemently refusing to touch some specific software (be it windows, or any other program, or programming language).
so many years have passed since i last wrote a line of masm...
ah that’s just because i needed rounding towards infinity and not towards zero. In other words i wanted -10/100 to be -1 and not zero. But i couldn’t figure it out on the spot, so i just made it never negative :)
Thanks! I don’t mind tips at all.