18 karma · joined December 2, 2023
I'd love a rebrand or rename in order to avoid having to work around the name collision.
Best of luck!
Once I know the other person is good at the gripfight in a certain position, I immediately let go and try to counterattack from another angle.
It's the only reliable way I've found to save my fingers lol
Wrestling/no-gi BJJ doesn't have a gi, so players can't lock down their opponents as much and there's a lot more movement in neutral. And Judo has a gi, but the way you win is via high-amplitude throws, which is a much more spectacular win condition. I think they're both much more exciting to watch than regular gi BJJ, especially for non-practitioners.
I think BJJ's main spectator-unfriendly flaws are that it has a gi and doesn't reward high-amplitude movements. So, unsurprisingly, the metagame has evolved around locking down your opponents.
(Background: I did Judo as a kid, and do BJJ now.)
In general, I think finding a relationship requires thoughtful effort but isn't particularly difficult. If relationships are seemingly impossible to find (e.g. for many incels), I think they either aren't putting enough thoughtful effort in (e.g. not realizing how some of their views/habits/mannerisms are off-putting to their target audience) or are looking in the wrong places (e.g. dating apps where the odds are too stacked against them).
1. Bazel requires non obvious, continued maintenance. Bazel is a theoretically hermetic build system with universal caching and near constant build times. The sticking point is that it only has those properties if someone sets it up correctly and maintains its infrastructure. At our company, no one set this up, and as a result build times ballooned and local development became a mess of bash and docker. And even if someone had set this up, who would maintain it? We would have had to expand the infra team, and even a couple of people extra can be a lot for a startup.
2. Bazel also has support for every language, which is theoretically true. In practice, this support is often incomplete, out of date, poorly documented, badly supported, or some unfortunate combination, because the (language)+bazel communities that support the docs, tooling, etc are often orders of magnitude smaller than teams that work with (language). So teams that use bazel are forced to choose between two bad options: integrate things the bazel way and rely on the relatively small (language)+bazel open source communities and tools of questionable quality, or use the much much larger (language) open source communities and hack the tooling in. We did the former, and it was hell, because we a) didn't have feature complete community tooling and b) upgrading the bazel version required every team at our company that was using bazel to stop working and simultaneously check trial bazel versions for breakages.
3. Bazel makes hiring and onboarding harder. In order to fix the above problems, you need people that know bazel. Hiring someone that knows, say, python is hard enough. But python and bazel? The hiring pipeline immediately gets reduced, which means you either have to spend more time searching for qualified candidates or more time onboarding candidates who don't quite fit all your criteria.
All in all, I would recommend against bazel unless you: 1. Have or can hire a preexisting community of knowledgeable bazel developers who will make up a sizeable portion of the company. 2. Have full executive support for multiple years while the infrastructure is being created, and executive support for maintenance teams thereafter 3. Actual, company-wide problems with builds that justify the former two criteria.