This reminds me of Tim McNamara's course Implement RougeDB, a Redis clone from outer space (https://learning.accelerant.dev/view/courses/implement-rouge...). I paid somewhere around $100 for this course (through some coupon code, I remember the original prices was $200-ish). It was supposed to be completed by Aug 2023, yet almost one year and a half later, it's still incomplete. I almost gave up at this point.
Wow, and their current "pre-sales" price is $280. No wonder they don't have any dates on that page, or link to the Github repo that hasn't been updated in over a year.
Learned that lesson in 2018 when I gave 500 EUR to Tesla (Spain) as a deposit for a Powerwall. Never heard another word from them. Been sending an email ~once a year to try to claim it back but not once I have got an reply. Never again.
Next step is to go to small claims court, but who has the time/energy to deal with bureaucracy... Future project :)
Have you reached out to Tim? I know him and I believe he wouldn't do that intentionally. Maybe he is busy with something else or just lost track of the schedule.
Of course I did. I DM'ed him on Twitter with no response. Then I commented under one of his tweets and he did respond. He mentioned it would be complete by Aug 2023 (this was before Aug 2023). Some time this year I commented under one of his linkedin posts asking for update - no response. There are multiple comments from other users on that web page I linked above - most of them had no replies.
Of course he's been busy. Everyone is busy. But charging $200 (or $100 with coupon) for a course which is delayed for more than 1.5 years and still has no sign of completion is another story.
Not yet. I'm willing to pay for stuff like this. I was reading Tim's Rust in Action at that time and I liked the book so when he announced that he was starting such a course I immediately singed up, although the price was a bit crazy. I got the coupon code from a guy on Reddit so that's pure luck. I am really willing to pay for other peoples IP. I am still hoping that one day he could complete the project but before that I've got some other projects to work on.
Side note: I've finished Build your own Redis in C/C++ (https://leanpub.com/build_your_own_redis) and it's pretty decent. The title of the book is a bit weird since it's almost 100% C++ so I don't know why they put "C" in there. But it's a pretty decent book (and reasonably priced).
One thing I want to add is, it's _not_ my job to reach out to him asking for an update. It's his job. If he could maintain a monthly (or even quarterly) email list with all the updates it would be a way better communication strategy.
This kind of (ahem) "business model" has become rampant. We easily call out crypto scams, but the "buy now, I'll finish it whenever" strategy has been rotting away at the core of the internet since Kickstarter became a thing.
I mean, Tim McNamara's course is literally a scam. You paid full price (minus the coupon) for a product that was never delivered (and likely never will be), sold to you based on hype and Twitter clout. What the actual fuck? How many people were defrauded, but were just like "meh, what's a few hundred bucks?"
Well, like I mentioned in my other comment, I really liked his book Rust in Action so I signed up for his course, despite the price. But yeah, maybe it _is_ a scam at the end of the day.
Haven't read the book. I feel like this is effectively "Rust: The Hard Parts" as a topic. Mostly in that from my admittedly limited understanding of rust, lifetimes and shared memory, Redis in rust semantics is almost an anti pattern.
I intend to look into this book as I find the topic interesting. But do feel that it's tackling some of the more cumbersome areas of rust. I'm also curious if there will be an effort to be binary file compatible.
With the Redis licensing kerfuffle and since fork of valkey I wonder about some of the other redis alike databases there are and will be. I think that rust is just a hard fit for this use case. But who knows.
I think redis design is probably easy becasue it's single threaded. So probably not
But wasn't the use you described the whole point of rust getting alot of investment from Mozilla in the first place. The browser had all those problems you describe and they thought the language makes it easier
"Fearless concurrency" yes. In Rust's model we can't make a lot of the easy mistakes. Safe Rust won't let you, for example, try to share an Rc<T> between two threads, because while Rc<T> is perfectly sound and has good performance locally, if it's possible for two concurrent operations to touch the object bad things may happen, so we can't ever (in Safe Rust) see such an object from more than one thread - in this case you should use the (more expensive on some hardware) Arc<T> if there might be more threads.
In safe Rust understanding why all this works isn't your problem, it just does. Hardcore implementation work (say, you're making a new kind of mutual exclusion primitive) will need unsafe and also rely on proper understanding of how to (and whether to) enable use of your type this way.
No, it's not a problem at all. There are already several high-performance databases written in Rust.
Lifetimes are mainly a learning barrier for new users, and affect which internal API designs are more convenient, but they're not a constraint on the types of applications you can write.
Rust strongly guides users towards using immutability and safeguards uncontrolled shared mutability, but you can use shared mutable memory if you want. In single-threaded programs that's trivial. In multi-threaded programs shared mutability is inherently difficult for reasons beyond Rust, and Rust's safeguards actually make the problem much more tractable.
Writing a Rust clone was one of the first projects I did when trying to learn Rust ~4-5 years ago. On top of that I opted for an async version with a database-per-core design.
Throughout the whole project I never once ran into lifetimes, and I gave up once I had to think about cross thread transactions, which had nothing to do with Rust the language.
Well, I don't exactly know your scope but I was doing stuff the other day with sqlite and using it on a single thread while having a multi-thread webserver. My solution was to have a wrapper that's "multithreaded" and it'd just accept a `FnMut(transaction) -> Result<T,DbError> + Send + Sync + static` and queue them internally so they ran one at a time. Since all the lambdas are "hardcoded" (like the rest of my source code) the static requirement isn't a big deal.
My main problem with it is that I ended up de/serializing T across the FnMut boundary. But given that the FnMut knows what T is it seems like there should be some way to use unsafe and pointers to remove the serialization if it's ever a performance problem.
I guess what the other person means is that there is no "buying", you can take the book for free. Yes it is incomplete but you'll get access to future work on the book.
So, just out of interest how close does this get to the performance of redis? It’s interesting to see a highly optimised production product compared to a presumably more trivial implementation I can read in a book. Still this might be a great way to learn rust!
Yes it's definitely not about winning, if you can get say 75% of Redis performance with simpler and memory safe code I'd say that is a big win and great advertising for the book! And maybe some examples of how performance can be improved/optimisations made also improves the book!
You might be able to get near 100% of Redis performance without a lot of tuning. Redis has a lot of overhead to make it a production ready system like performance counters, safety checking, and conditionals for features like replication/clustering/etc which slows it down.
Hell, you might even be able to use a concurrent hash map implementation and show multi-threaded performance much better than Redis :).
You can solve the CodeCrafters challenges in many languages, and Go is one of them, yes. Not sure if there are books or blog posts about it though. Through the CodeCrafters portal you can access the code of other people and the related repositories, however, so that can help.
I was doing the codecrafter course then went off-script when creating the parser, this is good to have all the steps in one place so I dont need to jump through the hoops on the website
