• 33 Posts
  • 462 Comments
Joined 2 years ago
cake
Cake day: June 15th, 2023

help-circle

  • I don’t know of a service that tracks all major repositories to calculate a single popularity index. They are not really comparable to each other anyway.

    Depending on what type of application you search for, I think “Flathub” could be one major source. It’s a pretty popular “platform” and not dependent on a certain distribution. There are “Trending” and “Popular” categories too. It’s excellent to find some new software (or to remind an older one exist) in my opinion. You don’t even need to install the Flatpak and can do it from Archlinux repositories (or the AUR if you prefer).



  • I explicitly only use it with features --derive. It let’s you write the cli option setup as a struct, which feels super natural to me. That’s why I know for a fact it works well. Look in your Cargo.toml under the section [dependencies] there should be an entry for clap: clap = { version = "4.5.41", features = ["derive"] } is mine. Right now version 4.5.48 is the newest I think.

    Also from your previous reply, what do you mean “unless i do the implied version, but then it can’t derive features”? I don’t know why you shouldn’t be able to use derive. I’m no expert either BTW, just wondering what went wrong.

    Edit: typo


  • Right now I am working on a Rust cli tool with clap and have no issues with the LSP in Neovim. It might be a configuration error. Clap is used by many and is the defacto standard cli parser in Rust. As a fan of argparse in Python, I think clap is even better. argparse being implemented as standard library is the biggest pro over clap. I wouldn’t even use getops anymore, unless it is a Bash script. And even so, Bash has its own builtin argument parser that I use for scripts.

    If you really wanted to try Rust, you should sort of that issue. Clap works great and lot of users use it. Who knows, you may even end up liking it and Rust.

    Edit: BTW which example do you refer to exactly? I looked at the official ones and couldn’t find: https://doc.rust-lang.org/stable/rust-by-example/


  • I think these incidents like a calculator leaking 32GB are not the problem in the industry. These are isolated issues, and fixable as you say. The bigger problem are many “smol” programs are written without performance in mind at all, with crazy languages like JavaScript, its bloated environment and runtimes and frameworks like React and a huge browser to run it. While they do not leak memory like crazy, they hog a lot and people accept it. If all programs are like this, then you end up doing 16GB for simple tasks (random number chosen for likes), while the 32 GB leaked app is corrected and now just uses 200 MB at max (just random number again, to illustrate my point).



  • About Immutable Data:

    The most obvious benefit of this is that it is easier to reason about code when you don’t have to worry about the “current” state of any internal data.

    My own phrasing about this subject: With mutable data, the state is no longer encoded in programming code itself, rather a temporary state you have to calculate in your head. That’s why people need debuggers, to help pausing at a time and see the current state and analyze each step in between all immutable states; which can be endless, depending on the input.



  • I handle comments for blocks of code like functions (besides nor arguments). Sometimes this commenting style opens my eyes to abstract it away or just to create a named function call in place. Depending on context and rest of the code off course. Comments should be high level for blocks. I try to avoid any commenting for single line. Sometimes line comments are signs to restructure or rename stuff.

    For if blocks, when needed (first try to avoid the need for comments) a summary at top is added. And only then if needed, in each sub-block (under if, or else if or else) parts comments could be added, for additional context. I probably break my rules more often than I should, but that’s at least my goal.