|
|
|
|
|
|
by aseipp
750 days ago
|
|
|
Honestly, I think the "stringly-typed targets" thing isn't too bad, having used Buck2 quite a bit, and being a Nix user for 10+ years. If anything, it's a small price to pay for some of the other smart things you get in return, like the far more fine-grained action graph and the tooling around BUILD files like querying. One weird benefit of that stringly-typed bit is that the BUILD files you have don't even have to meaningfully evaluate or even parse correctly, so you can still build other subsets of the tree even when things are broken; at ridiculous-scale it's nearly impossible to guarantee that, and it's something Nix does worse IMO since evaluation of the full nixpkgs tree is slow as hell in my experience but a requirement because a single eval error in the tree stops you dead in your tracks. Also, no matter how much I might not like it as a language nerd, I think Starlark is simply far more "familiar" for your-average-bear than the Nix language is, which matters quite a bit? It might be more complex in some dimension, but the problem space is fundamentally complex I think. So other factors like how approachable the language is matters. (And at least in Buck2, you can use MyPy style typing annotations, thank God.) |
|
|
I think you get more or less the same property with Nix. You can have all kinds of errors, even certain syntax errors in the same file, but if they are unneeded for the current evaluation, they won't cause any problems.
As for language familiarity/approachability - this will always be a matter of opinion, but I personally don't think it makes sense to optimize for the casual contributor. Plenty of people know python, but I never see casuals making anything besides trivial changes to bazel build files. I don't think they gain anything by familiarity with python, they could very well copy paste nix or any other language. And if they get in to trouble, they will call in the experts.