The Missing Semester of Your CS Education (MIT course)
Thank you stranger. Shows the award.
When you come across a feel-good thing.
Shows the Silver Award... and that's it.
- By - Jonhoo
"Day in the Life" of open-source development in Rust [video]
Gives 100 Reddit Coins and a week of r/lounge access and ad-free browsing.
- By - Jonhoo
Best book after the official Rust book?
Shows the Silver Award... and that's it.
When you come across a feel-good thing.
- By - zxyzyxz
Making a Rust crate compile faster [video]
Thank you stranger. Shows the award.
When you come across a feel-good thing.
- By - Jonhoo
Nuggets about each and every (strict) Rust keyword [Twitter thread]
Shows the Silver Award... and that's it.
- By - Jonhoo
Crust of Rust: Send, Sync, and their implementors [video]
Gives 100 Reddit Coins and a week of r/lounge access and ad-free browsing.
Thank you stranger. Shows the award.
When you come across a feel-good thing.
- By - Jonhoo
Twitter thread with trivia about Rust types
Thank you stranger. Shows the award.
When you come across a feel-good thing.
- By - Jonhoo
Implementing and Optimizing a Wordle Solver [video]
Shows the Silver Award... and that's it.
Thank you stranger. Shows the award.
When you come across a feel-good thing.
An amazing showing.
A glittering stamp for a feel-good thing
[Happy crab noises]
- By - Jonhoo
Announcing Leapfrog, a faster concurrent HashMap
Shows the Silver Award... and that's it.
Thank you stranger. Shows the award.
- By - cata_lyst_
Implementing Hazard Pointers in Rust (part 4/4) [video]
When you come across a feel-good thing.
When you come across a feel-good thing. Gives %{coin_symbol}100 Coins to both the author and the community.
- By - Jonhoo
C++ boring Rust very fun
Shows the Silver Award... and that's it.
When you come across a feel-good thing.
- By - SirBanananana
What's New in Rust 1.56 and 1.57 [Rustacean Station Podcast]
When you come across a feel-good thing.
- By - kibwen
Leave a Reply
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!
Hi, is there a newer version after 2019 of this course and labs downloadable to non-MIT students? Thanks
The class is entirely open, and there have been no instances of it since the
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?
All of the content for the class is available on the website for everyone :)
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.
Look at how much easier the code is to read (and how much less error-prone it is) with
I didn't know that! The length of
Yeah, if you look at
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.
Thanks for clearing that up for us, Jon! (Great book btw <3)
Happy to! I agree it's a little vague. And thanks :D
It's a very dense book. It's light on code, no pictures. Top to bottom of just text.
I love this honest, high-level take on the book. So much so that I
Hmm, is that meaningfully different from pub use somecrate in src/lib.rs? I feel like I only ever really see that form?
I believe rustdoc renders it differently, which makes for a convenient way to be clear about reexporting a different crate entirely
Huh, yeah, you're right. For example,
The "0" there is the terminating null (ASCII code 0), not the character "0".
Yeah, I should arguably have specified it as b"\0"
[T]
[удалено]
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
Ooh, how hard would it be to extract out the nvim bindings into their own Rust crate for reuse by other plug-ins?
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! :)
Hehe, yeah, it's entirely out of habit. My brain knows it, but my fingers refuse to comply!
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.
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!
Hey, dashmap author here.
Sounds to me like we should extend the benchmark suite to also run with non-atomic types for the keys and values 👍
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)
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.
https://www.reddit.com/r/rust/comments/c3weuc/jon_gjengset_will_be_doing_an_ama_about_rust_live/
Haha, thanks for the notification! Not sure if real (source?), but gave me a laugh nevertheless.
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.
Ah, thank you kind stranger!
Thank you. This explanation makes a lot of sense.
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).
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.
Both great points, and thanks for the clarification!