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

Advice for the next dozen Rust GUIs

raphlinus.github.io

Post reply on HN
Print view View original

261–270 of 279 posts

Re: Advice for the next dozen Rust GUIs

#261

Post by dataangel »

mjevans wrote: post #163
Nadya wrote: post #51

Earlier quoted context omitted.

What's funny is that it pisses off a large number of those 1% of users who swap OSs frequently as well. So it isn't even for the benefit of that 1% either. When operating a Mac I expect Mac-specific behaviors. When operating a Windows PC I expect Windows-specific behaviors. I LOATHE programs that decide to do away with OS-isms that I am accustomed to and require me to learn how to "do things their way" because they w…

Games are the peak of this, since consoles lack anything resembling a filesystem, natural fits for that (like inventory management) tend to differ for every single game... and then they get ported back out to PCs of various flavors with zero adaptation for new peripherals. (Or old ones, as most of those consoles COULD in theory support a keyboard and mouse or touchpad input of some sort too.)

What do you mean by inventory management? Like each item in the characters inventory is a file? There are lots of reasons to not do that.

Re: Advice for the next dozen Rust GUIs

#262

Post by dataangel »

pornel wrote: post #17

The background for this is that most existing UI toolkits are a poor fit for Rust. Rust doesn't like having shared mutable state, but event-based UIs have a global event loop and can mutate anything at any time. Rust works best with strictly tree-shaped data structures, but event handlers turn trees of widgets into arbitrary webs with possibility of circular references. Rust prefers everything thread-safe, but many U…

Rust has no problem expressing things that aren't thread safe. If the UI framework is single threaded all it takes is making its objects neither Send nor Sync, which will likely be taken care of automatically by them having fields that are not.

Re: Advice for the next dozen Rust GUIs

#263

Post by dataangel »

pjmlp wrote: post #260
buildartefact wrote: post #259

Earlier quoted context omitted.

Optimises what away exactly?

The reference counting code that can be proven to be unnecessary, given the execution flow of the code. Rustc doesn't possess such knowledge about library types.

Rust is capable of eliminating unnecessary count increments and decrements for Rc fairly often. The compiler doesn't usually need specific knowledge -- if there is a +1 and then a -1 LLVM is smart enough to cancel that out on its own. I'd actually be curious to see examples where it doesn't.

Re: Advice for the next dozen Rust GUIs

#264

Post by dataangel »

verdagon wrote: post #231
tjoff wrote: post #199

Earlier quoted context omitted.

Or, you use a non-GC language for any application where you care about memory (hint, vast majority of applications fall into this category). GC is imo the single biggest mistake in software engineering.

In a lot of fields, it's more important to have a codebase that's easier to use and more flexible than a codebase that uses less memory. This is why people opt for GC and why it's such a big benefit.

It's way more than just a memory use problem. Garbage collection trashes the CPU cache, and unless you aggressively use value types you have extra layers of indirection everywhere that trash it even more. GC languages have a deserved reputation for worse performance.

Re: Advice for the next dozen Rust GUIs

#265

Post by kaba0 »

tjoff wrote: post #234
kaba0 wrote: post #233

Earlier quoted context omitted.

That’s way too dismissive, and is outright false. First of all, memory architecture is not thrown out the window with a GC, there are plenty of considerations that can be done in managed languages as well. Also, many managed languages have value types, allowing for basically every memory pattern you would use in a low-level language. Second of all, a GC is the superior way of handling many, random-allocations with no…

Of course not, you can have an excellent memory architectures with a GC. My point is that if you do that, well, then you've done the hard parts of living without a GC - so might as well ditch it altogether. But the absolute vast majority of course doesn't have excellent memory architectures, so they'll suffer greatly from not being "burdened" with having to think about memory. It is unfortunate that GC debate is all…

I don’t understand you completely.

Most programs are not video decoders running a tiny tiny code on gigabytes of data, they contain quite a bit of code and many parts of it run irregularly. By not “paying attention” to memory allocations on these vast amount of cases, you get similar, or sometimes even better performance, safer and more correct software, faster. If it turns out to be a critical part, it is very easy to pay a bit more attention to the allocation story there.

So in like 90+% of cases, a GC is a huge boost to productivity, and this is proved by their extensive usage in the industry.

Re: Advice for the next dozen Rust GUIs

#266

Post by ratww »

jakear wrote: post #243
ratww wrote: post #242

Earlier quoted context omitted.

> I don't have access to such corporate software at the moment, but can you verify in devtools where the delay is actually coming from in the apps you mention? I already did. Like I said, that happens when there's zero network activity (the apps are a bit sluggish even with wifi deactivated) but also zero disk activity as well (according to Apple's tools), as caches are warm. Sure, network in the apps I mentioned is…

This post is about moving the GUI layer to Rust, away from the standard HTML/JS/CSS used in the apps you mention. That’s why I brought it up. My claim is that moving to Rust is useless without solving the unnecessary rerenders, and once those are solved moving to Rust would be pointless. So that only real problem is fixing bad coding practices, which has nothing to do with the underlying language. In fact using a low…

Got it. I’m just making it clear that I’m only replying to your question (“Could you give an example of an application where the bottleneck is UI code?”) rather than arguing for language X or Y.

I actually agree with you.

I guess I’m kinda tired of people trying to lure me into arguments I don’t want to have.

Re: Advice for the next dozen Rust GUIs

#267

Post by pohl »

pornel wrote: post #180
pohl wrote: post #36

Earlier quoted context omitted.

Swift is different from Rust, but it's more towards Rust's end of the spectrum. Sure, it has classes, but it's almost as if they're mostly there to aid in compatibility with Objective-C APIs like UIKit. SwiftUI builds UIs with value types and protocols like View. I wonder if something like SwiftUI would work well for Rust.

Swift Rust similarity is only superficial in syntax. Swift has full OOP with inheritance, allows shared mutable state, and doesn't have compile-time thread safety. It has been built for Cocoa interoperability from the start. The clunky `Rc >` that Rust tries to get rid of from UI toolkits in Swift is just `Object`. Rust's undesirable case is the Swift's built-in default (that's not a criticism of Swift, ARC works gre…

Swift is kind of like the two-headed best Orthrus from greek mythology, but where classes & OOP are confined to one head.

You only really need to deal with them when you're interacting with legacy APIs. All of the new APIs use value semantics.

Re: Advice for the next dozen Rust GUIs

#268

Post by pohl »

pohl wrote: post #267
pornel wrote: post #180

Earlier quoted context omitted.

Swift Rust similarity is only superficial in syntax. Swift has full OOP with inheritance, allows shared mutable state, and doesn't have compile-time thread safety. It has been built for Cocoa interoperability from the start. The clunky `Rc >` that Rust tries to get rid of from UI toolkits in Swift is just `Object`. Rust's undesirable case is the Swift's built-in default (that's not a criticism of Swift, ARC works gre…

Swift is kind of like the two-headed best Orthrus from greek mythology, but where classes & OOP are confined to one head. You only really need to deal with them when you're interacting with legacy APIs. All of the new APIs use value semantics.

s/best/beast/

Re: Advice for the next dozen Rust GUIs

#269

Post by tjoff »

kaba0 wrote: post #265
tjoff wrote: post #234

Earlier quoted context omitted.

Of course not, you can have an excellent memory architectures with a GC. My point is that if you do that, well, then you've done the hard parts of living without a GC - so might as well ditch it altogether. But the absolute vast majority of course doesn't have excellent memory architectures, so they'll suffer greatly from not being "burdened" with having to think about memory. It is unfortunate that GC debate is all…

I don’t understand you completely. Most programs are not video decoders running a tiny tiny code on gigabytes of data, they contain quite a bit of code and many parts of it run irregularly. By not “paying attention” to memory allocations on these vast amount of cases, you get similar, or sometimes even better performance, safer and more correct software, faster. If it turns out to be a critical part, it is very easy…

I'd liken it to the Linus quote regarding data-structures https://lwn.net/Articles/193244/

And in what world is a GC safer and more correct? And no, please don't argue that it is faster in any meaningful way.

> So in like 90+% of cases, a GC is a huge boost to productivity, and this is proved by their extensive usage in the industry.

It is not a boost in productivity. And the reason for why it has extensive use in the industry is because the sad state of programming languages have been that languages with GC are safe and high-level whereas languages without a GC are old and unsafe. That really has nothing to do with the GC though. Which is why I say that the GC has been the biggest mistake in software engineering.

Rust and Swift are beginning to change that in a very small way.

Re: Advice for the next dozen Rust GUIs

#270

Post by buildartefact »

pjmlp wrote: post #260
buildartefact wrote: post #259

Earlier quoted context omitted.

Optimises what away exactly?

The reference counting code that can be proven to be unnecessary, given the execution flow of the code. Rustc doesn't possess such knowledge about library types.

I mean, how often are you cloning an Rc? It’s not like c++ where passing a shared_ptr to a function is going to copy it. Most of the time you’re going to move it.
Post reply on HN