Hacker News Reader

Comment by CyberRabbi | Hacker News Reader

Seems like a large part of the complexity is enabling the creation and use of reusable UI components that work in a variety of UI hierarchies and modify a variety of backend models (or app states), in a type-safe way. Is that right or are there other problems attempting to be solved?

The simple way to do this is a callback system. Why is that not appropriate for Rust? Does it require custom ownership dynamics that the borrow checker does not support?

View on HN

Callbacks are often isopmorphic to a big ball of mutable state, which Rust makes very painful.

It’s like the classic Joe Armstrong quite about getting the whole jungle when all you wanted is the banana.

You can do it, and if you check out the Gtk/QT bindings you’ll see the boilerplate it introduces. Not insurmountable but many people are interested in figuring out if there’s a better way.

I’m sure I’m being naive, but could this be worked around by passing a mutable reference to the state into the callback rather than it closing over the state? Assuming there’s only one UI thread, then only one callback can run at once anyway…

I think the fundamental problem with that approach is that even in single threaded code rust makes it illegal to have to have two pointers where at least one is mutable to the same state. So I can pass in a `&mut State` pointer, but then I can't also pass in a `&mut AnElementInSomeListInState` pointer. Nor can I really have `AnElementInSomeListInState` just have a parent pointer to the rest of the state, because someone has to have a `&mut State` pointer, and they would conflict (also because doubly linked lists are hard in rust).

The problem is that multiple callbacks might require a reference to the same state, and closing over those references and retaining that callbacks, makes two mutable references to the same state, which Rust makes an illegal pattern. That is indeed safe in single-threaded code, but Rust prevents it nevertheless; there is a famous (in Rust circles) blog post about this: https://manishearth.github.io/blog/2015/05/17/the-problem-wi...

There is a workaround called "internal mutability", an ability to mutate state pointed by a shared pointer. That is syntactically slightly messier, and generally frowned upon. The blog post mentions about this workaround, and also states that it's not ideal so we should strive for better.

> There is a workaround called "internal mutability", an ability to mutate state pointed by a shared pointer. That is syntactically slightly messier, and generally frowned upon.

I don’t see why this would be frowned upon. It seems to be a runtime version of the borrow checker. For sufficiently dynamic code I don’t see how you can get around checking mutability access at runtime (or asserting that multiple blocks of code aren’t concurrently requesting a mutable reference).

As a comparison, there are many cases where the compiler can prove that a bounds check is unnecessary for accessing an element in a vector but there are also many useful cases where it’s simply not possible to do at compile time. It would be silly to frown upon runtime bounds checks when the requested index or the size of the vector is not known at compile time, a common occurrence in many interesting programs.

I get the motivation to make APIs as statically checkable as possible but it doesn’t seem to always be practical. Reusable UI components can be used in a variety of contexts, e.g. situations with multiple callbacks for different backends. The information is just not always there at compile time.

As someone who had literal paid gigs in c++ where I had to remove all sorts of reference counts to reach performance targets, it's depressing that there doesn't seem to be a better way in rust

The way to do this in Rust is to use “unsafe.” It essentially means “trust the programmer that this pointer is live.”

I don’t think there is a way around this. You’re dealing with a high-level runtime condition. There are no tractable ways to get compilers to understand these higher level runtime conditions, so conditions must be reproven at runtime. It needs an oracle. That oracle should be you but you’ve decided that you cannot be trusted. This appears to be somewhat of a contradiction. Should you even be writing this program in the first place?

The reason it's frowned upon is that it makes the code not thread safe. This is fine in application code, but if you are a library author, you generally want your code to be as flexible as possible, and able to be used in various situations. Making the code not thread safe brings upon some limitations how the code can be used by your users. This is why using internal mutation sparingly is the default.

I’m not clear on what you mean it’s not thread safe. Arc<> is thread safe.

Borrow checking gets a lot more complicated with closures that live past their scope. It’s usually much more frustrating than it’s worth.

I think I just ran into this issue about a week ago. I started working on a task manager written in Rust using the Cursive library, which provides like an ncurses TUI. Heavy use of callbacks, but all callbacks require a <'static> lifetime. All the structures I make for information on the database of course don't have <'static> lifetimes. I eventually figured out that cursive has a function where you can kind of give it the data, but to pull the data back out requires a lot of cloning and boiler plate code.

Isn't the standard solution to pass the data within an Rc or Arc? That way, the closure still owns all of its data.

I'll need to play around with that. I just started doing a serious dive into Rust about a month ago.

Tip for you: when the compiler says you need a 'static lifetime, it's actually trying to say that all temporary references are forbidden and won't work. Arc is a reference, but isn't temporary. Add a mutex or atomic when you need to modify data behind arc.

This is the "interior mutability" approach that the article mentions.

This is very useful, so useful that I can't help but think that the compiler actually should say what you said.

I definitely think the error could be improved but I'm not sure it should really say "just shove it in an `Arc<Mutex>`," because that really is only sometimes the right solution and it might lead people to make poor choices by default.

I think a lot of the problem is really with the confusingness of the concept of static lifetime in rust to begin with, where it's kinda used for both "lives forever" and "doesn't reference anything that lives longer than it"[1]. I hope someday these meanings get different names, tbh.

But when you see that error the naive thought is like... "ok better make it live forever" but it really just means you need to make it something that you control, and there are other ways to do that than a refcounting mutex.

[1] https://doc.rust-lang.org/rust-by-example/scope/lifetime/sta...

That's very useful, thanks!

That's very useful, thanks! I need to learn more Rust.

Try raising an issue on GitHub. Rust people are interested in improvements like that. I'm not saying it will be accepted, but it won't be ignored.

Reply on news.ycombinator.com