Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think there are fair complaints and good ideas in this. But I also think thats a bit hypocritical: They complain that there is a gigantic backlog of features in progress (as in "not in stable yet"), and then goes on to propose a lot of additional, quite fundamental and far reaching featues they'd like to see.

Don't get me wrong: I'd like coroutines and a lot of other unstable/hidden features done as well. Function traits sound great, and I'd also like the whole Pin stuff to be easier (or gone?).

But please, "Lets just extend the borrow checker and fix that" sounds very demeaning. Like no one even tried? I am by far no expert, but I am very sure that its not something you "just" go do.

I like most of the proposed features and improvements, I mostly share the critique on the language, but I do not thing the "why not just fix it?" attitude is helpful or warranted. Theres tons of work, and only so much people & time.



I think the author also underestimates how incredibly difficult these things are to implement. We've seen how hard the async MVP was, and how progressing async support is so very difficult.

There was a good blog post recently on Pin ergonomics, which I hope will lead somewhere good. It's not like they don't know that these things are difficult, and it's not like they're not trying to fix them, but generalised coroutines (for example) in the presence of lifetimes are absolutely monumentally difficult to get right, and they just can't afford to get it wrong. It's not like you can just nick the model from C#'s, because C# has a garbage collector.


> I am by far no expert, but I am very sure that its not something you "just" go do.

As someone who has dabbled in compiler writing (i.e. I may be totally wrong), I believe that from a technical standpoint, modifying the borrow checker as proposed in the article (w.r.t. self-referential structs) is actually something you can "just do". The issues that come up are due to backwards compatibility and such, meaning it cannot be done in Rust without a new Rust edition (or by forking the compiler like in the article).


Before you can "just do" a change to the borrow checker you have to be able to precisely describe how those new behaviours for the borrow checker actually work, how it interacts with the rest of the borrow checker's behaviour and how it doesn't lead to unsoundness problems. Otherwise, you might as well just not have a borrow checker.


Indeed. In the case of self-referential borrows, this is not allowed because Rust wants copying structures byte-for-byte (e.g. `memcpy`) to always be safe.

The solution was `Pin<T>` et. al., which gives a way to make some value immovable in memory.

An equivalent yet simpler version of this system could be integrated into the borrow checker (this was a proposed solution for Rust), but as I said before, it would not be backwards-compatible, hence the need for `Pin`.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: