GitHub pages:

You can use custom domains with SSL

Here's a full example:

https://github.com/rosshemsley/rosshemsley.co.uk

Whilst I don't totally disagree with many of the points here, I think there's a wider picture to many of these issues.

The author is concerned with installing packages on user machines: which are typically very long-lived installs - maybe a user has the same machine with the same dependencies for years.

However, for many engineers, (such as myself), a binary may not be used past even a few days from when it was first compiled - e.g. as part of a service in a a quickly continuously integrated system.

I might even argue that _most_ software is used in this way.

When software is built this way, many of the points in this article are very helpful to keep builds stable and to make deployment fast - and in fact for the case of security, we usually _don't_ want dependencies to auto-update, as we do not want to automatically deploy new code if it has not been audited.

Maybe there's a future were OSs become more like this, where binaries are more short lived... maybe not. Although I don't think it's strictly fair to label all of these as "Bad" with a capital B :)

Protip:

On OS X you can set it so no icons appear on your Desktop.

For me at least, having that "new laptop" clean slate at all times helps me maintain focus :)

"if you need a tool, buy the cheapest one you can find. If it’s inadequate, or breaks, or you use it a lot, then buy the best one you can afford"

I don't know how I feel about this... The unsaid thing here is that you will end up landfilling the broken or inadequate tool and buy twice what you need.

These days, if I'm going to put money into buying material goods, I feel they have to meet at least a minimal "this isn't going to end up in landfill after the first time I use it" bar.

A lot of cheap tools barely meet this level, sadly...

I think a common conflation is seeing "making something future proof" as "making it more generic".

IMO, good future-proof design is about putting in place good components and system boundaries.

Those components and boundaries can be highly specialised and have as few options as possible - it's much easier to make a system boundary more complex than to make it simpler. So start as simple as possible!

Now, with those boundaries, you can easily write tests, and iterate on the different parts of the system. Bad code in one component doesn't "infect" bad code in another part of the system.

Most "balls of mess" systems that I have seen came down to not having clear boundaries between components of the system, rather than being too generic or not generic enough.

A litmus test I'm excited about is writing a less clunky linear algebra / numerical optimisation package.

Gonum is good, but it can feel like a lot of the powerful abstractions in numpy and Eigen are difficult to replicate.

Whilst numpy and Eigen do "turn the magic up to 11" just a bit too much for my liking, I do like the idea of things like this:

    interface Scalar() {
        type float float32 int int32 int64
    }

    type DenseMatrix(type T Scalar) [][]T

    func Identity(type T Scalar)(int size) DenseMatrix(T)

etc.

Features I wish C++20 had:

* An opinionated, modern packaging and dependency story (like go modules, Rust crates)

* built-in library support for logging, http, zip, gzip, json, yaml, template rendering, RFC3339 datetime reading/writing

* the dream: compliant compilers must be able to compile down to static binaries, cross compiling built-in.

Features C++20 actually has:

* new fancy spaceship operator that I'll now have to learn and never use...