Whiteboard coding almost always devolves into leetcode which also requires at home study. You're going to be spending evenings and weekends coding something in either case.
I'm assuming you're referring to the golang model of statically linking everything. That's not really doable when many popular libraries are (L)GPL'd like glibc and libstdc++. It also doesn't work if you want to provide a shared library and need to be compatible with every possible system. That's not my opinion it's just a deficiency of bazel.
The logic is backwards though. I may have multiple consumers of a library some of which may want static some of which may want dynamic. You need to create/import new targets to do this even though the original target creates both static and dynamic libs by default.
None, bazel's caching implementation is broken because they don't even know or specify what constituents a build hash/key. See this issue from 2018 that's still open [1].
No, they are extremely broken. You can only choose:
- Link everything static.
- Link everything dynamic.
- Link user libs as static and system libs as dynamic.
There is no easy way to link a single user lib static/dynamic without resorting to hacks/workarounds like re-importing the shared library or defining weird intermediate targets. It's completely broken.
That's the biggest problem with this model. With inference it's better to just use a dedicated model server. For training it's better to deploy on a massive dedicated machine. The only real use case left over is experimentation and debug for devs or students.
100% agree with this. There's nothing in the new standards past 17 that actually helps me in real life day to day work. Most of the new features are solely for code-golfers (see ranges). Mean while co-routines and other concurrency extensions have languished for years as TSs with only partial support. Here's the full list of TSs [1], half of which only have partial or no support despite being 5+ years old.