Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches • Hacker News Board

Re: Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches

#141

Post by mpweiher » Mon, Dec 23, 2024, 12:28 AM UTC

pornel wrote: post #26

andrewstuart wrote: post #2

I’d love to see a language that kept everything as familiar as possible and implement memory safety as “the hard bit”, instead of the Rust approach of cooking in multiple different new sub languages and concepts.

Safety is not an extra feature a'la carte. These concepts are all inter-connected: Safety requires unions to be safe, so unions have to become tagged enums. To have tagged enums usable, you have to have pattern matching, otherwise you'd get something awkward like C++ std::variant. Borrow checking works only on borrowed values (as the name suggests), so you will need something else for long-lived/non-lexical storage.…

Hm...Smalltalk is also safe.

So there are obviously different ways of addressing this.

Re: Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches

#142

Post by pornel » Mon, Dec 23, 2024, 12:07 PM UTC

mpweiher wrote: post #141

pornel wrote: post #26

Earlier quoted context omitted.

Safety is not an extra feature a'la carte. These concepts are all inter-connected: Safety requires unions to be safe, so unions have to become tagged enums. To have tagged enums usable, you have to have pattern matching, otherwise you'd get something awkward like C++ std::variant. Borrow checking works only on borrowed values (as the name suggests), so you will need something else for long-lived/non-lexical storage.…

Hm...Smalltalk is also safe. So there are obviously different ways of addressing this.

Bash is also memory-safe.

Almost every programming language is memory-safe, but Smalltalk and most high-level dynamically typed languages require a fat runtime, and have a much higher overhead than C or Rust.

For languages that can be credible C and C++ competitors, the design space is much smaller.

Re: Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches

#143

Post by mpweiher » Wed, Dec 25, 2024, 9:02 AM UTC

pornel wrote: post #142

mpweiher wrote: post #141

Earlier quoted context omitted.

Hm...Smalltalk is also safe. So there are obviously different ways of addressing this.

Bash is also memory-safe. Almost every programming language is memory-safe, but Smalltalk and most high-level dynamically typed languages require a fat runtime, and have a much higher overhead than C or Rust. For languages that can be credible C and C++ competitors, the design space is much smaller.

The id-subset[1] of Objective-C is also memory safe, just like the Smalltalk it copied.

And Objective-C is a credible C competitor, partly because it is a true superset of C, partly because you can get it to any performance level you want (frequently faster than equivalent practical C code [2]) and it was even used in the OS kernel in NeXTStep.

Now obviously it's not done, as it is a true superset and thus inherits all of C's non-safety, and if you were to just use the id-subset that is memory safe, you wouldn't be fully competitive.

However, it does show a fairly clear path forward: restrict the C part of Objective-C so that it remains safe, let all the tricky parts that would otherwise cause non-safety be handled by the id-subset.

That is the approach I am taking with the procedural part of Objective-S[3]: let the procedural part be like Smalltalk, with type-declarations allowing you to optimize that away to something like Pascal or Oberon. Use reference counting to keep references safe, but potentially leaky in the face of cycles. Optional lifetime annotations such as weak can be used to eliminate those leaks and to eliminate reference counting operations. Just like optional type declarations can reduce boxing and dynamic dispatch.

[1] https://blog.metaobject.com/2014/05/the-spidy-subset-or-avoi...

[2] https://www.amazon.com/gp/product/0321842847/ref=as_li_tl?ie...

[3] https://objective.st/