3 ms·

I'm confused. What sort of advantage do you imagine a build system like Bazel would provide for you? Build systems for C are bandaids. You would not ideally w

by hsn915 4y ago

I'm confused. What sort of advantage do you imagine a build system like Bazel would provide for you? Build systems for C are bandaids. You would not ideally want them. They are extra baggage that you just have to carry around because of legacy reasons. It's not something to want.

necubi 4y ago
It's primarily an advantage if you're trying to perform builds across languages. Bazel lets you build a C library that gets linked into a Rust application from a single build definition.
jvolkman 4y ago
> What sort of advantage do you imagine a build system like Bazel would provide for you? Build my C (or Rust, or Odin) Python extension, package the Python app with the extension and whatever other dependencies are required (e.g., generated protocol buffer libraries) into a Docker image, push the image to a docker repo, and apply changes to a Kubernetes deployment with a single command, and without doing any unnecessary work like rebuilding those native extensions if nothing has changed.
- hsn915 4y ago
  While that sounds abhorant to me, I can't think of a reason why you can't fit the odin compiler in there. Just have a step where the odin compiler is executed, and take its output and pipe it through the rest of the system.
pie_flavor 4y ago
Does Odin's build system solve all the problems Bazel does, e.g. scalable and nearly perfect caching? And why were you under the impression it is only useful for C, given that those problems need to be solved in a wide variety of languages? Cargo is best-in-class, but the build times for our monorepo convinced us to switch to building Rust with Bazel just for the CI experience. This is, in fact, the primary problem I have with Odin: it builds on almost nothing that came before it, assuming that everything is C/complex/hidden/just generally NIH, and throws away the good with the bad.
- hsn915 4y ago
  I suppose for me it's the opposite: that's one of the attractive things about it. It doesn't just blindly accept the way things have always been done. > Cargo is best-in-class, but the build times for our monorepo convinced us to switch to building Rust with Bazel just for the CI experience. I'm a bit surprised (not really) you don't see the contradiction in your statement. Something is really slow that you decided to throw it away, but it's also "best in class". I wonder if that's what the "best in class" is, what that says about the entire class? Maybe it's really all garbage?
  - pie_flavor 4y ago
    What best in class means is that it solves large numbers of problems, like dependency hell, or opt-in library features, that no other system of its style solves (including Odin). The problem that it doesn't solve, i.e. scalable perfect caching, is also a problem that Odin doesn't solve, and no other system solves except Bazel, but you would not call Bazel the best because it has many developer-experience and learning-curve related downsides in addition to being out-of-ecosystem. For repos big enough where build times are a serious problem, you want to trade out a better system for Bazel, because what you lose in DX you gain eightfold in performance, a tradeoff that is only good if performance is significantly negatively impacting DX. So, to recap, Odin is incapable of solving a problem many people have due to an aspect of its design that everyone knows you shouldn't do, but Odin doesn't bother with what everyone knows you should do. The thought process in Odinspace is that it is Old and Odin is New, and therefore while nobody has bothered checking what sort of problem this system solves, it can't be important because it's Old. You praise it for not blindly accepting what other languages do, but what it instead does is blindly reject what other languages do. Blindness is the problem, not acceptance.

by hsn915 4y ago

necubi 4y ago

It's primarily an advantage if you're trying to perform builds across languages. Bazel lets you build a C library that gets linked into a Rust application from a single build definition.

jvolkman 4y ago

> What sort of advantage do you imagine a build system like Bazel would provide for you? Build my C (or Rust, or Odin) Python extension, package the Python app with the extension and whatever other dependencies are required (e.g., generated protocol buffer libraries) into a Docker image, push the image to a docker repo, and apply changes to a Kubernetes deployment with a single command, and without doing any unnecessary work like rebuilding those native extensions if nothing has changed.

hsn915 4y ago
While that sounds abhorant to me, I can't think of a reason why you can't fit the odin compiler in there. Just have a step where the odin compiler is executed, and take its output and pipe it through the rest of the system.

pie_flavor 4y ago

Does Odin's build system solve all the problems Bazel does, e.g. scalable and nearly perfect caching? And why were you under the impression it is only useful for C, given that those problems need to be solved in a wide variety of languages? Cargo is best-in-class, but the build times for our monorepo convinced us to switch to building Rust with Bazel just for the CI experience. This is, in fact, the primary problem I have with Odin: it builds on almost nothing that came before it, assuming that everything is C/complex/hidden/just generally NIH, and throws away the good with the bad.

hsn915 4y ago
I suppose for me it's the opposite: that's one of the attractive things about it. It doesn't just blindly accept the way things have always been done. > Cargo is best-in-class, but the build times for our monorepo convinced us to switch to building Rust with Bazel just for the CI experience. I'm a bit surprised (not really) you don't see the contradiction in your statement. Something is really slow that you decided to throw it away, but it's also "best in class". I wonder if that's what the "best in class" is, what that says about the entire class? Maybe it's really all garbage?
- pie_flavor 4y ago
  What best in class means is that it solves large numbers of problems, like dependency hell, or opt-in library features, that no other system of its style solves (including Odin). The problem that it doesn't solve, i.e. scalable perfect caching, is also a problem that Odin doesn't solve, and no other system solves except Bazel, but you would not call Bazel the best because it has many developer-experience and learning-curve related downsides in addition to being out-of-ecosystem. For repos big enough where build times are a serious problem, you want to trade out a better system for Bazel, because what you lose in DX you gain eightfold in performance, a tradeoff that is only good if performance is significantly negatively impacting DX. So, to recap, Odin is incapable of solving a problem many people have due to an aspect of its design that everyone knows you shouldn't do, but Odin doesn't bother with what everyone knows you should do. The thought process in Odinspace is that it is Old and Odin is New, and therefore while nobody has bothered checking what sort of problem this system solves, it can't be important because it's Old. You praise it for not blindly accepting what other languages do, but what it instead does is blindly reject what other languages do. Blindness is the problem, not acceptance.