turboponyy

Yes. GitHub actions can be just a thin wrapper to call any Nix commands that you can run locally.

> How do you automate running tests

You just build the Nix derivation that runs your tests, e.g. `nix build #tests` or `nix flake check` in your workflow file.

> deploying to dev on every push

You can set up a Nix `devShell` as a staging area for any operations you'd need to perform for a deployment. You can use the same devShell both locally and in CI. You'd have to inject any required secrets into the Action environment in your repository settings, still. It doesn't matter what your staging environment is comprised of, Nix can handle it.

nix develop

You shouldn't pass invalid values to a function. If a function can return some sensible value for some input, then the input is not invalid - even if the return type is an error by name.

Ideally, you can constrain the set of inputs to only valid ones by leveraging types. But if that's not possible and a truly invalid input is passed, then you should panic. At least that's the mental model that Rust is going with.

You do lose out on the ability to "catch" programming errors in subcomponents of your program. For example, it's extremely useful to catch exceptions related to programming errors for called code in response to a web request, and return a 500 in those cases. One could imagine a "try" "catch" for panics.

The thing is, it takes a lot of discipline by authors to not riddle their code with panics/exceptions when the language provides a try/catch mechanism (see C# and Java), even when a sensible error as value could be returned. So Rust opts to not introduce the footgun and extra complexity, at the expense of ungraceful handling of programming errors.

Containerizing an application is far easier than packaging an application for Nix - I think most avid Nix users would agree with that.

The reason why Nix users "refuse" to containerize is that Nix packages and their associated ecosystem come with a host of benefits that their containerized counterparts do not.

There's always the escape hatch of marking a derivation as impure.

However, most tests should really have no reason to be impure by design. And tests that do depend on side effects might as well be re-evaluated every time.

Nix solves this as a byproduct (as it does with many things) of its design. You can have your tests be a "build", where the build succeeds if your tests pass. Any builds can be cached, which means you're essentially caching tests you've already run. Since Nix is deterministic, you never have to rerun any tests until anything about them that could change the evaluation changes.

That summary is nearly identical to the abstract of the paper...

The thing is, Nix is not Yet Another Tool, it is the tool.

Except the completion of the preparation of various nodes may have to be synchronized to that of other nodes - i.e. the steps can not be parallelized in the general case. Some nodes expire, experience changes in temperature or moisture distribution and so on. In that sense, there is additional context that your model doesn't account for that may preclude certain nodes from being combined.

Um, my session with GitHub never expires - weird.

This is literally just a skill issue

This is inherently a Hard Problem™, since completions may require evaluating arbitrary derivations (e.g. building a custom Linux kernel).

For "what symbols are available", the nil LSP implementation[1] works for anything in scope that doesn't require evaluation. It also includes completions for the stdlib and NixOS options (in certain contexts).

Another LSP implementation is nixd[2], which is trying to tackle the problem of evaluations for completion.

[1] https://github.com/oxalica/nil/

[2] https://github.com/nix-community/nixd

What's so bad about it?

Putting aside the poor typing (the lack of proper typing is a shame, so valid criticism), I actually really like the language - it's genuinely a great DSL for the particular problems it's supposed to handle.

It does take a bit of use for it to click, though. A lot of it has to do not with Nixlang itself but about learning nixpkgs' idioms.

Somewhat related: https://github.com/nix-community/NixOS-WSL

I love how the rules imply that not providing these proofs and applying them is against the rules.

Not to be dismissive, but because I like it - it just sits right with me.

Neither have I; and no, I don't - I misinterpreted what you said.

But I don't see why LSP servers shouldn't support this, still. I'm not sure if the LSP specification allows for this as of current, though.

I like them because it reinforces the idea that functions are just values like any other - having a separate keyword feels like it is inconsistent.

There's no reason they have to work one symbol at a time - that's just a missing feature in your language server implementation.

Some language servers support modifying the symbols in contexts like docstrings as well.

Magit is possibly one of the best pieces of software ever written. Its discoverable and intuitive interface makes complex operations trivial and trivial operations blazingly fast and frictionless. The interface you use does matter. Magit greatly reduces the overhead for most Git operations, and, as such, has undoubtedly made me a more proficient Git user by making it easier to materialize my thoughts, experiment, and feel confident performing operations I otherwise would second guess - to a degree that I doubt other interfaces could replicate. Magit holds your hand, whilst not abstracting away Git's internals. It can not be praised enough.

More notably, then you'd have to use Ansible.

Minecraft was immensely popular before you could starve, but I agree.

I empathize with this point of view - if not in any other way then in principle.

However, as a counterpoint, I'd suggest that encoding all known invariants as types may be prohibitively cumbersome and time-consuming - to the point where writing the program becomes more of an exercise in proofs rather than producing something useful. Often the invariants of a program are implied or can be easily inferred by the reader, which can actually make the program easier to understand for both the reader and the writer by leaving some things unsaid.

Of course, whether a program is easier to understand when its invariants are written down vs. when they are left to be inferred by the reader is probably a matter of circumstance, so different tools for different jobs and all that.

I've recently been writing a small program in Go - my first foray into the language - and I thoroughly enjoy how it gets out of my way. The lack of rigor is freeing if you don't stop to think about it too much.

As with anything Haskell, one could simply reply with "here's the formal definition."

But in easily digestible terms, it's a way to narrow your view over a collection to a subset that satisfies some property, and perhaps perform some operations on that subset.

This video presentation (with a very humorous audience dynamic, might I add) serves as a great introduction by example: https://youtube.com/watch?v=QZy4Yml3LTY

Agreed. For PR commits, appending the PR number (e.g. `#8`) to the short message is fine, but the short message should still contain a summary of changes. For issues, having something like "Fixed #8" in the commit message body is picked up by forges like GitHub.

You realize that commits can be changed, right?

Nix is completely orthogonal to whatever tech you use to build the resume - it's nice as a build tool + to provide dev environments for however you're going to realize your resume.

Direnv and Nix are related in the sense that direnv has a `use flake` command that you can put in your .envrc to load the devShell defined in the project's flake.nix file. It's essentially just an automatic entry to the project's Nix-native devShells.

Edit: this is the only thing I use direnv for - I haven't used direnv without touching Nix.

On the other hand, it's only an order of magnitude faster

Why not integrate a Lua LSP instead of reimplementing all that language support?