Crypto payment should be identical to how we do things in Asia: Method 1: Merchant shows a QR code which has the payment amount and destination embedded it in. I scan, biometric authentication, done. Also works when buying things online. Method 2: I create a QR code (requires auth). The merchant scans, and the money is automatically pulled from the account (this only works for in-person shopping). It’s really annoying to track which payment came from who using transaction hashes, and sometimes if the RPC is sluggish, you miss a transaction.

It’s worth your time to learn these programming languages, even if you don’t use them: 1/6 C C is on step removed from writing assembly. It forces you to understand the difference between “stack” and “heap.” You also must tangle with pointers — and training your brain to handle indirection will help you grok harder problems later as nearly every “hard” problem must be modeled with some level of indirection.

Uniswap v3 is simple: a bunch of cutted pieces of Uniswap v2 glued together. But boy, to explain that and make it clear, that is hard.

This is true. Our Solana series only needed 5 chapters on “just enough Rust to do Solana and boilerplate everything else.” Without Anchor, that would have been at least 15 chapters — and that would have been a real turn-off for the readers. Anchor does a great job hiding the more complex aspects of Rust (e.g. serialization and deserialization) while keeping the safety. Yes, you should at some point write a raw Rust Solana program for the educational aspect, but that’s very intimidating for someone who hasn’t used Rust/C++ before. I can say though, if everyone would just spend 15 minutes a day on @RareCodeAI, Rust mastery would be the norm. (And because I keep getting asked — more Solana content is coming soon).

The most important thing you can do for your career progression is not: - listening to people yap on a panel ❌ - approaching random people to have the same conversation over and over ❌ - partying at a side event ❌ It’s getting locked in and upskilling in something very fast. ✅ That’s what RareWeek is about.

The next Uniswap V3 article that comes out is going to blow peoples’ minds. This isn’t just because the animations are cool, but because what would normally be scary math feels extremely digestible. This is one thing that makes RareSkills incredible as a publishing company. We don’t just re-hash existing documentation or tutorials and make them slightly more oriented towards a certain audience. We re-work the underlying concepts from first principles and discover the best concept-map representation of the subject, then turn it into an article. When existing derivations aren’t good enough, we don’t make them better. We scrap them and re-derive them ourselves.

Based on early data I’m seeing from @RareCodeAI it takes about 20-30 hours of dedicated Rust practice to get to the point of “mastering” Rust. By “mastering” Rust I mean: - You can whip up a solution to a common problem (let’s say find strings in a set that are anagrams of each other) without straining yourself. - You can sense what syntax is available to you in an unfamiliar situation. - Most compiler errors don’t scare you and you can immediately recognize the solution to the most common ones. This 20-30 hours does NOT include: - reading tutorials - spending time figuring out what to practice and review - deciding if you should learn something new or practice something from earlier Without RareCode, I suspect the time required would be closer to 40 to 80 hours. So before you force devs to learn Rust to use your product, consider the fact that most people don’t want to go through 80 grueling hours.

Why should you learn recursion even if you will never use it? Recursive solutions train you on a few mindsets: 1. Rather than trying to generate the solution, you often start with “what is the structure of a valid solution” work backwards. For some problems, working backwards is much easier. 2. When you are solving the problem, it’s easy to get distracted by all the “what ifs.” When solving a problem recursively, you often forced to “ignore” 90% of the issues and focus on getting just one part right. 3. What would often be a “corner” case in an imperative solution is a “base case” in a recursive on. Thinking recursively sometimes forces you to not ignore the corner cases. Furthermore, recursive solutions make heavy use of pattern matching so you are forced to think of all the situations you could encounter. Here’s a really good example: Leetcode 335 Self Crossing (Hard problem). You travel on a spiral trajectory on a grid (i.e. always turn left after traveling some distance north, south, east, or west). The question is, “given the distance of each ‘segment’ of the spiral in order, did the spiral cross itself or not?” Although the solution to this doesn’t need to be a function calling itself, the “nice” solution uses recursive properties: 1. if we haven’t found a crossing yet, then we can assume there are no crossings or invalid spirals in the past. We furthermore notice that it doesn’t matter if we are traveling left, right, up, or down because we can only turn left. All we care about is if the previous segments are parallel to our previous turn and how far away they are. 2. when we turn left, there is an extremely limited number of “segments” in the spiral we can crash into, which is “recursively” true no matter how big the spiral gets. There are a lot of past data about the spiral we can ignore. 3. There’s a limited number of scenarios in your previous turn that affect your logic: a) did you travel far enough to not crash into anything, b) if not, what could you potentially crash into? (also limited). The annoying thing about Leetcode hards is they suddenly become easy if you find the key insight. But those key insights will come to you more naturally if you’ve trained yourself in recursive programming. It’s not just about designing functions that call themselves — it’s about forcing yourself to break the problem down in such a way that it can be solved with a function calling itself. The more ways you can break down a problem, the more likely you are to find an “aha” solution. Obviously, I don’t need to leetcode in my profession, but I do need to find creative ways to break down problems so they become understandable — and training in recursion has definitely helped with that.

Using AI to code is like being an astronaut on the moon. You can suddenly jump a lot higher and lift objects that would normally be too heavy. But in reality, you are becoming physically weaker through atrophy. To counteract this, astronauts need to be extremely disciplined about exercising to retain muscle. The way I see it, coders will spend most of the day using AI to build, but training — not only to avoid atrophy — but to increase in skill using @RareCodeAI and/or @RareSkills_io. In RareCode, the AI goes from doing work for you to becoming a coach to train you efficiently and avoid unproductive frustration and atrophy.

You can learn how to use Uniswap v4 without understanding how Uniswap v3 works, but knowing how to use it is different from knowing how it works. In Rareskills, you learn how it works.