I'm currently at the point in the stream where you get asked, if your time isn't too valuable for streaming. And I just want to tell you, how much I appreciate your streams. This one has a huge impact on my work on Github and how to setup a CI/CD. It's different from Gitlab and it saved me a lot of time to figure out how to setup the most important basics. Thank you very much!
I find your streams extremely helpful. Especially the wordle stream, since I also built a solver before and had lots of connections to the topic. It's also very helpful to see you encounter problems and watch you solve them. I've recently written my first more-than-hello-world program in rust and had it reviewed by two rustaceans. Both said they were impressed with the result, given I started one week ago. That made me very happy! I definitely learned _a lot_ from you after going through the awesome rustlings tutorial. A big THANK YOU for sharing your knowledge!
56:00 I'd call the additional work currently needed to declare accurate minimal versions "toil", not waste. Clearly, as you explain, the work output is useful, so the work is not "waste". "Toil" captures the "we could have a machine do this annoying work" much better. And we want to automate toil, but remove waste.
I'm currently learning about rust and its ecosystem. Would you mind elaborating why exactly this helped? To me it looked like his project now depends on old (and outdated) versions of stuff that should be up to date (like ssl). I might have missed a part though or don't exactly understand how cargo managed dependencies.
@flwi I think this was talking about minimum versions. This is not what regular cargo would use, but it allows folks stuck on older rust versions to still find a dependency solution when the newest versions of the dependency do not support that rust version anymore. Also when multiple libraries depend on the same thing, having accurate and lax lower bounds provides for more flexibility if not all of them agree on the upper bound.
Aanother useful result of your streams is that after looking Into the first part of it I went and fixed min dependencies in some crates and going to do this in some others. This brilliant teaching is a way to scale up efforts of improving the ecosystem. It works
Thanks for the video Jon. I've been aware of CI for some time, I've been curious about it and I've been meaning to learn more, but I don't have the time or energy to figure it out on my own. There's not too much info (that I've seen) presenting practical/applied CI from the Rust perspective. This video saved me a lot of time and effort, thank you!
42:44 - You may answer this in later Q&A but I have a question. Is "Hey, your versions are misspecified, you should probably use 1.2.3 for the minimum version of foo" the kind of bug report that you tend to push upstream? As a maintainer, If you saw a bug report like that, what information would you like to see?
I ought to file issues for these, but find that I rarely do. And I honestly don't really know why. Maybe it's a perception that many maintainers don't really care? Even though I don't actually have evidence for it. If I got a PR like that, I'd certainly be happy! Main info I'd want to see is that the crate doesn't compile with the minimal version as currently specified, but does compile with the updated minimal version.
Was the pain with cargo extra-bad because it is a binary that brings in a lot of dependencies that you are using as a library? Normally library authors are somewhat conservative with their deps, but I suspect Cargo isnt.
proptest is *destructively* obtuse -- it's very 'python testing' style -- adds a ton of oscurity and complciation and takes way more work and leaves you with something that is unobvious to maintain. I see what tehy're going for, but it's a bad model in most cases. QuickCheck is what's on the tin with straightforward ways to clean things up. QuickCheck is also inline with the idea of type based fuzing it ... fuzes the *type* by default. Not substructures within a type. -- PropTest has useful elements, but it adds more weight than value given that QuickCheck exists, in most cases imo
I'm currently at the point in the stream where you get asked, if your time isn't too valuable for streaming. And I just want to tell you, how much I appreciate your streams. This one has a huge impact on my work on Github and how to setup a CI/CD. It's different from Gitlab and it saved me a lot of time to figure out how to setup the most important basics. Thank you very much!
Definitely agree. Your videos are extremely valuable to me and have led me to buy your literature. Very good stuff, very hard to find elsewhere.
Invaluable content as always. The big concepts are gone over often, but the amount of tidbit information included is so hard to find elsewhere.
I find your streams extremely helpful. Especially the wordle stream, since I also built a solver before and had lots of connections to the topic.
It's also very helpful to see you encounter problems and watch you solve them.
I've recently written my first more-than-hello-world program in rust and had it reviewed by two rustaceans. Both said they were impressed with the result, given I started one week ago. That made me very happy! I definitely learned _a lot_ from you after going through the awesome rustlings tutorial.
A big THANK YOU for sharing your knowledge!
56:00 I'd call the additional work currently needed to declare accurate minimal versions "toil", not waste. Clearly, as you explain, the work output is useful, so the work is not "waste". "Toil" captures the "we could have a machine do this annoying work" much better.
And we want to automate toil, but remove waste.
I'm currently learning about rust and its ecosystem. Would you mind elaborating why exactly this helped?
To me it looked like his project now depends on old (and outdated) versions of stuff that should be up to date (like ssl).
I might have missed a part though or don't exactly understand how cargo managed dependencies.
@flwi I think this was talking about minimum versions. This is not what regular cargo would use, but it allows folks stuck on older rust versions to still find a dependency solution when the newest versions of the dependency do not support that rust version anymore. Also when multiple libraries depend on the same thing, having accurate and lax lower bounds provides for more flexibility if not all of them agree on the upper bound.
58:15 For what it's worth Jon, your videos have been EXTREMELY helpful and educational to me. It hasn't been wasted.
Also,
59:00 LMAO
Aanother useful result of your streams is that after looking Into the first part of it I went and fixed min dependencies in some crates and going to do this in some others. This brilliant teaching is a way to scale up efforts of improving the ecosystem. It works
I would love to see a stream just about coverage TBH. I found the coverage tools in the Rust ecosystem to produce a good bit of false positives.
Thanks for the video Jon. I've been aware of CI for some time, I've been curious about it and I've been meaning to learn more, but I don't have the time or energy to figure it out on my own. There's not too much info (that I've seen) presenting practical/applied CI from the Rust perspective. This video saved me a lot of time and effort, thank you!
42:44 - You may answer this in later Q&A but I have a question. Is "Hey, your versions are misspecified, you should probably use 1.2.3 for the minimum version of foo" the kind of bug report that you tend to push upstream? As a maintainer, If you saw a bug report like that, what information would you like to see?
I ought to file issues for these, but find that I rarely do. And I honestly don't really know why. Maybe it's a perception that many maintainers don't really care? Even though I don't actually have evidence for it. If I got a PR like that, I'd certainly be happy! Main info I'd want to see is that the crate doesn't compile with the minimal version as currently specified, but does compile with the updated minimal version.
this will be under 2 hours COPIUM
I love your videos jon, I'd have never become a rust dev without you
Wait, Rust 1.69 is dropping on 4/20? Nice.
twitter.com/bitshiftmask/status/1405549491558682627?lang=en
See also github.com/rust-lang/rust/pull/42069
damn, didn't expect to see you in youtube comments SeriousSloth
Thank you for your work and dedication!
Was the pain with cargo extra-bad because it is a binary that brings in a lot of dependencies that you are using as a library? Normally library authors are somewhat conservative with their deps, but I suspect Cargo isnt.
Thanks! super helpful 👍
10:17 wouldn't a git submodule also be a viable solution for the external ci setup?
It'd be a lot more annoying when you want to make local changes though.
Try a subtree
These videos are so helpful
Epic thanks
wish a video implementing Raft🙃
The Fluffy Dough of Rust
what are the chances that rust 1.69 is released on 4/20 ?
I hope the odds are... high.
someone meme 59:00
Implement raft algorightm
01:33:36
cursed browser layout
proptest is *destructively* obtuse -- it's very 'python testing' style -- adds a ton of oscurity and complciation and takes way more work and leaves you with something that is unobvious to maintain. I see what tehy're going for, but it's a bad model in most cases. QuickCheck is what's on the tin with straightforward ways to clean things up. QuickCheck is also inline with the idea of type based fuzing it ... fuzes the *type* by default. Not substructures within a type. -- PropTest has useful elements, but it adds more weight than value given that QuickCheck exists, in most cases imo