4 ms·

Odin claims to be pragmatic (what language doesn't lol) but "All procedures that returned allocated memory will require an explicit allocator to be passed". Cha

Odin claims to be pragmatic (what language doesn't lol) but "All procedures that returned allocated memory will require an explicit allocator to be passed". Charitably, is this aimed at c/zig heads?

BigJono 9mo ago
I'm guessing it's aimed at game development since Vulkan has a similar pattern in every function call (although optional, the driver does it's own allocation if you pass null).
- astrange 9mo ago
  That's a pretty heavyweight pattern. Wouldn't dynamic scope be better?
  - miningape 9mo ago
    As another commenter wrote "how do you allocate memory without an allocator?" Even `malloc` has overhead. > Wouldn't dynamic scope be better? Dynamic scope would likely be heavier than what Odin has, since it'd require the language itself to keep track of this - and to an extent Odin does do this already with `context.allocator`, it just provides an escape hatch when you need something allocated in a specific way. Then again, Odin is not a high level scripting language like Python or JavaScript - even the most bloated abstractions in Odin will run like smooth butter compared to those languages. When comparing to C/Rust/Zig, yeah fair, we'll need to bring out the benchmarks.
    - johnisgood 9mo ago
      > and to an extent Odin does do this already with `context.allocator` It has a temporary allocator as well, which could track memory leaks. Not so much anymore though, IIRC. > As another commenter wrote "how do you allocate memory without an allocator? I would like to point out that this is basic knowledge. At first I was wondering if I have gone insane and it really is not the case anymore or something.
      - deleted 9mo ago
        [deleted]
    - MangoToupe 9mo ago
      > As another commenter wrote "how do you allocate memory without an allocator?" You call these things something other than an "allocating" and "allocators". Seriously, few people would consider adding a value to a hashmap an intentionally allocational activity, but it is. Same with adding an element to a vector, or any of the dependent actions on it. Seriously
      - tialaramex 9mo ago
        For "adding an element to a vector" it's actually not necessarily what you meant here and in some contexts it makes sense to be explicit about whether to allocate. Rust's Vec::push may grow the Vec, so it has amortized O(1) and might allocate. However Vec::push_within_capacity never grows the Vec, it is unamortized O(1) and never allocates. If our value wouldn't fit we get the value back instead.
      - miningape 9mo ago
        Yep exactly, at it's simplest all an allocator is doing is keeping track of which memory areas are owned and their addresses. In a sense even the stack pointer is a kind of allocator (you can assign the memory pointed to by the stack pointer and then increment it for the next use)
    - astrange 9mo ago
      > Dynamic scope would likely be heavier than what Odin has, since it'd require the language itself to keep track of this Not necessarily, you can imagine that malloc() itself has an API that says "temporarily switch calls on this thread to a different allocator" and then you undo it later.
messe 9mo ago
> All procedures that returned allocated memory will require an explicit allocator to be passed All procedures in core/os. Odin isn't removing the allocator from implicit context in the rest of its APIs.
leecommamichael 9mo ago
All you've got to do is write `context.allocator` to abide.
ycombinatrix 9mo ago
How do you allocate memory without an allocator?
- tialaramex 9mo ago
  The usual thing for languages is to provide a global allocator. That's what C's malloc is doing for example. We're not asked to specify the allocator, it's provided by the language runtime so it's implied everywhere. In standalone C, or Rust's no_std, there is no allocator provided, but most people aren't writing bare metal software.
  - ycombinatrix 9mo ago
    That creates problems when you need to use multiple allocators. IMO allowing an allocator to be specified is a superior design.
    - MangoToupe 9mo ago
      If you need multiple allocators, and you aren't already using lisp, who cares? Just use lisp. Anyone who can use allocators against the C abi can clearly see the benefits of using a language that can cater to the developer. Zig can never do this, yea even with its shallow macros. Zig will always be a shitty B knockoff rather than something artisans actually want to use
- MangoToupe 9mo ago
  You call the use of memory something other than "allocation". Ez. I thought that passing down allocators was core to the language. I was mistaken. This is actually quite nice for writing allocation code when you'd like to opt into it.

Odin claims to be pragmatic (what language doesn't lol) but "All procedures that returned allocated memory will require an explicit allocator to be passed". Charitably, is this aimed at c/zig heads?

BigJono 9mo ago

I'm guessing it's aimed at game development since Vulkan has a similar pattern in every function call (although optional, the driver does it's own allocation if you pass null).

astrange 9mo ago
That's a pretty heavyweight pattern. Wouldn't dynamic scope be better?
- miningape 9mo ago
  As another commenter wrote "how do you allocate memory without an allocator?" Even `malloc` has overhead. > Wouldn't dynamic scope be better? Dynamic scope would likely be heavier than what Odin has, since it'd require the language itself to keep track of this - and to an extent Odin does do this already with `context.allocator`, it just provides an escape hatch when you need something allocated in a specific way. Then again, Odin is not a high level scripting language like Python or JavaScript - even the most bloated abstractions in Odin will run like smooth butter compared to those languages. When comparing to C/Rust/Zig, yeah fair, we'll need to bring out the benchmarks.
  - johnisgood 9mo ago
    > and to an extent Odin does do this already with `context.allocator` It has a temporary allocator as well, which could track memory leaks. Not so much anymore though, IIRC. > As another commenter wrote "how do you allocate memory without an allocator? I would like to point out that this is basic knowledge. At first I was wondering if I have gone insane and it really is not the case anymore or something.
    - deleted 9mo ago
      [deleted]
  - MangoToupe 9mo ago
    > As another commenter wrote "how do you allocate memory without an allocator?" You call these things something other than an "allocating" and "allocators". Seriously, few people would consider adding a value to a hashmap an intentionally allocational activity, but it is. Same with adding an element to a vector, or any of the dependent actions on it. Seriously
    - tialaramex 9mo ago
      For "adding an element to a vector" it's actually not necessarily what you meant here and in some contexts it makes sense to be explicit about whether to allocate. Rust's Vec::push may grow the Vec, so it has amortized O(1) and might allocate. However Vec::push_within_capacity never grows the Vec, it is unamortized O(1) and never allocates. If our value wouldn't fit we get the value back instead.
    - miningape 9mo ago
      Yep exactly, at it's simplest all an allocator is doing is keeping track of which memory areas are owned and their addresses. In a sense even the stack pointer is a kind of allocator (you can assign the memory pointed to by the stack pointer and then increment it for the next use)
  - astrange 9mo ago
    > Dynamic scope would likely be heavier than what Odin has, since it'd require the language itself to keep track of this Not necessarily, you can imagine that malloc() itself has an API that says "temporarily switch calls on this thread to a different allocator" and then you undo it later.

messe 9mo ago

> All procedures that returned allocated memory will require an explicit allocator to be passed All procedures in core/os. Odin isn't removing the allocator from implicit context in the rest of its APIs.

leecommamichael 9mo ago

All you've got to do is write `context.allocator` to abide.

ycombinatrix 9mo ago

How do you allocate memory without an allocator?

tialaramex 9mo ago
The usual thing for languages is to provide a global allocator. That's what C's malloc is doing for example. We're not asked to specify the allocator, it's provided by the language runtime so it's implied everywhere. In standalone C, or Rust's no_std, there is no allocator provided, but most people aren't writing bare metal software.
- ycombinatrix 9mo ago
  That creates problems when you need to use multiple allocators. IMO allowing an allocator to be specified is a superior design.
  - MangoToupe 9mo ago
    If you need multiple allocators, and you aren't already using lisp, who cares? Just use lisp. Anyone who can use allocators against the C abi can clearly see the benefits of using a language that can cater to the developer. Zig can never do this, yea even with its shallow macros. Zig will always be a shitty B knockoff rather than something artisans actually want to use
MangoToupe 9mo ago
You call the use of memory something other than "allocation". Ez. I thought that passing down allocators was core to the language. I was mistaken. This is actually quite nice for writing allocation code when you'd like to opt into it.