5 ms·

Author here, Cone is a pretty fascinating language. It builds a borrow checker on top of any user-specified allocator, whether that be single ownership, refere

Author here, Cone is a pretty fascinating language. It builds a borrow checker on top of any user-specified allocator, whether that be single ownership, reference counting, arenas, garbage collection, or any other user-specified strategy. A user can even code their own. It's a very promising approach, because it preserves the borrow checker's strengths while addressing its the borrow checker's development velocity downsides. GC and RC often make a program's overall architecture looser and more flexible, but by offering borrow checking for everything else, it allows a program to much more cut down on its memory safety overhead. What Cone does differently than other languages is that it decouples the allocation strategy from the type of data you're working with. This makes it much easier to change your code to use different memory safety styles. In a way, it's like Rust but allows for more flexibility on memory management. It's still in progress, but I encourage anyone interested in languages and memory safety to take a look: https://cone.jondgoodwin.com/ https://cone.jondgoodwin.com/

zozbot234 4y ago
User-specified local allocators are planned for Rust too. Among other things, they're needed for feature parity with C++.
- comex 4y ago
  Technically it’s only the standard library that lacks custom allocator support. Box and Vec and all the rest are “just” types defined in the standard library, and if you define your own, you can use any allocator you want and still take advantage of the borrow checker and other language features. This has been possible since 1.0. …Well, except for certain magic features that the standard library types get that you can’t (yet) replicate in a custom type. This is an annoying wart, but they’re relatively minor. But yeah, custom allocator support for standard library containers is planned.
- FpUser 4y ago
  >"feature parity with C++" I think Rust is missing a fair bit more than "user-specified local allocators" to be on feature parity with C++. Curious if it plans to be on full feature parity.
  - pkolaczk 4y ago
    It definitely misses some features that are considered bad: e.g implementation inheritance or memory handling by exceptions. Those are not essential for anything and are not planned.
    - FpUser 4y ago
      >" implementation inheritance " What authority declares implementation inheritance bad may I ask? As long as one does not stick it into inappropriate places it is actually very helpful.
      - pkolaczk 4y ago
        1. it can be always replaced with composition, which Rust already supports 2. it comes with a non-negligible complexity cost to the language (e.g. what if you do multiple inheritance, what code gets called at object construction etc) You probably don't want to end up with a language that implements all ideas that are good in some context. Especially you don't want to have different mechanisms for achieving the same thing.
        FpUser 4y ago
        >"1. it can be always replaced with composition, which Rust already supports" This is no argument from my point of view. Everything can be replaces with simpler things. We are not going back to assembly however except very few cases. "2. it comes with a non-negligible complexity cost to the language (e.g. what if you do multiple inheritance, what code gets called at object construction etc)" Every feature has complexity costs and I prefer to have options here. It should be me who decides what I am willing to trade and what for. >"Especially you don't want to have different mechanisms for achieving the same thing." They're not exactly the same thing and actually this is exactly what I want. I am very averse of super opinionating "my way or highway" type of things. Oh and btw from a glance Rust seems to have different mechanisms for the same thing too, for example with all those option / unwrapping / question mark. The question was asked about "by what authority". Your arguments are just an opinion not any better than mine.
- verdagon 4y ago
  I recommend taking a look at Cone in a little more detail, its type system support for allocators are head and shoulders above what Rust has. The language's awareness of allocator allows it to decouple it from the users code in a way no other language allows (except perhaps Odin).

zozbot234 4y ago

User-specified local allocators are planned for Rust too. Among other things, they're needed for feature parity with C++.

comex 4y ago
Technically it’s only the standard library that lacks custom allocator support. Box and Vec and all the rest are “just” types defined in the standard library, and if you define your own, you can use any allocator you want and still take advantage of the borrow checker and other language features. This has been possible since 1.0. …Well, except for certain magic features that the standard library types get that you can’t (yet) replicate in a custom type. This is an annoying wart, but they’re relatively minor. But yeah, custom allocator support for standard library containers is planned.
FpUser 4y ago
>"feature parity with C++" I think Rust is missing a fair bit more than "user-specified local allocators" to be on feature parity with C++. Curious if it plans to be on full feature parity.
- pkolaczk 4y ago
  It definitely misses some features that are considered bad: e.g implementation inheritance or memory handling by exceptions. Those are not essential for anything and are not planned.
  - FpUser 4y ago
    >" implementation inheritance " What authority declares implementation inheritance bad may I ask? As long as one does not stick it into inappropriate places it is actually very helpful.
    - pkolaczk 4y ago
      1. it can be always replaced with composition, which Rust already supports 2. it comes with a non-negligible complexity cost to the language (e.g. what if you do multiple inheritance, what code gets called at object construction etc) You probably don't want to end up with a language that implements all ideas that are good in some context. Especially you don't want to have different mechanisms for achieving the same thing.
      - FpUser 4y ago
        >"1. it can be always replaced with composition, which Rust already supports" This is no argument from my point of view. Everything can be replaces with simpler things. We are not going back to assembly however except very few cases. "2. it comes with a non-negligible complexity cost to the language (e.g. what if you do multiple inheritance, what code gets called at object construction etc)" Every feature has complexity costs and I prefer to have options here. It should be me who decides what I am willing to trade and what for. >"Especially you don't want to have different mechanisms for achieving the same thing." They're not exactly the same thing and actually this is exactly what I want. I am very averse of super opinionating "my way or highway" type of things. Oh and btw from a glance Rust seems to have different mechanisms for the same thing too, for example with all those option / unwrapping / question mark. The question was asked about "by what authority". Your arguments are just an opinion not any better than mine.
verdagon 4y ago
I recommend taking a look at Cone in a little more detail, its type system support for allocators are head and shoulders above what Rust has. The language's awareness of allocator allows it to decouple it from the users code in a way no other language allows (except perhaps Odin).