wmanley

I could see how customising the compressor could be helpful - a bit like how there's an `--rsyncable` option to `gzip`, but I'd like to keep compatibility with existing formats. I like to avoid coming up with new formats whenever possible because you might want to mine the data in 20 years time - and if it's a custom format it'll be much harder to deal with.

I don't have a current use-case for this, but I like thinking about it. In particular I like data stores to be as simple as possible. Managing persistent state is the hard bit of most systems as unlike with runtime state or code you have to manage forwards and backwards compatibility, migrations, etc. and you can't just "turn it off and on again" to fix issues.

It would look something like this:

    CREATE TABLE t1(
        json TEXT,
        data INT GENERATED ALWAYS AS (json_extract(body, '$.d')) STORED
    );

You can read more about this kind of technique here: https://dgl.cx/2020/06/sqlite-json-support

[1]: https://www.sqlite.org/gencol.html

I also like how simple and powerful the custom partitioning is.

[1]: https://www.sqlite.org/gencol.html

[1]: https://github.com/stb-tester/apt2ostree#lockfiles

Maybe I'm bitter, but I used to really enjoy r/rust up until 2 years ago or so. Now it's completely inane and it's no longer worth the time to sort through the noise to find the signal.

> 3. The sqldiff utility is not designed to support schema migrations and is forgiving with respect to differing column definitions. Normally, only the column names and their order are compared for like-named tables before content comparison proceeds. > > However, the single-table comparison option, with "sqlite_schema" named, can be used to show or detect detailed schema differences between a pair of databases. When doing this, the output should not be used directly to modify a database.

One nice thing about this approach is that because it works by inspecting a database that has been put in a desired state. This means it doesn't matter how you set up your database (with an ORM, a SQL file, etc.) the same function can be used to do the migration.

I'd really like if something like this were built into SQLite. That way we'd have more confidence that it would be/stay correct and complete. It seems generic enough that it could be a part of built-in functionality. I would have proposed it upstream, but AIUI the SQLite authors don't accept external patches.

Edit: Another benefit of this being built-in: there are plenty of places where SQLite is applicable where you can't, or don't want to run Python.

> My preferred approach to database migrations is the one implemented by Django: migrations are a sequence of transformations stored in files on disk, and the database includes a table that says which of those migrations have been applied. This keeps everything in version control and means there's no chance of the wrong migration being applied in the wrong way.

Do the transformations have to be applied in sequence? If so how does this handle resolving git conflicts? With our system mostly conflicts in our database.sql script are resolved automatically with git merging. And CI works well because we downgrade the database to the version of database.sql found in $(git merge-base main HEAD) before running integration tests.

No, but the keyboard manufacturer might be, as might the people who are writing and optimising compilers targetting that CPU.

Everything being an extension (and thus removable) is a strength in some specific circumstances, but is a weakness in most.

One alternative would be to provide escaping more directly like this:

    curl --json '{
      "map": %s,
      "prime": [
        %i,
        %i
      ],
      "target": {
        "x": %i,
        "y": %i
      }
    }' "$continent" "$p1" "$p2" "$x" "$y" https://example.com

1. What's on the command line resembles what's actually going to be sent.

2. Curl doesn't actually need to parse (nor validate) the JSON, or to create a tree representation of the data within itself. %s is invalid JSON anyway, so you can do a string substitution - all you need to keep track of are matching quotes (including escape sequences).

I've used a printf style format string here, which could be expanded for extra convenience. For example the Python-style `%(env_var)s` sequences could be used which could expand environment variables directly. Or something could be added for convenient handling of bash arrays.

Dependencies in make are equivalent to systemd's Requires= and After= combined. Systemd is far more general in this regard, both in that Requires= and After= are separate concepts, but also in that there is Wants=, BindsTo=, etc. and their inverses (RequiredBy=, Before=, etc.). Sometimes when I'm writing Makefiles I wish Make were capable of expressing some of these concepts.

I've been seeing comparisons to Ponzi schemes a lot in the last few weeks. AFAICS "Bitcoin as Ponzi scheme" is a useful strawman for pro-bitcoin arguments because it's so easily defeated. Bitcoin as Pyramid scheme is a much stronger argument, with far fewer articles dedicated to it.

Yes, there are a very specific and limited set of changes you could make to the types here and not have to change this code. You can't replace `Result<>` with `Option<>` because of `map_err`. You could replace `Result<>` with something else that is very `Result<>`y, but your flexibility would be very limited if you didn't want to change the signatures of `with_some_error_handling_that_can_rescue` or `some_error_processing`.

I'm sure it's possible to contrive an example where this would help, but I don't believe that it would be that much of a help very often in practice. I think it's just a bit more monady and people who take the time to learn monads then want to apply that wherever they can.

I'm not saying that the combinators should never be used, but that each additional one you use increases the cognitive burden of reading your code. So the question becomes: which of the combinators are worth it.

I would argue that `.map_err()` is useful as it compliments the `?` operator. Hopefully with (and often without) `try!` blocks many of the other ones can go away. In particular I think that language constructs are almost always better than `.and_then()`.

    let x = match may_fail_who_knows() {
        Ok(y) => Ok(another_computation_which_can_fail(use_value(x))),
        Err(e) => with_some_error_handling_that_can_rescue(
            some_error_processing(e)),
    };
    match x {
        Ok(y) => y,
        _ => a_default_value,
    }

Also: by avoiding functors there are fewer subtle lifetime issues and `move ||` stuff to deal with and you can return from the containing function and use the `?` operator.

During the discussions of how `.await` was going to work for rust async there was the proposal to add other suffix keywords. So this would look like:

    may_fail_who_knows()
    .match {
        Ok(y) => Ok(another_computation_which_can_fail(use_value(x))),
        Err(e) => with_some_error_handling_that_can_rescue(
            some_error_processing(e)),
    }
    .match {
        Ok(y) => y,
        _ => a_default_value,
    }

SQLite has "Indexes On Expressions"[1] since 2015. I'm assuming functional indexing in Postgres is the same. So I think the syntax would be:

    CREATE INDEX idx_t_bar ON json_extract(data, '$.bar');

> Also PostgreSQL has many operators[2] which makes using JSON fields easier.

This does look a little more convenient to write than SQLite's JSON syntax, but I don't see any fundamental difference here.

    SELECT id, json_extract(data, '$.foo')
    FROM   t
    WHERE  json_extract(data, '$.bar') > 5

     f(arg1, arg2, _ {name: "Hello", address, ...})

     f(arg1, arg2, MyKwargs {name: "Hello", address, ..Default::default()}

I wrote apt2ostree. It applies the cargo/npm lockfile idea to debian rootfs images. From a list of packages we perform dependency resolution and generate a "lockfile" that contains the complete list of all packages, their versions and their SHAs. You can commit this lockfile to git.

You can then install Debian or Ubuntu into a chroot just based on this lockfile and end up with a functionally reproducible result. It won't be completely byte identical as your SSH keys, machine-id, etc. will be different between installations, but you'll always end up with the same packages and package versions installed for a given lockfile.

This has saved us on a few occasions where an apt upgrade had broken the workflow of some of our customers. We could see exactly which package versions changed in git history and roll-back the problematic package before working on fixing it properly. This is vastly better than the traditional `RUN apt-get install -y blah blah` you see in `Dockerfile`s. You know exactly what was installed before an update and exactly what is installed after and you can rebuild old versions.

IMO it's also more convenient than debootstrap as you don't need to worry about gpg keys, etc. when building the image. Dependency resolution and gpg key stuff is done at lockfile generation time, so the installation process can be much simpler. In theory it could be made such that only dpkg is required to do the install, rather than the whole of apt, but that's by-the-by.

apt2ostree itself is probably not interesting to most people as it depends on ostree and ninja but I think the lockfile concept as applied to debian repos could be of much broader interest. The lockfile generation could be easily separated from apt2ostree. Most of it is implemented in a custom fork of aptly anyway. Actually applying the lockfiles and creating a rootfs from it is much more apt2ostree specific and would probably need to be reimplemented separately to be more generally useful. Ideally that would be built in to dpkg, but I don't think I'm the man to drive that consensus.

[1]: https://news.ycombinator.com/item?id=28837690

[2]: https://ostreedev.github.io/ostree/

You can then install Debian or Ubuntu into a chroot just based on this lockfile and end up with a functionally reproducible result. It won't be completely byte identical as your SSH keys, machine-id, etc. will be different between installations, but you'll always end up with the same packages and package versions installed for a given lockfile.

This has saved us on a few occasions where an apt upgrade had broken the workflow of some of our customers. We could see exactly which package versions changed in git history and roll-back the problematic package before working on fixing it properly. This is vastly better than the traditional `RUN apt-get install -y blah blah` you see in `Dockerfile`s. You know exactly what was installed before an update and exactly what is installed after and you can rebuild old versions.

IMO it's also more convenient than debootstrap as you don't need to worry about gpg keys, etc. when building the image. Dependency resolution and gpg key stuff is done at lockfile generation time, so the installation process can be much simpler. In theory it could be made such that only dpkg is required to do the install, rather than the whole of apt, but that's by-the-by.

apt2ostree itself is probably not interesting to most people as it depends on ostree and ninja but I think the lockfile concept as applied to debian repos could be of much broader interest.

[1]: https://github.com/stb-tester/apt2ostree#lockfiles

[2]: https://ostreedev.github.io/ostree/

> So while your customers and employees are going to be mad, they’re also going to be distracted from worrying about your downtime.

This is incredibly important for business. If we go with AWS and it goes down, then it's big news and our customers blame AWS. If we choose a different provider, even one which is more reliable than AWS, then our customers blame us.

This reasoning obviously doesn't apply to all systems e.g. air-traffic control or stock exchanges, but it does for the vast majority of businesses, and certainly any business that would host their systems in the cloud in the first place.

    $ python2 -c 'False = None = True'
      File "<string>", line 1
    SyntaxError: cannot assign to None

    $ python3 -c 'False = None = True'
      File "<string>", line 1
    SyntaxError: cannot assign to False

IMO the real value in trailing commas is that it's easier to produce simple JSON programmatically.