Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
I think generics tip the scale. One neat thing about not trying too hard to make to make a super-awesome set that takes advantage of all the things sets can do and just straight-up settle for a map[T]struct{} is that you can swap out any existing map[T]struct{} in your code for the new set type, and nearly transparently drop in the new stuff with sensible implementations. (Note for those who may not realize it, it is perfectly valid go to take a library that implements a generic map[T]struct{} and drop it into your map[string]struct{} with no further modifications; you are not obligated to "keep" the genericness.) A generic library that tries to wrap a map[T]bool, from the point of view of a generic library, is making a much bigger assumption about those bools. Your local code is entitled to make such assumptions and deliberately choose a reduced subset of the types it is invoking, but a library author is much less entitled to assume that and ought to be a lot more nervous about what that true versus false means because their assumptions are being imposed on the user of the library.
Where we do use mocks, we primarily use GoMock.
This will be controversial, but I do think the considerations for good package design are agnostic to build system: raw go toolchain or Bazel. The build system can affect package layout, but you can still design a good model with either.
For larger object graphs do you roll everything by hand or encourage something like https://github.com/google/wire