FWIW, I’ve just started experimenting with std and I really like the approach. For me the biggest value is in it’s establishing standard patterns for the places where there are gaps in, for example, the nix flake output schema, and in allowing the community to start defining more enforceable standards without the main nix project or even std being a bottleneck.
More yapping on the value of convention and standardisation...
Whatever the stack, I love it when there’s a solid, well defined standard for stuff on the periphery of a project, like layout, code style, and similar conventions. That stuff is rarely the focus of the project, so I rather not spend time worrying about it. On the other hand, those periphery decisions also can end up being a real PITA to fix down the road, even if they’re inconsequential early on. It’s even more valuable when taking the first unfamiliar steps with something, when a lack of experience can make the “traps” invisible.
Coming from a Python background, PEP8 and now the black formatter are a godsend. Sure sometimes my personal preferences don’t align 100% with PEP8/black, but the value gained by being consistent with a wider ecosystem far outweighs the minor cost of having to slightly compromise on my preference. Since the standard is set by the larger community, no one on the team has to waste time discussing what style we should adhere to. We can refer to the standard when on-boarding people, but without having to document it from scratch ourselves (writing good documentation and standards is a difficult and under-recognised art IMO!). We also don’t have to reconfigure tooling for our own custom style. So it’s minimal effort for the team, but we get all the benefits that come from consistency, both internally and externally, like it being easier to grok code, since the style is familiar to the eye, and making it easier to spot bugs during review. Equally a good standard doesn’t tie our hands, it doesn’t have to be dogma. If there’s a good reason to deviate from the standard then we still can, and the fact those original decisions for PEP8 are well documented, makes it much easier to work out if the deviation from the spec is justified or comes with a unseen “trap” down the road.
Nix, even in the short time I’ve been using it, seems to have greatly improved standardisation and documented established conventions, especially when flakes came along, but there’s still plenty of gaps. Afaik the only defined output schema for flakes is the one on the wiki which itself just refers to the source for flake check. Nix has a huge potentially to be useful for all kinds of applications, but the schema for flakes doesn’t yet (again afaik) include a standard way to define a library function, or a data set, let alone the huge number of other outputs that it would make sense to standardise.
It seems std goes some way to close the gaps there, and provide a way for the community to start defining other enforceable defacto standards without the main nix project, or any single project, being a bottleneck.
I did really struggle with some of the core language, i.e. the cells, clades, organelles stuff. I think using relatively abstract language is a smart move, especially because it manages to mostly avoid reusing terminology with pre-existing associations, but it means the documentation is a lot more crucial to understanding the basics.
More simple examples would help a lot, and perhaps fleshing out some of the text in the existing “Hello World”. The other examples listed from the wild under the “Introduction” section were a bit too big and complex for me to use in my tentative initial learnings. I think some more super simple, guided examples of example the more general/popular clades would be useful both to bootstrap potential users, and to make it easier to understand the concepts. Maybe starting with data, then going on to nixago then devshells would be a good progression.
Another small thing was that the reference listing for the “Built-in Clades” confused me initially. I should have known better, but before everything clicked, especially for base abstractions, I naively thought those sections were examples of how to use the clades and not the definitions of the clades themselves. As a I say, that was daft of me, since it is listed under the reference section, but when for example I was trying to work out exactly what the devshells clade is for and how it’s used, it seemed like the only relevant link I could click.
Anyway love the project and look forward to using it more! Thanks for the hard work!
…