janslow

I try to use Make to bootstrap project-specific tooling when missing, by getting it to download (then verify) the tools, then delegate everything else to something like knit (or just/cargo/npm).

That way, there's very few prerequisites for a new dev to install (plus you have consistent build/test/run targets for all projects).

If someone wants to manage tools themselves (e.g, the no prebuilt binaries example), they can do that, then skip the Makefile entirely.

Agreed. I wasn't originally a fan of Go's error handling, but I do find it forces me to explicitly handle the error, I very rarely use a plain `return err` statement, instead wrapping it with additional parameters.

Whereas when I use Rust's Result types, I tend to not add any additional context with `map_err` (until I need to investigate the cause of an error and have to retrofit it).

There's still definite room for improvement though (I think the Go 2 proposal will help a lot).

This is unacceptable, in my opinion.

Most of the properties I've rented in the UK have only have only had an inspection at the end, although one has had a mid-tenancy inspection, where they took photos of the (previously) damaged part only.

Personally, I'd start off by raising a Subject Access Request under GDPR (it's part of British law, not just EU) as well, as well as asking how they asking how they process and store the data.

If they're using the data incorrectly (e.g, if they claim to collect data to check for damage, but there is no damage), you could make a complaint to the ICO.

If you're not familiar with your rights under GDPR, I'd recommend reading the UK Information Commissioner's Office guide for this (https://ico.org.uk/your-data-matters/your-right-to-get-copie...).

In most cases, a breaking tooling change should only impact the root project (e.g., they need to change their readme from `go get` to `go install`), so there's only one codebase to fix and it's in the control of the person upgrading the tooling.

Whereas, a breaking language change could impact transitive dependencies of the root project, which a developer doesn't have control over.

The lack of support for context.Context rules out this project for me.

All our cross-cutting concerns (tracing/monitoring, auth, timeouts) are built on top of the context pattern (and it works great compared to other languages).

Something like Execute(context.Context, req *Request) could be a simple solution to this.

One of the issues is that it's tied quite heavily to the Java compiler, so you may need to wait until Lombok supports a new Java version before you can use it.

Also as it is compiler magic, it can be a bit confusing to developers who haven't used it before.

Whilst Swagger Codegen doesn't create perfect libraries and some of the generators don't support all the features, once it's set up, it's just as easy to create a client for every language as it is for just one.

For example, we create multiple client libraries, HTML documentation and a partial server (so we don't have to manually write the parameter parsing and models serializers).

Another advantage is you can start consuming the API as soon as the API design is agreed, by using a generated mock server instead of waiting for the real one to be implemented.