I learned SQL before pandas. It's still tabular data, but the mechanisms to mutate/modify/filter the data are different methodologies. It took a long time to get comfy with pandas. It wasnt until I understood that the way you interact with a database table and a dataframe are very different, that I started to finally get a grasp on pandas.
A big feature of polars is only loading applicable data from disk. But during exporatory data analysis (EDA) you often have the whole dataset in memory. In this case, filters wont help much there. Polars has a good page in their docs about all the possible optimizations it is capable of. https://docs.pola.rs/user-guide/lazy/optimizations/
One I see off the top is projection pushdown, which only selects relevant columns for a final transformations. In pandas, if you perform a group by with aggregation, then only look at a few columns, you still perform aggregation across all the data. In polars lazy API, you would define the entire process upfront, and it would know not to aggregate certain columns, for instance.
Its a paradigm shift from pandas. In polars, you define a pipeline, or a set of instructions, to perform on a dataframe, and only execute them all at once at the end of your transformation. In other words, its lazy. Pandas is eager, which every part of the transformation happens sequentially and in isolation. Polars also has an eager API, but you likely want to use the lazy API in a production script.
Because its lazy, Polars performs query optimization, like a database does with a SQL query. At the end of the day, if you're using polars for data engineering or in a pipeline, it'll likely work much faster and more memory efficient. Polars also executes operations in parallel, as well.
I lean on nixos modules first, but half the time it either doesnt exist or its too complicated at first glance. So I will manually create an oci-container configuration by referencing a docker compose on the projects site. For simple compose files this is easy. Sometimes its not easy, and I dont end up deploying it.
I've been wanting to find or build a method that lets me drop a compose alongside ny config and have nix load the yaml and build the oci-container configuration for me. That would be nice since Im familiar with compose syntax and it's usually easier to write imo.
I used Zola for a while, but at the end of the day there wasnt enough themes available that fit what I was looking for. I ended up messing with the templating engine to get what I needed.
I suggest OP choose Hugo over Zola, in the hopes that they find a theme that suits them best and for the most part prevents them from having to touch templating to begin with.
I recently built a site with hugo. Its very easy. You pick a theme, then write some markdown files. And when you need flexibility, you have it for later. I also think it's the most popular right now, which lends to a lot of themes to pick from and a lot of cpmmunity support.
I use a declarative flatpak flake that lets me install flatpaks declaratively. You could use this as well, in case you want to manage the flatpaks in your configuration.
I've used minio briefly, and I've never used any other self hosted object storage. In the context of spinning it up with docker, it's pretty easy. The difficult part in my project was that I wanted some buckets predefined. The docker image doesn't provide this functionality directly, so I had to spin up an adjacent container with the minio cli that would create the buckets automatically every time I spun up minio.
But for your use case you would manage bucket creation manually, from the UI. It seems straight forward enough, and I don't have complaints. I think it would work for your use case, but I can't say its any worse or better than alternatives.
I think this is good idea. If the modules/options you are writing are for internal use, and not expected to be shared with the wider community, then this is great. I should incorporate this in my own config, but I dont know if this is common practice.
I learned SQL before pandas. It's still tabular data, but the mechanisms to mutate/modify/filter the data are different methodologies. It took a long time to get comfy with pandas. It wasnt until I understood that the way you interact with a database table and a dataframe are very different, that I started to finally get a grasp on pandas.