Bazel is an investment to learn for sure but your effort estimates are way overblown. We have a Python, Go, and Typescript monorepo that I setup for our team and rarely have to touch anything. Engineers rarely think about Bazel as we use Gazelle to generate all our build files and have patterns for most everything we need to do.
Compared with build efforts using other tools and non-monorepo setups at other companies the effort here has felt much reduced.
No need to be snarky; that API did not exist when I started using protobuf. The method was called `TimestampProto` which is not intuitive, especially given the poor documentation available. And it required error handling which is unergonomic. Given that they switched it to timestamppb.New, they must've agreed with me. https://github.com/golang/protobuf/blame/master/ptypes/times... <-- and you can still see the full code from this era on master because of the migration from `github.com/golang/protobuf` to `google.golang.org/protobuf`, which was a whole other exercise in terrible DX.
It's weird to me that GitHub doesn't have larger machines types available for actions yet. I don't want to bother with a self-hosted runner just to get more CPUs. They have much larger machines available for Codespaces - why not actions? I'm happy to pay for them.
Hey founder of BuildJet here,
With BuildJet for GitHub Actions, you can get up to 64 vCPU as a GitHub Actions runner. We plug right into your existing setup and have a significantly higher per core performance compared to the native runner.
Congrats - PIOSolver is an amazing program. What are the future plans for it? It would be great if you didn't need a PhD to set it up though. I keep wondering if I'm actually training myself using the right solutions or not based on the setup :)
The plans are to start turning it into real company which hopefully means easier to use software, more learning material and better communication. Till now it was mostly two guys working from home and overwhelmed by it all.
This is one of the major benefits of open source. You can share engineering resources, even with your competitors, for things that aren't your bread & butter.
I think Stripe does a lot of things right, but your comments back in 2018 certainly indicated that Billing could be used in perpetuity:
"- For existing customers, there's no pricing change. You just get more functionality than before for free. This is what we generally try to do: we want Stripe to continually become better value for you over time, as you get more functionality for the same price."
I specifically reached out to Stripe support back then to verify this would be the case and they confirmed. If you've since changed your mind, I think you should come out and say that's the case as opposed to saying this is a communications issue.
Thanks for the question. Beam has a more complex execution model and AFAIK also needs some executor environment like Spark to really parallelize workloads. Given a mongodb that all producers and consumers can attach to, minibatch runs anywhere.
Anything that won’t work if you tried this as a drop in replacement for a full PG instance in tests? Maybe extensions? Any benchmarks?