At that point I think it's pretty competitive with "go get". In both cases users have to install one thing, then use it to get your thing.
Haven't seen an internal rust tool yet.
> Users who can’t do that shouldn’t be using CLI
Users who can do that will still find it an odd departure from convention.
It'll never be as clean as a static binary build, but it saves us from having to build out two language ecosystems when the rest of the company uses Python for everything.
Python is awful for this stuff
It's never fun. It's never pleasant. But to be fair, if I have a CLI tool that needs a deployed SSH client, or Tensorflow, or SDL or Qt or something else, I'm not convinced packaging gets much easier no matter what language we're talking about. If your use case is simple, Python is easy enough to deploy, and Go is even easier. If you can't disable CGO or need a third party component, I imagine the fun is just getting started anyway.
As a counterpoint, awhile back, discovered that Golang had a minimum kernel version requirement. That pretty much eliminated it as a possibility for writing tools for legacy systems. Python was viable though, Bash moreso. :) Couldn't tell you if that was still a requirement for Go today.
This seems an infrastructure extension of treating compile warnings as errors.
Agree with you strongly. Also by committing to a database you can take advantage of things it does for you rather than trying to stay "generic" and portable. Pick a database (I like Postgres), and then wring everything you can out of it.
> Don't migrate an application from the datacenter to the cloud
Good advice that follows the pattern of don't do a rewrite with a plan to cut-over. Instead make two and gradually transition to the newer one.
> Don't write your own secrets system
Follow-on to 'don't do your own crypto'
> Don't run your own Kubernetes cluster > Are you a Fortune 100 company? If no, then don't do it.
> Don't Design for Multiple Cloud Providers
This seems like an extension of YAGNI. If you're not using it, don't build it. If you really will need it, use it as you're building it. A good example is if you're doing multi-datacentre redundancy using standard tech, it might be worthwhile to do multi-cloud. But have an actual threat model in mind that this mitigates, e.g. cloud provider 'A' may become a conflict-of-interest competitor in the foreseeable future.
> Don't let alerts grow unbounded
> Don't write internal cli tools in python > Nobody knows how to correctly install and package Python apps. If you write an internal tool in Python, it either needs to be totally portable or just write it in Go or Rust. Save yourself a lot of heartache as people struggle to install the right thing.
+1 This one rarely gets mentioned.
One that I would add, that I haven't experienced but can certainly foresee is "don't switch major datastores". Switching between MySQL and PostgreSQL might be rough but doable. Switching between MySQL and CockroachDB for a large, heavily-used app could stall developing new features for a long time or make everything take 5x longer. The reason isn't the query syntax, it's the query characteristics. Using a std rdbms gives you the ability to do many relatively quick round-trip queries (though you should avoid N+1's) some can be tolerated. A distributed DB can have high throughput but will have high latency for simple queries.