turboponyy

Emacs is whatever you want it to be, and it has wonderful modal editing packages such as evil-mode[1] - which surpasses the editing system from vi that it is based on - and Meow[2]

1. https://github.com/emacs-evil/evil

2. https://github.com/meow-edit/meow

The best graphical, modal text editor is Emacs.

> By the way, is there a way to create minimal NixOS VMs without systemd?

No, systemd is a hard dependency for NixOS.

> They’re advocating deploying a binary as preferable to using docker, fair enough, but what about the host running the binary? One of the reasons for using containers is to wrap your security hardening into your deployment so that anytime you do need to scale out you have confidence your security settings are identical across nodes.

There are tools that make "bare metal" configuration reproducible (to varying degrees), e.g. NixOS, Ansible, building Amazon AMI images.

> Rust-style returned tuples of {:ok, val} or {:error, e}.

Tuples fall under product types. Rust's APIs return errors as sum types. A more apt comparison would be with Go, where errors are actually returned in tuples.

Edit: nevermind, I see what the author meant now!

Could you give examples? There is a lot of hard work and magic going on in the build system, but you're not really supposed to interact with it as a user. As long as you pull in nixpkgs' library, package definitions are as trivial as they can get.

Completely opposite experience for me. I think Nixlang is exceptionally well designed and makes sense for the usecases it wants to cover, and it is exactly what I would expect from a DSL tackling the problems it tackles.

The stuff Nix lets you declare really are very arbitrary. I even specify my Firefox extensions in my home-manager config.

The backslash is unsightly, I agree. Codifying template expression evaluators as a core part of the language, however, is a rational choice. Java is surprisingly foresightful in this regard - it means idioms in the language itself can guide people to getting the common use case of interpolating stuff correct. "STR" for the most prevalent case is perhaps a bit verbose, but at least it's explicit.

Not really in the programming mainstream, but in research-oriented languages with dependent typing like Lean or Idris, constraining your "implementation search space" with types and leveraging the type system to prove properties about your program is commonplace.

In Haskell and other pure functional programming languages, monads are used to model arbitrary contexts. For example, in Haskell, there is a package which provides the Tardis monad which provides a time traveling context[1]. It can be used to solve some classes of algorithmic problems quite elegantly[2].

1. https://hackage.haskell.org/package/tardis-0.4.4.0/docs/Cont...

2. https://rosettacode.org/wiki/Water_collected_between_towers?... (see the "see also" section for a Tardis implementation)

From elsewhere in this thread:

> Also worth checking out for more general use of LLMs in emacs: https://github.com/karthink/gptel

If you're reinventing a language, it's probably not a bad idea to reinvent the simplest one!

I've stumbled on the ontological argument without knowing that it's called that myself - not as an argument for god, but for multiple universes. Namely, one can conceive a universe so powerful that one of its properties is that it must necessarily exist, even if it doesn't yet and even if there is currently only one universe - a universe so powerful that it is capable of breaking the isolation inherent of a multiverse and will itself into existence.

I suppose you could argue for anything with this reasoning.

I'm very surprised you haven't heard of org mode - your product is essentially a reimplementation.

> Where do you push the changes? You make a fork on GitHub. Go to magit, press a couple of keys to add a remote, name it the same as your GitHub username, magit automatically sets the URL correctly.

Or, just use the magit-forge package by the same author and run `forge-fork`.

Less people outside -> less scoots

I think we've mostly agreed on editorconfig[1], though it doesn't concern itself with language-specific formatting - it's even built into a lot of editors.

For language-specific formatting, you can run formatters in pre-commit-hooks and CI. Treefmt[2] can help with that if you want to cover a lot of languages in your repo.

1. https://editorconfig.org/

2. https://github.com/numtide/treefmt

What's described in the title of the article is old news. What might be novel, however, is the application of detecting typing on laptop keyboards. This type of detection was previously only reliable for mechanical keyboards.

> "I don't really listen to music" == "I don't breathe much".

Could you elaborate?

I definitely used to be a person who just didn't listen to music - I found it quite boring, really. I've since found genres that I like that I listen to on occasion, but definitely still not as frequently as the average person.

My ideal world would have no timezones and be entirely Anglophone (English is not my first language, so I'm not even biased in that regard). This is probably an extremely controversial take, considering how much interesting culture and history would be wiped out, but the thought makes me feel warm and fuzzy inside.

Darwin is one of the supported architectures, yes, though it is a bit of a second class citizen in the Nix ecosystem when compared to x86_64-linux.

I think you got the wrong guy!

Yeah, all of these can be essentially boiled down to "use Maybe String, where String supports Unicode". Amusing, nonetheless!

As a somewhat avid user of Nix, I can say that this is by far the best piece of writing that serves as an introduction to Nix that I've read. It leaves nothing unsaid, whilst serving as a perfectly crystallized version of what I'd want to describe if someone asked me what Nix is.

No, it is not. It has no plans to introduce type classes and allows for impure (effectful) functions. It is perhaps most similar to OCaml.

This isn't really specific to Rust's type system, though. It's more related to the philosophy of the language and how the standard library is implemented. You could have the same behaviour in most other traditional programming languages.

Though, Rust's type system and syntactical features probably lend themselves to more ergonomic handling of the various error states.

It seems that every language, given enough time, wants to tend towards Haskell!

I don't get it - Is this an LSP, or specific to SCode? If it is an LSP, it would be nice if the project advertised this in the README.

You should use asserts or throw errors to prevent misuse of a procedure by the caller. Ideally, you could model these constraints at the type level. You can think of pre-conditions as a sort of pseudo-dependent typing.

Consider the following pseudocode:

    // Idris
    binarySearch : SortedList a -> a -> Maybe Nat
    binarySearch = ?implementation

    // Java
    int binarySearch(List<T> elems, T elem) {
        assert isSorted(elems);
        throw new NotImplemented();
    }

(The generic type parameter should also implement Comparable or similar, but I digress).

In this case, it would be nonsensical to pass an unsorted list to either procedure, so we prevent it - in Idris' case by using dependent typing; in Java's case by using assertions.

To contrast, consider the following:

    // Idris
    readLines : Path -> IO (Either FileError (List String))
    readLines = ?implementation

Here, the FileError represents a number of things that could go wrong: no file existing at the given path, lack of permissions, running out of memory during read and so on. However, this is not misuse of the procedure - these are all expected deviations from the happy path, and hence we model that in the type definition.

(I've omitted a corresponding Java example, as following a similar style would be terribly non-idiomatic. Java prefers throwing and catching exceptions to manage non-happy paths)

Note that we can't constrain the Path parameter to only resolve to files that exist. Doing so would require knowledge of the current filesystem state, e.g. the type signature would be something like the following:

    readLines : (fs : FileSystem) -> (p : Path) -> fileExists fs p -> IO (Either FileError (List String))
    readLines = ?implementation

To summarize, use preconditions, assertions or type-level constraints to prevent misuse of procedures. Return errors (using sum types, for example) when it is known and expected that the result of a procedure can deviate from the happy path. You may refrain from modeling conditions at the type level, even if possible in principle, as it may be prohibitively complex.