[HN Gopher] If Odin Had Macros
       ___________________________________________________________________
        
       If Odin Had Macros
        
       Author : mattwilsonn888
       Score  : 17 points
       Date   : 2025-09-26 09:13 UTC (3 days ago)
        
 (HTM) web link (www.gingerbill.org)
 (TXT) w3m dump (www.gingerbill.org)
        
       | valorzard wrote:
       | Something I don't get.
       | 
       | Odin doesn't support closures (a la C++ or Rust)
       | 
       | The thing is, I don't understand why.
       | 
       | Odin's FAQ says it's because closures require automatic memory
       | management. [0] But if that's the case, why do languages like C++
       | and Ada [1] support closures?
       | 
       | [0] https://odin-lang.org/docs/faq/#does-odin-have-closures
       | 
       | [1] https://learn.adacore.com/courses/advanced-
       | ada/parts/resourc...
        
         | wk_end wrote:
         | I can't speak for Ada, but C++ closures require that you
         | explicitly specify what's captured from the enclosing
         | environment and how (i.e. copy or reference). That capture is
         | also unsafe, which relates to the issue of automatic memory
         | management: for instance, if you have a function that returns a
         | closure that's captured a reference to something in the
         | function's stack frame, stack semantics mean that value will be
         | destroyed. I'm sure C++ developers are fine with them but -
         | having not used them in anger - they sound quite brittle.
         | 
         | The answer in the Odin FAQ maybe could be expanded to say "many
         | uses of closures require automatic memory management, and while
         | Odin could add some kind of support for closures to handle the
         | uses that don't, it'd add too much complexity and too much
         | potential for bugs to be worthwhile". Not to speak for
         | gingerbill, here.
        
         | csb6 wrote:
         | Automatic memory management isn't necessary for closures, but
         | if you don't have it then it is easy to have dangling pointers
         | (e.g. you capture a local variable by reference, return the
         | closure object, and then call the closure and use the
         | referenced variable). This is a problem in C++ but isn't in Ada
         | due to Ada's stricter scoping rules. Capturing variables by
         | value is safe (assuming the captured values contain no dangling
         | references themselves). It might require allocation if there
         | were type-erased function objects (like std::function in C++),
         | but this could be done using explicit allocator and deallocator
         | functions with some help from the compiler to determine the
         | closure object's size.
        
         | randomstringxyz wrote:
         | Conceptually, think about it. Coroutines require copying not
         | only the variables but the function itself, outside of the
         | lifetime of the parent function. (Or at least pointers
         | thereto.) I would like to hear about a language with static
         | coroutines but I am not aware of any. Even Rust doesn't do it,
         | they just make you pass the lifetime around.
        
         | doug-moen wrote:
         | what ginger bill actually said was
         | 
         | > I'd argue that actual closures which are unified everywhere
         | as a single procedure type with non-capturing procedure values
         | require some form of automatic-memory-management. That does not
         | necessarily garbage collection nor ARC, but it could be
         | something akin to RAII. This is all still automatic and against
         | the philosophy of Odin.
         | 
         | C++ doesn't have this feature either. A C++ closure does not
         | have the same type as a regular C-style function with the same
         | argument types and result type. The types of functions and
         | closures are not unified.
         | 
         | And C++ does have RAII, which the author feels is a kind of
         | automatic memory management and against the philosophy of Odin.
         | 
         | So C++ doesn't have the feature G.B. says is impossible. I
         | don't know enough to comment on Ada.
        
       | Imustaskforhelp wrote:
       | > The road to hell is not paved with good intentions but rather
       | the lack of intention.
       | 
       | Although I am a man who seemingly seems to love the idea of a
       | freedom of a language like nim,julia,lisp,(scala?) etc., just
       | langauges which can give you a lot of freedom in general, my
       | intention has always been: I have been asking for freedom irl,
       | what is wrong with giving developers freedom in programming
       | languages.
       | 
       | I can still respect this opinion and I followed up on pragmatic
       | choice and I mean, its Mr's Wilson's language and honestly the
       | freedom to have a language like this might be freedom in it of
       | itself too and I can respect his opinions and I might check odin
       | again later too.
       | 
       | https://skytrias.itch.io/todool I saw it from Odin lang page a
       | long time back ago and I actually really loved this tool/ am
       | thinking of creating an open source alternative in an another
       | language like golang/kotlin/typescript/nim (i like to imagine
       | things and be lazy sometimes lol) but there are definitely a lot
       | of projects like jangafx which are written in odin iirc which are
       | definitely really impressive
       | 
       | I will also think about this statement more as I do think that
       | the reason why I sometimes lack intention is because I want to
       | define good first, I don't want to take my opinions and run with
       | it if they hurt people directly or indirectly and I am willing to
       | have lack of opinions first to really understand the situation I
       | suppose but I can respect his opinion in this thing too.
       | Something worth thinking about for me. So thanks!
        
         | randomstringxyz wrote:
         | All of those languages have a lot of freedom, you just ("just")
         | need to reach into the FFI to do it. Lua, which is the only one
         | I have used extensively, is the most literal definition of
         | scripting. It's designed to be written in conjunction with C.
         | Even languages like Haskell with a gigantic runtime still
         | expect you to put in some C for hot paths.
        
           | Imustaskforhelp wrote:
           | FFI scares me if I am being honest and that is why I always
           | try to think of a language which can do a lot of things
           | themselves without having to reach for FFI thinking its going
           | to be my last resort most of the time.
           | 
           | So that was my perspective when I had written up my comment.
           | 
           | What are some really good languages for FFI? Lua as you
           | suggest?
           | 
           | I have always had this notion that FFI is really hard and so
           | firstly I would like to ask if that's really true and
           | secondly is there a langauge which can make it easy to work
           | with FFI the most? Like do you suggest lua for something?
        
       ___________________________________________________________________
       (page generated 2025-09-29 23:00 UTC)