@amiloradovsky I think the same problems would arise to typecheck package descriptions written in GNU Guile, no?
@otini Not quite. #Guix is splitting hairs much better, even despite #Guile #Scheme being also a dynamically-typed language.
Record types there, for example, have fixed set of fields with default values, AFAIK, so one cannot just put arbitrary stuff in there and expect it to pass through.
Actually, I'd say Guix already has some type-system, look at this for example:
There is definitely some static analysis going on.
@amiloradovsky If Guile has real record types with a fixed set of fields, that's probably better. I never quite understood where dynamic field labels where used in NIxpkgs.
See e.g. Acknowledgments in
There is much more, I'm sure.
And I heard several times that the lack of non-free s/w in Guix is a problem for them.
• If this is something "mission-critical" (assuming businesses have a mission lol), you may not want to expose it to the whole world for audit, especially if it's really cheap (e.g. site's back-end).
• If this is a tooling, needing constant support and integration with the rest of the world, let's "open-source" it and make hordes of jobless amateurs do all the dirty work… Plus get the badge of "open-source company" as a bonus, good.
functional.cafe is an instance for people interested in functional programming and languages.