Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If Odin Had Macros

gingerbill.org

Post reply on HN
Print view View original

11–20 of 29 posts

Re: If Odin Had Macros

#11

Post by kibwen »

valorzard wrote: post #2

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...

Rust shows that closures don't require automatic memory management, unless you consider Rust's static ownership analysis to be "automatic memory management", which I suppose you could, but it's all at compile-time, not runtime. Of course, it's fair if he doesn't want his language to have an ownership system, but ownership systems honestly aren't very complex, they're just different.

Re: If Odin Had Macros

#12

Post by whobre »

One of the things I like about Odin is the features it doesn't have. Package manager is the big one, but OOP constructs and macros are not far behind. Good job!

Re: If Odin Had Macros

#13

Post by PinkMilkshake »

Imustaskforhelp wrote: post #8
randomstringxyz wrote: post #6

Earlier quoted context omitted.

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.

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…

PUC Lua is supposedly a bit of a pain for ffi, but I havent tried it myself. Luajit is some kind of crazy magic. You can (almost) just copy and paste the c header file into the ffi.cdef function and then start using c functions as if they were lua functions.

Re: If Odin Had Macros

#14

Post by tialaramex »

doug-moen wrote: post #9
valorzard wrote: post #2

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...

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…

What Bill wrote, on his own web site, about his own language is simply this:

> For closures to work correctly would require a form of automatic memory management which will never be implemented into Odin.

I suppose you can insist Bill thinks "correctly" means all that verbiage about unified types - but then a reasonable question would be why doesn't Odin provide these "not correct" closures people enjoy in other languages ?

RAII is entirely irrelevant, the disposal of a closure over a Goose is the same as disposal of a Goose value itself. In practice I expect a language like Odin would prefer to close over references, but again Odin is able to dispose of references so what's the problem?

Re: If Odin Had Macros

#15

Post by bbkane »

Does anyone have good examples of the "metaprograms (programs that make/analyse a program" he's referring to?

Making these types of programs relatively easy in Go (with stdlib ways to manipulate source code) has been a huge boon to the ecosystem (golangci-lint linters, code gen tools).

I'd love to see examples of what that looks like in Odin

Re: If Odin Had Macros

#16

Post by bbkane »

kibwen wrote: post #11
valorzard wrote: post #2

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...

Rust shows that closures don't require automatic memory management, unless you consider Rust's static ownership analysis to be "automatic memory management", which I suppose you could, but it's all at compile-time, not runtime. Of course, it's fair if he doesn't want his language to have an ownership system, but ownership systems honestly aren't very complex, they're just different.

You really don't think ownership systems are that complex kibwen?

I just watched a recent Polonius talk ( https://m.youtube.com/watch?v=uCN_LRcswts ) and came away very impressed with the difficulty of implementing (or even modeling) the borrow checker. Or maybe you're referring to something else?

Re: If Odin Had Macros

#17

Post by gucci-on-fleek »

PinkMilkshake wrote: post #13
Imustaskforhelp wrote: post #8

Earlier quoted context omitted.

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…

PUC Lua is supposedly a bit of a pain for ffi, but I havent tried it myself. Luajit is some kind of crazy magic. You can (almost) just copy and paste the c header file into the ffi.cdef function and then start using c functions as if they were lua functions.

The LuaJIT ffi module has been ported to PUC Lua [0] (and abandoned and forked dozens of times), and it works pretty well in my experience.

[0]: https://github.com/dibyendumajumdar/ravi-ffi

Re: If Odin Had Macros

#18

Post by spartanatreyu »

bbkane wrote: post #15

Does anyone have good examples of the "metaprograms (programs that make/analyse a program" he's referring to? Making these types of programs relatively easy in Go (with stdlib ways to manipulate source code) has been a huge boon to the ecosystem (golangci-lint linters, code gen tools). I'd love to see examples of what that looks like in Odin

> Does anyone have good examples of the "metaprograms (programs that make/analyse a program" he's referring to?

That's a little tricky because almost anything can be a metaprogram. They're basically used when something could be "simplified" by writing a DSL, but you don't want to invent a whole new language (but you're going to anyway).

But some examples off the top of my head:

- For HTTP routers: HTTP methods (GET/POST/PATCH/DELETE/QUERY) are used when requesting a route. Instead of setting up the boilerplate of registering a url route and handling the different possible http method calls, a developer might want to use a more ergonomic macro to handle all the setup. (e.g. @(, )

- For MVC Frameworks (Same thing for MVVM, MVCL, MV*, etc... frameworks): Making a Model, View and Controller Macro that takes a name and a function and hooks it up to the application.

- For standards implementations: Adding special/non-standard bounds checking that is only calculated during compile time and removed from runtime for performance purposes (e.g. This int can only be between the ranges of -12 378 and 10621 11012)

- For game design: This level can only be solved by following the specified sequence. During the compile/build step, a proofer is run that ensures that the conditions for solving the level still hold. That way if someone adds a teleport item later in development, it doesn't break earlier levels.

- For testing: To mark a test case for a function

Re: If Odin Had Macros

#19

Post by ecshafer »

I really like Odin as a language. I have tried Rust and Zig as well (of the newer systems languages). I think that Odin has a great niche and a lot of potential in the games industry. If what you need is a systems language with good speed and manual memory management and memory safety, BUT you also need fast DEVELOPMENT speed its great. Rust slows down development speed too much, especially for something like games where you are playing things loose and need to pivot a lot. Zig is also fantastic, but I think that some of the extra safety features make it a bit slower in development speed.

Re: If Odin Had Macros

#20

Post by kibwen »

bbkane wrote: post #16
kibwen wrote: post #11

Earlier quoted context omitted.

Rust shows that closures don't require automatic memory management, unless you consider Rust's static ownership analysis to be "automatic memory management", which I suppose you could, but it's all at compile-time, not runtime. Of course, it's fair if he doesn't want his language to have an ownership system, but ownership systems honestly aren't very complex, they're just different.

You really don't think ownership systems are that complex kibwen? I just watched a recent Polonius talk ( https://m.youtube.com/watch?v=uCN_LRcswts ) and came away very impressed with the difficulty of implementing (or even modeling) the borrow checker. Or maybe you're referring to something else?

Ownership and the borrow checker two distinct things; putting these concepts together is the premier novelty of Rust. "Ownership" is this: an analysis pass that enforces single-ownership of values (call it "affine types" if you want to be fancy, but it's an extremely simple analysis), along with a mechanism to allow types to opt-out of single-ownership and allow multiple ownership/implicit copying (what Rust calls the `Copy` trait). That's all it is, and it automatically gives you Rust's trick of "automatic static memory management". It's much simpler than a borrow checker, which would also require a notion of generics and subtyping, to say nothing of lifetimes (or a control flow graph, which is what you want if you want a good borrow checker). Such a system of ownership without a borrow checker could even be memory-safe, if your language doesn't allow unmanaged pointers (though it wouldn't be as efficient as Rust, and would involve more copying, and makes for slightly more annoying APIs).
Post reply on HN