4 ms·

4-5 years ago I was first in line to claim that the Nix language needs a static type system. Now that we've seen what happens with languages like Cue I'm not so

by tazjin 5y ago

4-5 years ago I was first in line to claim that the Nix language needs a static type system. Now that we've seen what happens with languages like Cue I'm not so sure anymore. In a language like Nix there isn't really a distinction between compile time and runtime anyways and for cases where you want to check the shape of some data you can use e.g. yants[0]. The only difference would probably be slightly better error messages for incorrect type applications on builtins. [0]: https://code.tvl.fyi/about/nix/yants https://code.tvl.fyi/about/nix/yants

ncmncm 5y ago
I read lots of complaints about how hard it is to discover what types of arguments are needed and what types result for any particular function. If they were declared, there would be no need to dig and guess.
southerntofu 5y ago
> Now that we've seen what happens with languages like Cue I'm not so sure anymore. Could you maybe elaborate on this point? Or point me to other resources detailing this argument? I'm unaware of details about the cue project: i found it interesting on paper but when i never tried it as i personally consider it's useless as long as you can't validate data against an external schema (like JSON-LD or XML schemas). > The only difference would probably be slightly better error messages for incorrect type applications on builtins. Why only on built-ins though? If nix was statically typed, every package could define its own types for configuration/overrides and entire documentation could be auto-generated. I was not aware of yants, it looks great but it sounds like something that would be very useful as part of nix itself (like a nix check command). I love nix/guix as a concept but every time i've tried i've been been put off by severely-unintelligible errors due to bad typing or simple syntax errors (due to my lack of experience of what to use where and lack of documentation on expected types).
Kinrany 5y ago
I'd also like to read about people's experiences with Cue. > In a language like Nix there isn't really a distinction between compile time and runtime anyways This is very true, but exactly for this reason Cue's unified approach of having types be values seems like a good thing. Perhaps Cue is missing the ability to create new abstractions? I guess Turing-completeness may be necessary for this after all.

by tazjin 5y ago

ncmncm 5y ago

I read lots of complaints about how hard it is to discover what types of arguments are needed and what types result for any particular function. If they were declared, there would be no need to dig and guess.

southerntofu 5y ago

> Now that we've seen what happens with languages like Cue I'm not so sure anymore. Could you maybe elaborate on this point? Or point me to other resources detailing this argument? I'm unaware of details about the cue project: i found it interesting on paper but when i never tried it as i personally consider it's useless as long as you can't validate data against an external schema (like JSON-LD or XML schemas). > The only difference would probably be slightly better error messages for incorrect type applications on builtins. Why only on built-ins though? If nix was statically typed, every package could define its own types for configuration/overrides and entire documentation could be auto-generated. I was not aware of yants, it looks great but it sounds like something that would be very useful as part of nix itself (like a nix check command). I love nix/guix as a concept but every time i've tried i've been been put off by severely-unintelligible errors due to bad typing or simple syntax errors (due to my lack of experience of what to use where and lack of documentation on expected types).

Kinrany 5y ago

I'd also like to read about people's experiences with Cue. > In a language like Nix there isn't really a distinction between compile time and runtime anyways This is very true, but exactly for this reason Cue's unified approach of having types be values seems like a good thing. Perhaps Cue is missing the ability to create new abstractions? I guess Turing-completeness may be necessary for this after all.