Aside from the mandatory negotiation with the employee co-determination (works council), the layoffs "must be determined according to the principles of social selection [...] (t)his is often perceived as a major obstacle [...] it would be disastrous to have to dismiss top performers simply because they are younger than other employees or have been recently hired."
You are on the spot, it's almost impossible to lay somebody off who is like 50 y/o and has kids + has been with the company for quite a while.
Generally, workers rights here in Germany are quite good so as an employee life tends to be quite comfortable since you don't have to fear termination the moment the company isn't doing exceptionally well.
Bazel streamlines the build process with native code (C++/Rust) in Python, making the experience a breeze. However, the drawback is that you would need to transition to Bazel.
I'm not sure if it's still true, but I believe back at Google the interop with C/C++ was even more integrated - if I'm not mistaken the "java" binary got recompiled from scratch (but thanks for caching, not much hit), and your C/C++ code got compiled in with it - so no ".so" loading - you still have single binary (and I think the .jar also went at the end of the file).
Or maybe that was for python (e.g. compile CPython along with any ffi modules as one) + .zip file with classes.
In any case, even if above was not 100% true, it's doable with system like bazel/buck/etc., and still allow you for smooth incremental development (or say in the default "fastbuild" .so files may still be used - locally, but in "opt" the full static link, or through a --config)
My main issue with bazel is that adopting it means giving up good editor integrations for anything besides JVM (maybe C/C++ as well, I haven't touched that). And even then, only IntelliJ has good support.
I think a lot of smaller (read: most) companies adopt bazel without realizing this. You will pay dearly in terms of developer experience in exchange for the benefits bazel purports to offer.
There are some workarounds. In my company we have a script that generated IDE files automatically. It uses `bazel query` and `bazel build` to find all external and non native dependencies, and then generates IDE config and files for rust, java, python, etc.
Positives: your IDE experience becomes native and you don't need to interact with bazel for normal IDE work flows.
Negatives: need to run the generate script anything non native changes. Also need to deal with bazel build files etc for the git workflow, obviously.
We're small company, and this method has worked great, and we have a pretty complex build with python accessing rust and java (via jni). Java accessing rust and c (via jni).
Yes that's true. To this day using bazel + IntelliJ and I can't jump into some header files from other @repos// (it could be that I'm on Windows, and this doesn't work there). Need to give it a try on Linux/OSX.
To commoditize your complements, so that you don't have to pay license fee to your suppliers.
In a way, the German OEMs have been trying to do so, but mostly via different standardization efforts (OpenSCENARIO for example) so that they can easily change suppliers.
