<kiwiirc>
what would it take to add static typing to nix?
<__monty__>
Starting from scratch.
<kiwiirc>
ah dang. that being thought about?
<puck>
basically, yeah
* __monty__
HHOS : /
<puck>
i've been kinda thinking about a replacement for nixlang that is more statically typed
<puck>
but nothing concrete
<kiwiirc>
cool! pls take any good features from rust
<__monty__>
Rust isn't all that close. What features are you thinking of?
<__monty__>
Imo it should remain a GCed language. So much easier to work with.
<mgdm>
if you're going to go that effort would you implement a complete new language or create some kind of DSL using existing syntax?
<kiwiirc>
nothing specific in mind cuz i haven't learned nix yet
<__monty__>
Nix is already a DSL. Do you mean an eDSL specifically?
<puck>
tbh nixlang is pretty much a general purpose programming language
<puck>
the evaluator has some bugs preventing tail recursion from occuring but otherwise it's turing complete
<__monty__>
Only insofar as turing tarpits are general purpose languages imo.
<puck>
i compiled a C compiler to nixlang, and it only didn't work because of the tail recursion bug
<puck>
and i can get dynamic input / output
<__monty__>
Using what subset of nix?
<puck>
nixlang, plus toFile and pathExists (i'm considering these part of nixlang as they're part of libexpr)
<mgdm>
__monty__: I tend to use DSL to mean eDSL, so yeah
<puck>
__monty__: note that i already wrote a multiplayer game in nixlang, so things like "compiling a c compiler to nixlang" isn't out of my expertise :p
<kiwiirc>
impressive
<kiwiirc>
is software in the nixpkg repo not only installable to a system like nixos, but also usable as libs in nixlang progs?
<__monty__>
puck: I was more referring to nix's equivalent of accursedUnutterablePerformIO.
<puck>
__monty__: yes, you could call my hacks that
<kiwiirc>
ppl have been talking about how to make a repl friendly rust variant. it would be amazing if that ended up being a worthy 'nixlang 2.0'. rather than using a niche lang, using one that's being used as a general purpose one
<kiwiirc>
i think it would make nixos/ops/etc huge
<kiwiirc>
it'd more or less be rust but removing stuff that isn't needed or ideal for repl/scripting. so gc, no lifetimes, static typing optional failing back to inference, stuff like that
<__monty__>
Nix not really being general purpose is a selling point. Packages writting in such a rich language are already a hard sell.
<kiwiirc>
in some ways maybe but not in others, cuz it's yet another thing ppl gotta learn. but if it was a lang they already use to code all day, it's really just having more stuff that you can do for free, like 'code' your system config, infra/cm, etc
<__monty__>
Then it should be C or Java. Rust is way to niche for it not be "a new thing you gotta learn."
<kiwiirc>
nah it might be new but rust is gonna be bigger than js
<kiwiirc>
like C and js combined
<__monty__>
Good DSLs are so focused there's not much to learn and you can pick them back up by reading a DSL-in-20minutes! overview.
<kiwiirc>
ya that's true, but then they're on the limited side of the spectrum
<__monty__>
Which is a bonus imo.
<kiwiirc>
like any dev can pick up a new format, toml, yaml, ucl, whatever in an hour or less, but it's another thing
<kiwiirc>
why?
<__monty__>
Because simple is better than complicated when it comes to the infrastructure that defines your system.
<kiwiirc>
you could make the same argument about the code you run, yet ppl prefer full langs over dsls for dev (meta programming aside)
<jtojnar>
what makes infrastructure definitions different from any other program?
<kiwiirc>
and i disagree that simple is better. i think complex enough but no more, is the right goal and not simple
<kiwiirc>
agreed jtojnar
<kiwiirc>
i used to think as monty is about this, until i ran into limitations with ansible scripts enough to see the reality behind "any sufficiently capable config lang is indistinguishable from a shitty programming lang"
<kiwiirc>
so then i became convinced i'd like the same lang for everything, with perhaps a couple variants for context (compiled, data serialization format, and interpreted code)
<kiwiirc>
like in rust, rust, ron, and whatever repl variant ppl come up with
<kiwiirc>
ron being rust object notation
<__monty__>
I prefer the nix approach to the guile approach. It's much harder to lose purity of expressions.
<kiwiirc>
what's guile?
<kiwiirc>
i remember playing as him only
<__monty__>
The language guix uses.
<kiwiirc>
i don't know what guix is i'll search it
<__monty__>
Cryptol is a great example of a DSL that's just better than a general-purpose language used in its place would be.
<kiwiirc>
i havent learned nixos yet so i can't put a quick read about guix into total context but it sounds similar
<kiwiirc>
but why? what about cryptol makes it better to use for nixlang's purpose than a general purpose lang?
<jtojnar>
Cryptol looks like Haskell + syntax sugar for bit string type
<__monty__>
That's not at all what I said. Cryptol is an example of a DSL that's superior to general purpose languages for its purpose.
<__monty__>
Which also means it'd be horrible as a replacement for nix. Probably unusable.
<kiwiirc>
k but my original thought, why would a general purpose lang being used for other things not be better to base nix on?
<jtojnar>
it looks good but you trade the tooling of estabilished language for convenience of DSL (and I am not sure the difference is big enough to justify that, compared to Haskell eDSL)
<kiwiirc>
yes, and its ecosystem of available software
<kiwiirc>
like what i asked earlier, if nix can use software to both install onto a system, as well as in a nix program directly. that would be amazing
<kiwiirc>
let's say you're doing nixops and you wanna generate a number with a certain algorithm to be used for the qty of new servers to provision and deploy, maybe fib sequence based or whatever, way easier to grab an existing module than need to shove more functionality into the niche config lang
<__monty__>
kiwiirc: That'd mean giving up on purity. Throwing out the reproducible builds baby with the slight inconvenience bathwater.
<kiwiirc>
or let's say you wanna source data via an api call, have fun adding that to a config lang
<kiwiirc>
hmm
<jtojnar>
Nix does not allow that (without plug-ins) since it could no longer maintain purity
<kiwiirc>
if purity is based on the composition of config lang, why couldn't it be based on the logic of the program?
<puck>
kiwiirc: this is a thing that kinda exists
<kiwiirc>
like rust has MIR and LLVM has IR
<puck>
you can read the output from derivations
<__monty__>
kiwiirc: Because an HTTP request is *not* pure. The way nix kinda gets around that currently is hashes.
<kiwiirc>
hm that makes sense
<kiwiirc>
i suspect there's some way to bridge it tho
<kiwiirc>
really great point tho that'll be a fun challenge to think about
<kiwiirc>
ive wanted what i'm talking about for so long and wondered why it's not already done and i knew there had to be an endboss engineering challenge or two lurking
<kiwiirc>
it's kinda related to the oracle question in blockchainy stuff
<jtojnar>
kiwiirc also, are you familiar with Dhall? There is dhall-to-nix
<kiwiirc>
when you guy think about what a worthy nixlang 2 would be, what's that look like? i know puck's thinking static typing
<__monty__>
What you were originally asking for (nix as eDSL) is already kinda working on with rust-nix(?) and hnix.
<kiwiirc>
no never heard of it ill search
<__monty__>
Yes, dhall is pretty much my ideal nix-lang.
<kiwiirc>
ah nice
<__monty__>
Haven't actually thought through implications.
<kiwiirc>
seems like a serialization format for program logic
<__monty__>
kiwiirc: Doubt you'll be happy with it. It's stricter than nix.
<kiwiirc>
so what you could do is have a set of valid keys for the various contents, and by restricting that you could ensure your purity space
<kiwiirc>
i'm never happy, monty
<__monty__>
Dhall's pure. So you still can't do the things you think you want.
<kiwiirc>
well ya im not saying dhall is what i want, it's not a general purpose lang first off, it just looked neat at a glance
<kiwiirc>
so dhall is more restrictive than nixlang yet it's your ideal, so what does nixlang have that you think is too lose?
<kiwiirc>
loose*
<__monty__>
Its untypedness leads to flexibility that's just confusing for little to no reason.
<kiwiirc>
ya i'm with you on typing. cool that you think that, i wouldn't assume since ur not in favor of a general purpose lang
<__monty__>
I'm in favor of everything that limits the amount of "cool hacks" you can do. Be that DSL or static typing : )
<kiwiirc>
so if that's the goal, why have i seen nixlang promoted as a general purpose lang? seems that's counter to its goals
<__monty__>
Not sure where you've seen that?
<kiwiirc>
only outside nix channels, so prolly misunderstandings or misrepresentations by non-users. maybe the fact that it *can* be got confused with that not being nix's goal
<kiwiirc>
would be nice to restrict anything not explicitly intended tho, like with dhall or whatever
<kiwiirc>
"oh hey look at that hammer sweet murder tool" "yeaa not really the goal"
evanjs has quit [Read error: Connection reset by peer]