3 ms·

The distinction between make and new is similar to Go. new allocates memory for the given type. make allocates memory referenced by the type. For example, a

by hsn915 4y ago

The distinction between make and new is similar to Go. new allocates memory for the given type. make allocates memory referenced by the type. For example, a slice is defined as: slice :: struct { data: rawptr, length: int } When you make a slice, you don't allocate space for the struct. You allocate space for the data to be referenced by the struct. > Umm, so there is a build system, but it's just integrated into the compiler? What is the benefit here? Rust has an excellent build system out of the box (cargo), but it's still separate from the compiler itself. What's the benefit of not having the build system integrated into the compiler? Ideally if you are not linking to external libraries, and all the code is in the language, you don't want to go through the typical stages of the C compiler where it first produces object files and then links them. You want to just produce the final exe directly. I don't think Odin does this - at least at this point - but anyway messing around with object files should be considered obsolete.

agluszak 4y ago
> What's the benefit of not having the build system integrated into the compiler? Being able to write new/integrate with existing build systems (i.e. Bazel). > Ideally if you are not linking to external libraries I'm afraid that's rarely the case. > messing around with object files should be considered obsolete. Messing with them yourself, as you need to do when you use `make` in C/C++ (without cmake or anything more fancy) - I agree, it should be considered obsolete. But what if I want to mess with them because, for example, I want to add support for Odin to Bazel?
- 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?

by hsn915 4y ago

agluszak 4y ago

> What's the benefit of not having the build system integrated into the compiler? Being able to write new/integrate with existing build systems (i.e. Bazel). > Ideally if you are not linking to external libraries I'm afraid that's rarely the case. > messing around with object files should be considered obsolete. Messing with them yourself, as you need to do when you use `make` in C/C++ (without cmake or anything more fancy) - I agree, it should be considered obsolete. But what if I want to mess with them because, for example, I want to add support for Odin to Bazel?

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?