My free book "Rust Projects – Write a Redis Clone" is out

https://leanpub.com/rustprojects-redis

by thedigicat • 2 years ago

96 38 2 years ago

leanpub.com

stefanos822• 2 years ago

This book is 40% complete

Shall we wait until it reaches 100% first and then people buy it?

thedigicat4• 2 years ago

Hi! The book is actually free, you can set the price to zero. Anyway, whatever way you choose, you get access to all future versions. Thanks!

stefanos822• 2 years ago

That's not what I meant; Leanpub shows us that the actual book is INCOMPLETE, it's only 40% ready, not 40% discount LOL! :D

InkCanon• 2 years ago

The remaining 60% is trivial and has been left as an exercise to the reader.

zerr3• 2 years ago

Get it from Library Generis or similar places for now. Buy when it reaches 100% and if you feel it is worth the value.

tracker1• 2 years ago

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.

tayo42• 2 years ago

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

tialaramex• 2 years ago

"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.

nemothekid• 2 years ago

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.

lesuorac• 2 years ago

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.

pornel• 2 years ago

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.

rollschild5• 2 years ago

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.

kinow• 2 years ago

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.

rollschild5• 2 years ago

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.

rollschild5• 2 years ago

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.

ilrwbwrkhv• 2 years ago

Never pay for future promises. Looking at Tesla, the games industry, RougeDB.

Every single time it ends in failure and disaster.

diggan• 2 years ago

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 :)

Arcuru• 2 years ago

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.

https://github.com/accelerant-dev/implement-rougedb

dvt• 2 years ago

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?"

rollschild5• 2 years ago

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.

timClicks2• 2 years ago

I'm extremely sorry about this. It's been such a huge wait for everyone who supported me. Thank you so much for holding on so long.

I finally have time to complete the material and updates will start appearing in the next few weeks.

Also, I am more than happy to issue well warranted refunds.

dxps• 2 years ago

Your feedback is really appreciated, Tim!

Hope you'll keep the promise :) and in the next few weeks we'll get the content updated.

The whole scope as you layed out in the toc looks great!

jgarzik• 2 years ago

By amusing coincidence, I wrote a Redis clone in Rust: https://github.com/bloq/memds

andy_ppp2• 2 years ago

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!

thedigicat4• 2 years ago

Thanks! So, I didn't consider performances at all, as it's not the goal of the project, but it would be interesting to have a look. Good idea!

andy_ppp2• 2 years ago

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!

ubisol2• 2 years ago

Anybody knows if there is a golang version of a write a redis clone ?

thedigicat4• 2 years ago

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.

ubisol2• 2 years ago

Ok, thank you, I'll check CodeCrafters.

melon_taeppe• 2 years ago

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

My free book "Rust Projects – Write a Redis Clone" is out

Related Stories