Today, I accidentally found out that instead of using {:?} to debug print, if one just adds an extra # like {:#?} the variable is pretty printed. This makes sense for struct rather than simple data types like numbers or strings. The interesting part (for me at least) is how I “discovered” it 😄 When I was printing a struct (for debugging 🙈) VS Code (I think rust analyzer plugin) showed a popup how the struct does not implement Display 1
Continue Reading »It is (almost) drop-in replacement for pip. We just need to invoke it as uv pip instead of pip How to install ? pipx install uv : This makes it available everywhere. Other alternatives are curl (recommended) and brew (on macOS) It is superfast I tried installing Django $ uv pip install Django Resolved 3 packages in 138ms Downloaded 3 packages in 2.53s Installed 3 packages in 228ms + asgiref==3.8.1 + django==5.
Continue Reading »In rust, str is a primitive type, but many non-primitive types are also in scope by default. e.g. We do not need to add use statement to use Vec - which is NOT a primitive type. It comes from std::vec So Vec::new() is really std::vec::Vec::new() Vec::new() works because Rust inserts this at the beginning of every module: use std::prelude::v1::*; This makes Vec (and String, Option and Result) available by default.
Continue Reading »When I published my previous post on mastodon, Sebastian pointed out 1 that using #[cfg] is better than cfg! macro. Documentation explains that : cfg!, unlike #[cfg], does not remove any code and only evaluates to true or false. For example, all blocks in an if/else expression need to be valid when cfg! is used for the condition, regardless of what cfg! is evaluating. Thanks, Sebastian! See this thread for the original discussion.
Continue Reading »We all know we shouldn’t use print debugging, and yet we all do 😉 1 Jokes apart, when I’m still developing the code, I use the debugger where possible. But sometimes, I want to keep certain print statements to verify runtime behaviour, especially when rolling out new feature and when there are too many variations (some of them unknown) in incoming data. I’m aware, logging is the right way to handle this (with loglevel set to debug or something), but it seems too much when developing toy projects.
Continue Reading »At first, I assumed since we’ve declared the capacity upfront, it would be maximum capacity of the Vec Turns out, since Vec is expected to shrink and grow, as needed, there is no maximum capacity for Vec It just ensures that “sufficient” memory is allocated to the Vec, such that memory reallocation is not required. On the other hand, if you need more that what you declared with with_capacity, you will get it, but there will need to be reallocation (of memory), so it will be inefficient.
Continue Reading »Today I learnt that certain rust code can be marked such that it is compiled only for specific platform. This makes sense for low level libraries that provide platform-specific functionality that is not available on other platforms. This is achieved by tagging the function with #[cfg(target_os = "xyz")] Here xyz can be one of the following : “windows” “macos” “ios” “linux” “android” “freebsd” “dragonfly” “openbsd” “netbsd” Similar to target_os, here are other options :
Continue Reading »At least for floating point numbers, it does not crash/panic! 🤷♂ fn main() { let x = 10.0; let y = 0.0; println!("{:?}", x/y); } This above code returns inf But if we change the number to int, compiler catches this 1 at shows the following error: error: this operation will panic at runtime This is a contrived example. Instead of static values, if these were passed at runtime, it would (should?
Continue Reading »One of the strength of Rust is memory management. This also leads to compiler errors related to move or borrow When we assign an existing variable to new variable, two things can happen. Either the data is copied - in that case we can use both old and the new variable without worry. 1 Or data is moved - now we can only use the new variable, as the old variable is “out of scope”.
Continue Reading »(undocumented?) Zellij Keybindings Undocumented, because these don’t show up in the default configuration, which shows (I assume) most useful key bindings. I had to look for these, and found them in Github discussions/issues. Ctrl p d Ctrl p is for pane, but d after that (which I assume stands for down) is not documented. This creates a new terminal in horizontal split fashion 1 Ctrl n - to reduce the size of the terminal.
Continue Reading »