Ask HN: Anyone using Bazel at startups? or migrated to/away from Bazel?

Can't you use something like Maven build cache ( https://maven.apache.org/extensions/maven-build-cache-extens... ) for that?

I tried Bazel when it was first released as open-source but migrated away from it pretty quickly. It was just too complex for what it brought to the table. In a startup you should only be doing things that directly validate your business hypothesis, and futzing around with your build system is not really one of them.

I found it much more productive to use the native package managers and build systems that go with your language, eg. npm for Node, pip for Python, Gradle for Java or Kotlin.

Briefly looked into Bazel, but settled on pantsbuild since Google seems to have just thrown all the language support over the wall to the community.

Being able to trivially setup CI on Github has been very helpful and important to me.

Being able to easily add targets and package things that require multiple microservices has been nice.

People say you can use the native tooling, but what even is the native tooling for python? It doesn't have a standardized packaging tool unless you count docker. pants' support for pex was important for me until we eventually adopted containers.

Folks can (and did) get the native packaging wrong, particularly when they were not super familiar with the language they needed to pick up on the fly.

Having to deal with an abstraction layer over the tooling has introduced some of its own headaches (eg for docker), but mostly for advanced features.

In the end, I'm pretty happy, I see it as an investment in CI, and the CI has caught a bunch of real bugs people pushed.

I think starting early here has been good, since the lift to get onto it has been small.

- It copies your files into a temporary directory to run them and that directory is named an obnoxiously long hash digest, so it effectively takes a giant shit in all your stack traces. When you're looking at an error message, half of your field of vision is taken up by line noise of the same random hash over and over again and since it runs your Python the first few frames are just helpfully telling you "this code was run through bazel". I even wrote a script that scanned my clipboard for Python stack traces, parsed them and removed this noise to make it easier on my brain to search for the actual line with the error.

- Every import you write you have to write in two files or three if you have to export it. It's double the typing work and finding the target is a pain because there's no jump to definition of the Bazel target so it's even more typing to find it.

- I wanted to use pytest and it was much more work, I don't think I ever got it working. Normally there's no setup you just run "pytest" and it discovers all the tests and runs them.

- Your code doesn't start running as quickly.

- You have to type way more characters to start your code. I had aliases for every endpoint.

- There was something with tests where if the error log was too long it would just say "there was an error, please find it in this randomly-named file" and when you're debugging a test whose error log is too long it's going to be too long every time you re-run it too. So running and seeing the error is now a two step operation, double the work.

Maybe some things have changed or I misremembered something, but overall it was the part of our tech stack I really hated. I just wrote software, I didn't do any ops or any sort of deployment or touched live systems at all really, so I honestly have no clue what it actually did for us it was just pure downside for me. I would never use it.