3 ms·

> Memory Safe > No garbage collector, no manual memory management. A work in progress, though. I couldn't find an explanation in the docs or elsewhere how Rue

> Memory Safe > No garbage collector, no manual memory management. A work in progress, though. I couldn't find an explanation in the docs or elsewhere how Rue approaches this. If not GC, is it via: a) ARC b) Ownership (ala Rust) c) some other way?

steveklabnik 11mo ago
I am playing around with this! I'm mostly interested in something in the space of linear types + mutable value semantics.
- echelon 11mo ago
  Nice! I see you're one of (if not the primary) contributor! Do you see this as a prototype language, or as something that might evolve into something production grade? What space do you see it fitting into, if so? You've been such a huge presence in the Rust space. What lessons do you think Rue will take, and where will it depart? I see compile times as a feature - that's certainly nice to see.
  - steveklabnik 11mo ago
    This is a project between me and Claude, so yeah :) It's a fun project for me right now. I want to just explore compiler writing. I'm not 100% sure where it will lead, and if anyone will care or not where it ends up. But it's primarily for me. I've described it as "higher than Rust, lower than Go" because I don't want this to be a GC'd language, but I want to focus on ergonomics and compile times. A lot of Rust's design is about being competitive with C and C++, I think by giving up that ultra-performance oriented space, I can make a language that's significantly simpler, but still plenty fast and nice to use. We'll see.
    - echelon 11mo ago
      Love it! I think that's a nice target. Have fun! :)
- oulipo2 11mo ago
  So linear type + mutable value would be quite close to Rust, right?
  - steveklabnik 11mo ago
    Rust has affine types, not linear. It also doesn't have mutable value semantics, it uses references, lifetimes, and borrowing.
    - EnPissant 11mo ago
      I've never seen any significant difference in linear vs affine types. To me it just seems like Rust has Linear types, and the compiler just inserts some code to destroy your values for you if you don't do it yourself. I guess the only difference is that linear types can _force_ you to manually consume a value (not necessarily via drop)? Is that what you are going for?
      - steveklabnik 11mo ago
        Affine types are "may use" and linear types are "must use," yeah. That is, linear types are stronger. See https://faultlore.com/blah/linear-rust/ https://faultlore.com/blah/linear-rust/ for a (now pretty old but still pretty relevant, I think) exploration into what linear types would mean for Rust.
- jasonwatkinspdx 11mo ago
  You might find one of my late brother's research interests relevant: https://www.cs.princeton.edu/~dpw/papers/space.pdf https://www.cs.princeton.edu/~dpw/papers/space.pdf
  - steveklabnik 11mo ago
    Thank you for the link! I'll check it out for sure. (And sorry to hear about your brother's passing.)
    - jasonwatkinspdx 11mo ago
      Yeah, that's just one of the essays he was on as a phd student, but he was really interested in the interaction of linear types and region inferencing as a general resource management framework. That grew into an interest in linear types as part of logical frameworks for modeling concurrency. But then like a lot of people he became disillusioned with academia, went to make some money on wall street, then focused on his family after that. Anyhow, I just thought it might be a good jumping off point for what you're exploring.
- torginus 11mo ago
  Could you please explain what this implies in layman's terms? I've read the definition of 'linear type' as a type that must be used exactly once, and by 'mutable value semantics', I assume, that unlike Rust, multiple mutable borrows are allowed? What's the practical implication of this - how does a Rue program differ from a Rust program? Does your method accept more valid programs than the borrow checker does?
  - steveklabnik 11mo ago
    I’m on my phone on a long road trip, so I can’t really give you a good lengthy explanation right now, to be honest. Mutable value semantics means no references at all, from a certain perspective. You can sort of think of linear types as RAII where you must explicitly drop. Sorta. “More programs” isn’t really the right way to think about it. Different semantics, so different programs :)
- onlyrealcuzzo 11mo ago
  Also working on a language / runtime in this space. It transpiles to Zig, so you have native access to the entire C library. It uses affine types (simple ownership -> transfers via GIVE/TAKES), MVCC & transactions to safely and scalably handle mutations (like databases, but it scales linearly after 32 cores, Arc and RwLock fall apart due to Cache Line Bouncing). It limits concurrent complexity only to the spot in your code WHERE you want to mutate shared memory concurrently, not your entire codebase. It's memory and liveness safe (Rust is only memory safe) without a garbage collector. It's simpler than Go, too, IMO - and more predictable, no GC. But it's nearly impossible to beat Go at its own game, and it's not zero overhead like Rust - so I'm pessimistic it's in a "sweet spot" that no one will be interested in. Time will tell.
  - steveklabnik 11mo ago
    Neat! Good luck, that sounds very cool. I have no idea what if anything I'm going to do about liveliness.
  - Imustaskforhelp 11mo ago
    can you share the link, sounds fascinating language to follow its development as well and good luck on this project!
- sureglymop 11mo ago
  Have you explored the ideas explored for the Vale language: https://vale.dev/ https://vale.dev/ May be an interesting approach. That language seems very academic and slow moving at the moment though.
  - steveklabnik 11mo ago
    I think Vale is interesting, but yeah, they have had some setbacks, in my understanding more to do with the personal lives of the author rather than the ideas. I need to spend more time with it.
deleted 11mo ago
[deleted]
freakynit 11mo ago
Check out V-lang ... it has the details. It's a beautiful language... but, mostly unknown.
- maleldil 11mo ago
  Oh, it's known. It just has an incredibly negative reputation on this site.
  - freakynit 11mo ago
    I kinda expected.. just hesitated to point it out.
  - baranul 11mo ago
    This "negative reputation" on here, looks to be something that was first artificially generated by competitors and then allowed to boil, along with those using the bubbling to promote themselves and their sites.
- aw1621107 11mo ago
  > Check out V-lang ... it has the details. Does it? From its docs [0]: > There are 4 ways to manage memory in V. > The default is a minimal and a well performing tracing GC. > The second way is autofree, it can be enabled with -autofree. It takes care of most objects (~90-100%): the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via GC. The developer doesn't need to change anything in their code. "It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything or expensive RC for each object. > For developers willing to have more low-level control, memory can be managed manually with -gc none. > Arena allocation is available via a -prealloc flag. Note: currently this mode is only suitable to speed up short lived, single-threaded, batch-like programs (like compilers). So you have 1) a GC, 2) a GC with escape analysis (WIP), 3) manual memory management, or 4) ...Not sure? Wasn't able to easily find examples of how to use it. There's what appears to be its implementation [1], but since I'm not particularly familiar with V I don't feel particularly comfortable drawing conclusions from a brief glance through it. In any case, none of those stand out as "memory safety without GC" to me. [0]: https://docs.vlang.io/memory-management.html https://docs.vlang.io/memory-management.html [1]: https://github.com/vlang/v/blob/master/vlib/builtin/prealloc.c.v#L4-L14 https://github.com/vlang/v/blob/master/vlib/builtin/prealloc...
pjmlp 11mo ago
ARC is GC, chapter 5. https://gchandbook.org/ https://gchandbook.org/
- andsoitis 11mo ago
  Sure, ARC is a form of very specific, constrained garbage collection. Compile-time, reference-counting GC, not runtime tracing GC. So no background collector, no heap tracing, and no stop-the-world pauses. Very different from the JVM, .Net, or Go.
  - pjmlp 11mo ago
    Reference counting is a GC algorithm from CS point of view, it doesn't matter if it is compile time or runtime. Additionally there isn't a single ARC implementation that is 100% compile time, that when looking at the generated machine code has removed all occurrences from RC machinery.
    - Warwolt 11mo ago
      But common, collouqialy "Garbage Collection" as a language feature refers to a run time garbage collector. Saying that the language has GC just because it has opt-in reference counting is needlessly pedantic
      - pjmlp 11mo ago
        Knowlege gets taught in specific institutions exactly because street knowledge is quite often incorrect, like in this case, spreading urban myths based in shaky foundations.
    - gf000 11mo ago
      While I am usually the one that also goes in and correct people incorrectly calling RC not a GC, the important distinction here is that Rust (and C++) has the necessary language constructs to be able to implement ref counting entirely as a library.

steveklabnik 11mo ago

I am playing around with this! I'm mostly interested in something in the space of linear types + mutable value semantics.

echelon 11mo ago
Nice! I see you're one of (if not the primary) contributor! Do you see this as a prototype language, or as something that might evolve into something production grade? What space do you see it fitting into, if so? You've been such a huge presence in the Rust space. What lessons do you think Rue will take, and where will it depart? I see compile times as a feature - that's certainly nice to see.
- steveklabnik 11mo ago
  This is a project between me and Claude, so yeah :) It's a fun project for me right now. I want to just explore compiler writing. I'm not 100% sure where it will lead, and if anyone will care or not where it ends up. But it's primarily for me. I've described it as "higher than Rust, lower than Go" because I don't want this to be a GC'd language, but I want to focus on ergonomics and compile times. A lot of Rust's design is about being competitive with C and C++, I think by giving up that ultra-performance oriented space, I can make a language that's significantly simpler, but still plenty fast and nice to use. We'll see.
  - echelon 11mo ago
    Love it! I think that's a nice target. Have fun! :)
oulipo2 11mo ago
So linear type + mutable value would be quite close to Rust, right?
- steveklabnik 11mo ago
  Rust has affine types, not linear. It also doesn't have mutable value semantics, it uses references, lifetimes, and borrowing.
  - EnPissant 11mo ago
    I've never seen any significant difference in linear vs affine types. To me it just seems like Rust has Linear types, and the compiler just inserts some code to destroy your values for you if you don't do it yourself. I guess the only difference is that linear types can _force_ you to manually consume a value (not necessarily via drop)? Is that what you are going for?
    - steveklabnik 11mo ago
      Affine types are "may use" and linear types are "must use," yeah. That is, linear types are stronger. See https://faultlore.com/blah/linear-rust/ https://faultlore.com/blah/linear-rust/ for a (now pretty old but still pretty relevant, I think) exploration into what linear types would mean for Rust.
jasonwatkinspdx 11mo ago
You might find one of my late brother's research interests relevant: https://www.cs.princeton.edu/~dpw/papers/space.pdf https://www.cs.princeton.edu/~dpw/papers/space.pdf
- steveklabnik 11mo ago
  Thank you for the link! I'll check it out for sure. (And sorry to hear about your brother's passing.)
  - jasonwatkinspdx 11mo ago
    Yeah, that's just one of the essays he was on as a phd student, but he was really interested in the interaction of linear types and region inferencing as a general resource management framework. That grew into an interest in linear types as part of logical frameworks for modeling concurrency. But then like a lot of people he became disillusioned with academia, went to make some money on wall street, then focused on his family after that. Anyhow, I just thought it might be a good jumping off point for what you're exploring.
torginus 11mo ago
Could you please explain what this implies in layman's terms? I've read the definition of 'linear type' as a type that must be used exactly once, and by 'mutable value semantics', I assume, that unlike Rust, multiple mutable borrows are allowed? What's the practical implication of this - how does a Rue program differ from a Rust program? Does your method accept more valid programs than the borrow checker does?
- steveklabnik 11mo ago
  I’m on my phone on a long road trip, so I can’t really give you a good lengthy explanation right now, to be honest. Mutable value semantics means no references at all, from a certain perspective. You can sort of think of linear types as RAII where you must explicitly drop. Sorta. “More programs” isn’t really the right way to think about it. Different semantics, so different programs :)
onlyrealcuzzo 11mo ago
Also working on a language / runtime in this space. It transpiles to Zig, so you have native access to the entire C library. It uses affine types (simple ownership -> transfers via GIVE/TAKES), MVCC & transactions to safely and scalably handle mutations (like databases, but it scales linearly after 32 cores, Arc and RwLock fall apart due to Cache Line Bouncing). It limits concurrent complexity only to the spot in your code WHERE you want to mutate shared memory concurrently, not your entire codebase. It's memory and liveness safe (Rust is only memory safe) without a garbage collector. It's simpler than Go, too, IMO - and more predictable, no GC. But it's nearly impossible to beat Go at its own game, and it's not zero overhead like Rust - so I'm pessimistic it's in a "sweet spot" that no one will be interested in. Time will tell.
- steveklabnik 11mo ago
  Neat! Good luck, that sounds very cool. I have no idea what if anything I'm going to do about liveliness.
- Imustaskforhelp 11mo ago
  can you share the link, sounds fascinating language to follow its development as well and good luck on this project!
sureglymop 11mo ago
Have you explored the ideas explored for the Vale language: https://vale.dev/ https://vale.dev/ May be an interesting approach. That language seems very academic and slow moving at the moment though.
- steveklabnik 11mo ago
  I think Vale is interesting, but yeah, they have had some setbacks, in my understanding more to do with the personal lives of the author rather than the ideas. I need to spend more time with it.

deleted 11mo ago

[deleted]

freakynit 11mo ago

Check out V-lang ... it has the details. It's a beautiful language... but, mostly unknown.

maleldil 11mo ago
Oh, it's known. It just has an incredibly negative reputation on this site.
- freakynit 11mo ago
  I kinda expected.. just hesitated to point it out.
- baranul 11mo ago
  This "negative reputation" on here, looks to be something that was first artificially generated by competitors and then allowed to boil, along with those using the bubbling to promote themselves and their sites.
aw1621107 11mo ago
> Check out V-lang ... it has the details. Does it? From its docs [0]: > There are 4 ways to manage memory in V. > The default is a minimal and a well performing tracing GC. > The second way is autofree, it can be enabled with -autofree. It takes care of most objects (~90-100%): the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via GC. The developer doesn't need to change anything in their code. "It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything or expensive RC for each object. > For developers willing to have more low-level control, memory can be managed manually with -gc none. > Arena allocation is available via a -prealloc flag. Note: currently this mode is only suitable to speed up short lived, single-threaded, batch-like programs (like compilers). So you have 1) a GC, 2) a GC with escape analysis (WIP), 3) manual memory management, or 4) ...Not sure? Wasn't able to easily find examples of how to use it. There's what appears to be its implementation [1], but since I'm not particularly familiar with V I don't feel particularly comfortable drawing conclusions from a brief glance through it. In any case, none of those stand out as "memory safety without GC" to me. [0]: https://docs.vlang.io/memory-management.html https://docs.vlang.io/memory-management.html [1]: https://github.com/vlang/v/blob/master/vlib/builtin/prealloc.c.v#L4-L14 https://github.com/vlang/v/blob/master/vlib/builtin/prealloc...

pjmlp 11mo ago

ARC is GC, chapter 5. https://gchandbook.org/ https://gchandbook.org/

andsoitis 11mo ago
Sure, ARC is a form of very specific, constrained garbage collection. Compile-time, reference-counting GC, not runtime tracing GC. So no background collector, no heap tracing, and no stop-the-world pauses. Very different from the JVM, .Net, or Go.
- pjmlp 11mo ago
  Reference counting is a GC algorithm from CS point of view, it doesn't matter if it is compile time or runtime. Additionally there isn't a single ARC implementation that is 100% compile time, that when looking at the generated machine code has removed all occurrences from RC machinery.
  - Warwolt 11mo ago
    But common, collouqialy "Garbage Collection" as a language feature refers to a run time garbage collector. Saying that the language has GC just because it has opt-in reference counting is needlessly pedantic
    - pjmlp 11mo ago
      Knowlege gets taught in specific institutions exactly because street knowledge is quite often incorrect, like in this case, spreading urban myths based in shaky foundations.
  - gf000 11mo ago
    While I am usually the one that also goes in and correct people incorrectly calling RC not a GC, the important distinction here is that Rust (and C++) has the necessary language constructs to be able to implement ref counting entirely as a library.