rosshemsley

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 :)

Pytorch is a good option here - ultimately it's just a library for efficiently manipulating tensors and supports cuda GPUs.

"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...

Could this actually be a profitable business, selling carbon offsets?

Perhaps an easier (and more robust) way to do this is as follows:

1) Take your points in 3D, and add the point at the origin

2) Compute Delaunay in 3D

3) The 2D faces not containing the origin is your triangulation.

To get the Voronoi tessellation:

1) Circulate the faces of each vertex in order (use orientation test if they are not ordered yet)

2) Connect the circumcenters of each 2D face you visit.

Voilà!

I was seduced by BlueOcean and tried using Jenkins for CI, using Github and AWS ECS builders (which felt like a common enough use-case).

Unfortunately it ended up costing an astonishing amount of engineering time to get working and maintain, with builds frequently stalled or failing.

Since moving to CircleCI 2.0 enterprise (admittedly far from perfect) and Airflow, we have _dramatically_ reduced eng. time spent managing our job scheduling.

The core of our problem was how fragile and complex the Jenkins ecosystem seems to be: any change to the config or settings and it would easily burn a day of engineering, due to random bugs and hard to understand error messages. In the end, no one wanted to touch it!

I think there's a great project hidden somewhere here, but just getting the basic "everyday" stuff done with it can be a real PITA.

Go excels at:

- Anything that talks to a network (webservers, load balancers, caches - due to the fantastic built-in support for everything you eed, and concurrency primitives)

- CLIs (static linking and cross compiling make distributing binary CLIs a piece of cake)

- Gluing stuff together (it talks C, and all your favourite libraries are probably already available (gRPC, protobuf... etc)

- Munging data (expect orders of magnitude speedups over Python)

Go is bad at:

- GUIs

Why consider Go over other things?

- For me, Go is "the language with the least BS" there is. The "let's just get some engineers writing some code and ship it" story is literally miles ahead of Python/C++/Java/X language. It has been painstakingly crafted to minimise friction onboarding, building, testing, upgrading, and deploying.