• 3 Posts
  • 40 Comments
Joined 1 year ago
cake
Cake day: June 27th, 2023

help-circle



  • It’s not that the author picked Rust for scripting. All Rust game engines (e.g. Bevy) use Rust as the scripting language.

    Compare this with Godot, which is implemented in C++, but supports GDScript and many other languages for scripting.

    Also, only supporting Rust is not considered a limitation, but a feature here. Bevy’s ECS is tied up with Rust’s trait system, therefore it’s impossible to use a different language.

    So if Rust as a system programming language should not be used for game scripting, then projects like Bevy are fundamentally flawed. The author is willing to go there, but I don’t know if many people would go that far.

    There could be a Godot-like engine written in Rust that supports easier scripting languages, but I think that space is not explored due to the fact that Godot already exists.






  • If you execute a binary without specifying the path to it, it will be searched from the $PATH environment variable, which is a list of places to look for the binary. From left to right, the first found one is returned.

    You can use which cat to see what it resolves to and whereis cat to get all possible results.

    If you intentionally wants to use a different binary with the same name, you can either directly use its path, or prepend its path to $PATH.





  • The original “agile” is a reaction to the overly rigid planning and emphasizes worker self-management. It makes sense since the people who are closest to the work (the workers) know best how to plan and implement the work.

    It immediately breaks down when a specialized management tier emerges and tries to push their own agenda, i.e. to sell themselves rather than do something meaningful.

    At this point, whichever form is used doesn’t matter. The management, endowed with the power from above, will exploit the weakness of any agile-shmagile methodology to push their own agenda.



  • As other comments point out, they are usually not properly packaged through nix.

    If you read the vim/plugins modules, for most plugins, the derivation just downloads the plugin, puts it to nix-store, and makes it available to the editor through environment variables. So it’s similar to the binary distributed software. Two most notable restrictions:

    1. Nix is not aware of transient dependencies.
    2. The plugin is not aware of the nix-store model.

    So for plugins that don’t have external dependencies (or dependencies other than the “common” ones like python or sh that happen to be available), and that don’t interact with the filesystems, this approach would be fine, but the more complex ones would fail.

    In your example, mason failed because of 1, home-manager wasn’t aware that the pip module is a transient dependency of this plugin; and treesitter failed because of 2, because it doesn’t know that nix-store is read-only and should be managed by nix.

    There are no general solutions, but people may have nixified some plugins on a case-by-case basis. If you don’t want to spend a lot of time (and remember that it might be broken by the next plugin upgrade), as others have suggested, take the traditional plugin management approach. (Personally, I use LunarVim which uses Lazy.nvim and it’s been working fine.)



  • To be good at programming, a lot of knowledge is needed, but “accidental”. From practical ones like how to use git, to conceptual ones like cache performance mental model. It’s perfectly possible that git is designed with a different CLI, or the common cache line size being 512 bytes. Mathematicians usually don’t care about these things, since they are accidental. So they are bad at writing programs that’s far away from math.

    It’s a completely different story when they are writing programs about math. If the tool is good enough, i.e. allowing them to express math ideas in familiar terms, mathematicians are very good at writing math programs. As can be observed in Lean and mathlib.