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…
FFI is harder if the target lib doesn't have a C interface.
I feel I'm forced to reach for FFI if I want to do anything graphical e.g Wayland or OpenGL. Otherwise it's optional
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.
The parent is talking about closures, not coroutines. Rust does have closures that don't require a GC or passing lifetimes around (there's not even any syntax for putting a lifetime on a closure).
Rust closures can have lifetimes, and the lifetime of a closure is restricted to the lifetime of the shortest lived reference that it captures. But that just means the compiler protects you from having dangling pointers in your closure. And I don't think you can get much better than that without a runtime garbage collector.
I’ve been writing only Odin for about 6 months now and I love it. The grammar is dead-simple, and I’ve successfully intuited how dozens of features work and compose together. My GUI app goes from compiling to painting a frame in under a second. How cool is that?
The parent is talking about closures, not coroutines. Rust does have closures that don't require a GC or passing lifetimes around (there's not even any syntax for putting a lifetime on a closure).
Rust closures can have lifetimes, and the lifetime of a closure is restricted to the lifetime of the shortest lived reference that it captures. But that just means the compiler protects you from having dangling pointers in your closure. And I don't think you can get much better than that without a runtime garbage collector.
A Rust closure "has" a lifetime in the sense that the anonymous underlying struct that Rust creates to hold the closed-over values has a lifetime, but that's not a requirement to have closures without a GC. Like C++, Odin doesn't care about being memory-safe, so you can just say "be careful doing anything that involves pointers" (which is how the language already works), or if you wanted to be a little safer you could just forbid closing over anything that contained a pointer.
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 th…
Would this simple system efficiently allow for larger data structures to be referenced instead of copied?
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/P…
Sorry, I meant specific pieces of Odin code that do metaprogramming like this
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 th…
Would this simple system efficiently allow for larger data structures to be referenced instead of copied?
References are the purview of the borrow checker, naturally, but (assuming that you care about memory safety) you might be able to get away with a system that doesn't let you store arbitrary references, but conceivably you could have some kind of simple-ish scope-based analysis that might allow the compiler to transparently elide copies when passing owned values to functions deeper in the call stack. A mechanism to reify the notion of strictly-scoped values in the language (like Python's `with` statement) could probably go quite far here, allowing your compiler to know that a piece of data is anchored to a given scope which strictly outlives some child scopes, allowing a reference to that data to remain valid for those child scopes. You'd still have to have Rust's notion of aliasing XOR mutation, but if references are first-class values this might be tractable, because you get much of this for free from an ownership system (mutable references are owned, immutable references are copyable), although Rust has several other ways that it bends over backwards to make this work nicely (e.g. compiler-inserted reborrowing). If you wanted to avoid this complexity you could start by just sticking to only having immutable references that allow copying the inner data if you want to mutate it.
Would this simple system efficiently allow for larger data structures to be referenced instead of copied?
References are the purview of the borrow checker, naturally, but (assuming that you care about memory safety) you might be able to get away with a system that doesn't let you store arbitrary references, but conceivably you could have some kind of simple-ish scope-based analysis that might allow the compiler to transparently elide copies when passing owned values to functions deeper in the call stack. A mechanism to r…
Sounds interesting - I'm not entirely convinced it would work, but I'm certainly less of an expert than you on this :D
I’ve been writing only Odin for about 6 months now and I love it. The grammar is dead-simple, and I’ve successfully intuited how dozens of features work and compose together. My GUI app goes from compiling to painting a frame in under a second. How cool is that?
By "GUI app", do you mean a real GUI app with widgets/controls like labels, text boxes, list boxes, etc, or just a graphics painting app?
Asking because there was a recent Odin thread on HN where someone said that there are currently no bindings to a GUI framework for Odin.