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

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

verdagon.dev

Post reply on HN
Print view View original

31–40 of 143 posts

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

#31

Post by f1shy »

amelius wrote: post #27

I like many of the ideas of Rust, but I still think it is an unsuitable language for most projects. The problem is that it is very easy to write non-GC'd code in a GC'd language, but the other way around it is much much harder. Therefore, I think the fundamental choice of Rust to not support a GC is wrong.

Yet another PoV: for some things with critical timing or so, GC might be a problem. But most of the time, it isn’t. The performance/predictability topic could also be reviewed…

I was talking with a colleague about that, he said “in C I know exactly where things are when” And I replied that under any OS with virtual memory, you have basically no clue where are things at any time, in the N levels of cache, and you cannot do accurate time predictions anyway… [1]

I’m convinced today GC is the way to go for almost all. And I was until 5 years ago or so, totally opposed to that view.

[1] https://news.ycombinator.com/item?id=42456310

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

#32

Post by dgan »

willvarfar wrote: post #7

Meta comment, but I really like the formatting of the blog post! It reminds me of the early days of the web, when text was king and content was king. I particularly like the sidenotes in the margins approach. (Hope the author sees this comment :) Hats off)

I am sorry, I am maybe dumb but i can't see the 14 techniques been listed anywhere? Where do i even click?

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

#33

Post by 3836293648 »

amelius wrote: post #27

I like many of the ideas of Rust, but I still think it is an unsuitable language for most projects. The problem is that it is very easy to write non-GC'd code in a GC'd language, but the other way around it is much much harder. Therefore, I think the fundamental choice of Rust to not support a GC is wrong.

You've got this one wrong. Rust is designed for a specific use case. Most projects are not that use case. Therefore the choice to use Rust is wrong.

If GC is an option and you want all the nice parts of Rust, use OCaml

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

#34

Post by hawski »

dgan wrote: post #32
willvarfar wrote: post #7

Meta comment, but I really like the formatting of the blog post! It reminds me of the early days of the web, when text was king and content was king. I particularly like the sidenotes in the margins approach. (Hope the author sees this comment :) Hats off)

I am sorry, I am maybe dumb but i can't see the 14 techniques been listed anywhere? Where do i even click?

You need to read the post.

> Wait a minute, this list goes to 17, yet the intro only mentions 14! I actually did that because a couple might overlap and a couple of them are half-approaches, and that last one is just here for fun. Besides, as I learn more approaches and add them to the list, the title will get more and more out of date anyway.

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

#35

Post by in-pursuit »

3836293648 wrote: post #33
amelius wrote: post #27

I like many of the ideas of Rust, but I still think it is an unsuitable language for most projects. The problem is that it is very easy to write non-GC'd code in a GC'd language, but the other way around it is much much harder. Therefore, I think the fundamental choice of Rust to not support a GC is wrong.

You've got this one wrong. Rust is designed for a specific use case. Most projects are not that use case. Therefore the choice to use Rust is wrong. If GC is an option and you want all the nice parts of Rust, use OCaml

I think OPs general point, although maybe not what they stated is correct: it’s easy to write GC’d code. It’s “easy” to write code with manual memory management. It’s “easy” to write RC code. But it’s hard to write borrow checker code. And that will probably limit adoption, even though the goals of Rust are good.

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

#36

Post by FridgeSeal »

amelius wrote: post #30
FridgeSeal wrote: post #29

Earlier quoted context omitted.

It does have a GC. It just runs at compile time. Bonus feature, it helpfully prevents a number of common bugs too.

GC is short for automatic GC. If you have to do it yourself, then it does not "have" a GC.

Ssshhh you’re ruining my silly and “hasn’t gone over terribly well” joke.

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

#37

Post by pjmlp »

f1shy wrote: post #31
amelius wrote: post #27

I like many of the ideas of Rust, but I still think it is an unsuitable language for most projects. The problem is that it is very easy to write non-GC'd code in a GC'd language, but the other way around it is much much harder. Therefore, I think the fundamental choice of Rust to not support a GC is wrong.

Yet another PoV: for some things with critical timing or so, GC might be a problem. But most of the time, it isn’t. The performance/predictability topic could also be reviewed… I was talking with a colleague about that, he said “in C I know exactly where things are when” And I replied that under any OS with virtual memory, you have basically no clue where are things at any time, in the N levels of cache, and you cann…

Even with critical timing, real time GCs exist for decades now, PTC and Aicas are two surviving companies selling software tooling for embedded markets, including their own JVM implementations, with AOT compilers, bare metal deployments and real time GC.

Many of their customers are factory processes and military deployments with weapons control, two scenarios where any kind of stall might produce deadly results.

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

#38

Post by PeterWhittaker »

DanielHB wrote: post #20

I am not experienced with rust and borrow checkers, but my impression is that borrow checkers also statically ensures thread/async safety while most other memory safety systems don't. Is this accurate?

The first part - that the Rust borrow checker and overall memory model ensures thread/async safety - is true. I cannot speak to the second part - that other systems don't have this assurance.

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

#39

Post by pjmlp »

3836293648 wrote: post #33
amelius wrote: post #27

I like many of the ideas of Rust, but I still think it is an unsuitable language for most projects. The problem is that it is very easy to write non-GC'd code in a GC'd language, but the other way around it is much much harder. Therefore, I think the fundamental choice of Rust to not support a GC is wrong.

You've got this one wrong. Rust is designed for a specific use case. Most projects are not that use case. Therefore the choice to use Rust is wrong. If GC is an option and you want all the nice parts of Rust, use OCaml

If Go designers weren't so much anti-modern language design, in many scenarios where people are rushing to do RIIR, they would be better served with Go, if those modern features were part of the language.

Having said that, there are still OCaml (as you noted), Haskell, .NET languages with Native AOT, JVM languages with GraalVM/OpenJ9, D, Nim, Swift, ....

And if one wants to get fancy with type systems, Idris, Dafny, FStar,..

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

#40

Post by naasking »

More people need to read up on C#'s ref's:

https://em-tg.github.io/csborrow/

These kinda-sorta fall under borrow checking or regions, just without any annotations. Then again, Ada/Spark's strategy also technically falls under Tofte-Talpin regions:

https://www.cs.cornell.edu/people/fluet/research/substruct-r...

Post reply on HN