1. This is a very valuable model to bring into these discussions, especially so because it gives both terminology and categorizations that can be used to more precisely identify gaps and tradeoffs across different groups of people. Thank you for taking the time to write it up so eloquently!

  2. Hi, is there a newer version after 2019 of this course and labs downloadable to non-MIT students? Thanks

  3. The class is entirely open, and there have been no instances of it since the

  4. Some of the topics ( profiling, perf tools etc) seem pretty good. Are there any lab or github page for the assignments that non-MIT students can access?

  5. All of the content for the class is available on the website for everyone :)

  6. I disagree with the is_helper macro. Code duplication seems problematic to me when it also duplicates information which could get out of sync and cause bugs, for example #[repr(u8)] enums and their Into/TryFrom implementations.

  7. Look at how much easier the code is to read (and how much less error-prone it is) with

  8. Ah, so, what I'm trying to get at here is that if all you need from the map is FromIterator (that is, you're only going to do .collect() into a HashMap or call from_iter directly), then you can use that bound. In your linked case, you're not using FromIterator, you're trying to call ::new and .insert, so the fact that HashMap implements FromIterator isn't sufficient.

  9. Thanks for clearing that up for us, Jon! (Great book btw <3)

  10. Happy to! I agree it's a little vague. And thanks :D

  11. It's a very dense book. It's light on code, no pictures. Top to bottom of just text.

  12. I love this honest, high-level take on the book. So much so that I

  13. Hmm, is that meaningfully different from pub use somecrate in src/lib.rs? I feel like I only ever really see that form?

  14. I believe rustdoc renders it differently, which makes for a convenient way to be clear about reexporting a different crate entirely

  15. Huh, yeah, you're right. For example,

  16. The "0" there is the terminating null (ASCII code 0), not the character "0".

  17. Yeah, I should arguably have specified it as b"\0"

  18. Really interesting article — I love the visualizations! One observation is that you're doing closed loop time workload generation, which tends to lead to super weird artifacts in the produced data. Specifically, it causes tail latencies to look a lot larger than they are, but also makes it seem like there are fewer slow samples than there should be! There's a lot more detail in

  19. Ooh, how hard would it be to extract out the nvim bindings into their own Rust crate for reuse by other plug-ins?

  20. This is obviously very minor and not really relevant, but I noticed that you often git commit -am “some message” and then git commit --amend to add a second line to the commit message. You may have been doing this for some reason I haven’t inferred, but FWIW you can do this in one step by just doing git commit -a in the first place. Thanks for the great video! :)

  21. Hehe, yeah, it's entirely out of habit. My brain knows it, but my fingers refuse to comply!

  22. So FST can store a list of &[u8] and filter using an automata (like a RegExp) very efficiently. If DICTIONARY is trend into a FST, then we can find remaining quickly. Or even go directly to statistics about remaining. Is that "quickly" as compered to the incremental approach your where working on. I don't know.

  23. Hmm, that could maybe work, though I worry that the state space is super large, even with the minimizations that FSTs allow. Specifically, the challenge (I think) arises in that it's not just "which words match this pattern", it's "which words match this pattern against this word", and then taking the intersection of that against the words you currently have (that part might be efficient). I may be missing an obvious different approach to the problem though!

  24. Sounds to me like we should extend the benchmark suite to also run with non-atomic types for the keys and values 👍

  25. I make a podcast about this! In general, just take your time and don’t be afraid to ask others to walk you through what they’re saying slowly — I think players have a tendency to make logical leaps, which, while correct, aren’t easy to follow. So asking them to repeat their reasoning and listening with an open mind can help you make the same deductions (and occasionally, call out someone with incorrect logic)

  26. I'll also add that oftentimes playing confidently is a skill in and of itself, regardless of whether you're right or wrong, and regardless of whether you know that's the case. Sometimes you have to confidently proclaim things you know are false (because you're evil and want to throw off a scent, or you're good and want to throw off evil). And sometimes you're just wrong and don't know it, but you're still confident. Ultimately, this means that your perception that other players are so good at deducing things can often just be that they are good at projecting confidence (whether warranted or not). So before you conclude that they're a bona fide Holmes, check how often they're actually right! And consider whether you might up your game simply by focusing on a) confidently asserting things, and b) seeing through the false confidence (and hole-y logic) of others.

  27. https://www.reddit.com/r/rust/comments/c3weuc/jon_gjengset_will_be_doing_an_ama_about_rust_live/

  28. Haha, thanks for the notification! Not sure if real (source?), but gave me a laugh nevertheless.

  29. In the original video the student was watching a math lecture in the first frame and star wars in the second if I recall correctly. I will look for the original as I just saw it a few days ago.

  30. Ah, thank you kind stranger!

  31. Thank you. This explanation makes a lot of sense.

  32. Ah, so, the book is trying to give very specific guidance here: the HashMap: FromIterator<(K, V)> bound is a great way to say that your code needs only exactly that impl and whatever is in turn required for that to hold. In your case, your function also depends on being able to use the K through the entry API, which is a different API that would also need to be represented in the bounds (clearest expressed with K: Hash + Eq).

  33. Towards the end, Jon mentions an improvement to File::read_to_end. Two notes on that. Firstly, he says that the previous implementation was "sort of exponential". I'm sure Jon knows this, but biiig emphasis on the sort of part. Vec does a very good job of guarding its algorithmic time complexity guarantees. In that parlance, this patch only reduces a constant multiplier on the runtime. This change is still a sweet performance improvement, just don't want anyone to get the wrong impression about the previous behavior.

  34. Both great points, and thanks for the clarification!

Leave a Reply

Your email address will not be published. Required fields are marked *

News Reporter