The license choice is explained with the following:
> [...] we accommodate the business need for proprietary kernel modules. Unlike GPL, the MPL permits the linking of MPL-covered files with proprietary code.
Glancing at the readme, it also looks like they are treating it as a big feature:
> Asterinas surpasses Linux in terms of developer friendliness. It empowers kernel developers to [...] choose between releasing their kernel modules as open source or keeping them proprietary, thanks to the flexibility offered by MPL.
Can't wait to glue some proprietary blobs to this new, secure rust kernel /s
I'm curious about the practical aspect: Are they going to freeze a stable driver ABI, or are they going to break proprietary drivers from time to time?
Considering their OS as a framework approach I would guess they are more likely to expose a stable API than a stable ABI. Which also plays well with the MPL license (source file based) rather than something like the LGPL (~linking based).
Open source usually means that you are able to modify and redistribute the software in question freely. However between open and closed, there is another class - source-available software. From its wikipedia page:
> Any software is source-available in the broad sense as long its source code is distributed along with it, even if the user has no legal rights to use, share, modify or even compile it.
Built-in fetching of http resources and reading files from the filesystem[1] combined with turing-completeness are features that I wasn't expecting from a configuration language. I wonder if the complexity this brings is justified.
For me, that's where all the power of the language comes from. It's like writing your config in Go or Python (which I think is also a great approach) except its designed from the ground up for this use case of config generation.
Ah just give me typescript, I do not need to learn a new thing for configuration languages and at the end of the day the output is compatible with JSON. Typescript has all the stuff I would want: types, first class json support, an ecosystem of libraries (if you want it, I would probably not for config generation). And the tooling is amazing. Does pkl have LSP, syntax highlighting in every editor, debugger or repl?
Agreed. If we're getting the point where you're saying "it's like writing your configuration in [insert Domain Specific Language Here]" then I'd prefer to simply use that language. I understand the point Pkl is making in that "configuration won't work across DSLs so here's one language for all of them" but I don't know that that's enough motivation for people to adopt it.
However, I haven't built anything cool like this so what do I know. I'm just procrastinating on the my personal project and browsing hacker news.
At one time I just gave up on using any config formats and instead went back to the good old simple "use the programming language as the config file too" approach.
It's certainly not cross language capable but when your editor knows exactly what's there and what's not with auto completion from the config file, that was a superior experience than caring about cross language issues that may not even be a problem depending on the project.
If you must, you can easily make an identical copy of the config in the build process to convert it to another language.
A big problem we've hit with allowing users to write Typescript (or any other general-purpose programming language) for our product is that it's too powerful.
Observationally, it seems that all that power eventually gets used, and then you end up with config that has complex interfaces, or becomes non-portable because it's doing arbitrary file reads, or is non-deterministic because of an ill-advised call to random or the system clock. The config then becomes something not maintainable by the rest of the team - just the few who know it.
Config languages seem to need to strike an interesting balance between being complex enough to allow for reasonable DRY code (which helps maintainability at the expense of readability), but not so complex that they're not generally-maintainable.
Yep, application code can have the same problem! The difference is that application code lives "inside the abstraction" of the program, and is viewed and edited by a much smaller set of developers.
Configuration, by contrast, sits at the seam between two systems. It's the top-level parameterization of the abstraction, and behaves more like an API. E.g. imagine if the only way to configure Kubernetes or Docker were in language-specitic bindings - there was no such thing as a YAML lingua franca.
Typescript does have const variables. But you can still often mutate the instances and there are many other reasons why a configuration language should be strictly free from side effects allowed in imperative languages.
> Ah just give me typescript, I do not need to learn a new thing for configuration languages
People who don't know Typescript will still have to learn a new thing in that case, so there isn't really any reason to pick TS over any other existing language
> syntax highlighting in every editor
There is a tree-sitter parser for pkl, so it'll work anywhere where tree-sitter works. And for VSCode and JetBrains stuff, they have official extensions.
But I have no idea how I would build a config structure for an application using Nix... It seems very powerful so I'm sure it's possible, but I just have no idea where I'd start for this specific use case.
Whereas this documentation for Pkl is entirely about that use case.
I agree that there's a huge documentation and user awareness gap, but NixOS is obviously possible to configure this way so it's definitely possible.
Might be room for a tool that exposes just the configuration management side of Nix in a more approachable way... on the other hand it would be a bit silly to use nix for conf files and not also for the underlying packages.
I guess it strikes me as not just a documentation and awareness gap, but a different paradigm in a more fundamental way.
I think your last sentence gets at that too: For Nix, configuration management is just one component of a broader and more powerful paradigm. And it seems to me like putting a square peg in a round hole (or as you say, a bit silly) to try to use it to solve this narrower and simpler problem.
Better to learn a tiny corner of nix (which you may later apply to the rest of it, or not) than to learn a language with a narrower use case.
But one who embraces nix fully is one who is willing to commit a lot of time to turning their back on convention. Returning to 90% of the conventions that they worked so hard to leave behind probably won't excite them.
So it's not silly, it's just that the person to do it is culturally unlikely.
> Better to learn a tiny corner of nix (which you may later apply to the rest of it, or not) than to learn a language with a narrower use case.
"Better" in what way?
Like, maybe I agree in some sort of philosophical sense, of how it's better to learn and expand one's awareness of what exists and is possible in the world. That is, better for students, similarly to how I'd say it is better for students to learn lisp and haskell, because they'll figure out how to use javascript and python and C# or whatever as needed on the job. And I'm a believer in life-long learning, that everyone should do their damndest to carve out time to be a student at all times throughout life. So certainly I'm in favor of learning about Nix and its config structure and comparing and contrasting it to other things like this Pkl.
But I don't think the idea of using Nix's config management instead of a narrowly-targeted config management tool would be "better" in the sense of a professional figuring out how to set up or refactor the config structure within the non-Nix paradigm of the vast majority of organizations. And that's what I've been talking about here.
I'm actually a Nix kool-aid drinker, believe it or not, and I hope its paradigm will sweep the world, but I also have to do what's right by the organizations I work within at each moment in time, and being at the vanguard of the Nix paradigm has not been that, in my view, yet.
> a professional figuring out how to set up or refactor the config structure within the non-Nix paradigm of the vast majority of organizations
Then I don't think nix-as-config-only is a good move. But if you're a professional figuring out how to set up or refactor the config structure of some organization, AND for some reason you've already decided that you're going to introduce a language that nobody in the organization uses, then would I say that nix is a good choice. This is because there are probably other people in that organization that would find nix useful if they were already over the syntax adjustment phase.
If a multitool's screwdriver is just as good as a normal screwdriver (granted they're usually not), why not prefer the multitool?
Generally I'd just suggest using whatever languages are already around, config-focused or otherwise. For instance we have a lot of python in our stack so I've found a library called mergedict that gets us close enough to the composability of nix modules without adding a new language.
> Then I don't think nix-as-config-only is a good move.
Yep, that was the only narrow point I was trying to make initially :)
> If a multitool's screwdriver is just as good as a normal screwdriver (granted they're usually not), why not prefer the multitool?
Under the assumption that the multitool's screwdriver is just as good, then yeah, that might make sense. But as you grant, that is usually not the case. And my original point is that this is one of those usual cases where it is not as good, not one of those rare cases where it is just as good. And the reason Nix is not just as good for this, is that it was not made for this, it was made for something different and bigger.
> For instance we have a lot of python in our stack so I've found a library called mergedict that gets us close enough to the composability of nix modules without adding a new language.
Things like mergedict, while being a common genre of solution to this problem, are not a good solution to it. They are the total mess I said I'm always keeping an eye out for better alternatives to.
I don't know yet if I think Pkl (or Cue or any of the rest) actually fit that bill, but your contention that there is no point looking for solutions to this problem short of Nix strikes me as a classic case of making perfect the enemy of good.
> [...] we accommodate the business need for proprietary kernel modules. Unlike GPL, the MPL permits the linking of MPL-covered files with proprietary code.
Glancing at the readme, it also looks like they are treating it as a big feature:
> Asterinas surpasses Linux in terms of developer friendliness. It empowers kernel developers to [...] choose between releasing their kernel modules as open source or keeping them proprietary, thanks to the flexibility offered by MPL.
Can't wait to glue some proprietary blobs to this new, secure rust kernel /s