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

241–250 of 279 posts

Re: Advice for the next dozen Rust GUIs

#241

Post by msbarnett »

nyanpasu64 wrote: post #238
msbarnett wrote: post #236

Earlier quoted context omitted.

> Are you seriously arguing that C linked lists are just as wrong as Rust ones, by saying a CS student is as likely to write an incorrect C linked list as a hardened professional is to write an incorrect Rust linked list What? No, I’m saying that writing a linked list in C is “easy” if and only if your implementation doesn’t even bother to try to cope with the 9000 foot guns C offers you — that your easy C graph data…

A C data structure is never a disaster of "thread unsafety" if, like most data structures, you don't use it across threads. Any Rust data structure which is Send and Sync, translated literally into C, is just as safe in C to read (or write in the rare cases &Structure is mutable) across threads, and create in one thread and destroy in another. It's only thread-unsafe if used in a thread-unsafe manner (and all Rust ad…

> A C data structure is never a disaster of "thread unsafety" if, like most data structures, you don't use it across threads

lmao. profound stuff man.

> It's not a religion where apostasy is punished by castration.

What on earth are you even talking about. It was just a metaphor for runtime crashes you absolute dingus.

> I'm criticizing Stacked Borrows because I've seen more than enough evidence that it's an unreasonably stringent memory model for writing unsafe code

I didn’t ask! I don’t care! At no point in my life have I cared about anything less than I care about what “nyanpasu64” thinks about Stacked Borrows. Take the hint you tedious dork.

Re: Advice for the next dozen Rust GUIs

#242

Post by ratww »

jakear wrote: post #223
ratww wrote: post #185

Earlier quoted context omitted.

There's plenty of apps that we developers use daily that fall into that. Apps like Teams, Slack and Jira can feel incredibly slow to a lot of people, even with everything already in memory and not waiting for anything from the network or disk. Typing messages, changing tabs, going to read a notification... Facebook sometimes takes a second to show characters you typed in a reply, and the characters often show up out…

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? Leaping to "the stack is bad it needs to be rewritten in rust" is extreme, especially when apps like VS Code are generally regarded as non-slothy [1]. Or at least not more slothy than the domain requires [2]. I'd wager the developers are poorly incentivized - if…

> 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 also incredibly slow (mostly because of lots of requests and redundant data), but the real slow part is the interface itself. Dragging anything, typing text, clicking buttons, popups. Everything takes more time than a native app from 15-20 years ago.

Devtools show it's death by a thousand cuts. Thousands of sub-milisecond javascript functions, thousands of unnecessary re-renders. That happens in almost every operation. Even popup menus take a long time to show up, despite not really doing anything before such as loading data. This is in both Teams and Jira, btw, Slack is not as bad. Interestingly, Teams works faster when opened inside Safari rather than in Electron, but not by much.

> Leaping to "the stack is bad it needs to be rewritten in rust" is extreme

Thankfully I said nothing of the sort... You mention Rust a couple times more, so I guess this is something of a pet peeve to you, which I'll ignore since it has nothing to with my message. I was only answering to your query, I'm not interested in making arguments because I have no dog in this race. Like I said, other apps (even those written in the web platform) are faster than the examples I gave.

> I'd wager the developers are poorly incentivized - if something satisfies the ticket and looks fast enough on their tiny test bed with state of the art hardware and great network (perhaps even localhost), it ships.

In this case it's also not about being fast on localhost or having 100x more data, although this is definitely a safe bet on most products. It's slow even on the base case, even without doing anything remote, or having almost no data.

If you want me to wager on why this happens: developers work in a way they can retain their sanity. If there's weekly changes of scope, they'll program defensively in a way that allow quick changes. So there's no room for macro performance optimisations. The architecture is optimized for change, not performance. I know there are weekly stupid changes in Jira/Teams because I see bugs and little test features coming and going every single fucking week, frequently disrupting my workflow. VSCode on the other hand is a developer tool, and performance and familiarity seems to take precedence over quick stupid features. Why? VSCode is a dev tool, so developers indeed know better. In normal products developers are unable to fight back the asshole product manager or product owner changing their mind every other week.

Re: Advice for the next dozen Rust GUIs

#243

Post by jakear »

ratww wrote: post #242
jakear wrote: post #223

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? Leaping to "the stack is bad it needs to be rewritten in rust" is extreme, especially when apps like VS Code are generally regarded as non-slothy [1]. Or at least not more slothy than the domain requires [2]. I'd wager the developers are poorly incentivized - if…

> 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 lower level language is likely to make that much more difficult.

Re: Advice for the next dozen Rust GUIs

#244

Post by worik »

pohl wrote: post #36
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…

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.

What about Flutter?

Re: Advice for the next dozen Rust GUIs

#245

Post by worik »

tjoff wrote: post #235
verdagon wrote: post #231

Earlier quoted context omitted.

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.

I'm not really talking about memory requirements. And I don't see how a GC would make any difference in terms of ease of use or flexibility of a codebase. It is a mindset about memory, but you have to have a mindset about memory anyway so it isn't exactly unique.

It is important to have a code base that an inexperienced programmer can work on.

Keeping track of memory is one of the hardest parts of programming in languages like C, a bit easier in C++ (thanks RAII) but still memory leaks are rampant.

Rust improves in some aspects, but I do not think it is a language for inexperienced programmers.

So where garbage collection pauses are tolerable, and real time performance not an issue, save the money and use garbage collection.

I too hate garbage collectors, I want to be in control. But the business case is clear: garbage collected languages are a better choice in a lot, f not most, cases.

Re: Advice for the next dozen Rust GUIs

#246

Post by worik »

kaba0 wrote: post #224
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.

GC is the only measurable, significant productivity improvement in software development since high-level languages.

That is not true

* IDEs that know the language and catch syntax errors.

* Deprecating NULL. (Early days yet, but I am a believer)

* IDEs (again) and syntax highlighting.

* RAII (is that "since high-level languages"? I think so)

* Abstract interfaces.

Re: Advice for the next dozen Rust GUIs

#247

Post by worik »

stu2b50 wrote: post #116
epage wrote: post #82

Earlier quoted context omitted.

I'm glad Rust* is forcing us out of a rut in UI toolkit design. All of these spell hard-to-debug problems. * Yes, I know elm-derive UIs are also a thing and have laid a lot of ground work in this area. btw I've had great experience 10 or so years ago doing composition-based UI design in GTK with Python. When Maemo switched from GTK to Qt, the requirements on inheritance were one of my points of frustration and I got…

I wouldn't give Rust or Elm the credit for that, though. Although it was not first, React is really what put the declarative method for UI programming on the map. Today, there's a solid argument that by usage numbers React is the most used UI framework today, and it's children like Vue are high up there too. Swift also has a similar problem and unlike Rust has a powerful backer, so SwiftUI is in many ways already a v…

Swift is in a niche (I hope). Only useful in Apple's walled garden.

I recently spend two years with Swift: It is partly modern, but is slow, obtuse, opaque, and frustratingly archaic in places (its threading model is just awful).

Rust is hard, but is is beautiful, and it is mush more modern than Swift. Rust has an actual community (Swift has acres of astroturf). Rust does not wrap everything in a reference counted object.

If you are programming for iOS then Swift might be a good choice (but since it is not portable, you will regret it if you have success and want to port it - that is the voice of experience). For any other purpose avoid Swift. It has no reason to exist, we should let it go down with Apple wherever Apple is taking itself.

Re: Advice for the next dozen Rust GUIs

#248

Post by worik »

pjmlp wrote: post #194
stu2b50 wrote: post #116

Earlier quoted context omitted.

I wouldn't give Rust or Elm the credit for that, though. Although it was not first, React is really what put the declarative method for UI programming on the map. Today, there's a solid argument that by usage numbers React is the most used UI framework today, and it's children like Vue are high up there too. Swift also has a similar problem and unlike Rust has a powerful backer, so SwiftUI is in many ways already a v…

Except the borrow checker hinders the possibility to have components libraries, or a visual designer, unless it is RC all over the place.

Are you afraid of RC?

Everything in Swift is RC, but opaquely.

Re: Advice for the next dozen Rust GUIs

#249

Post by tene »

iovrthoughtthis wrote: post #161
verdagon wrote: post #125

Earlier quoted context omitted.

I suspect the mismatch is actually due to the borrow checker's inability to do various common abstractions such as delegates and observers. These patterns are quite useful, especially in stateful situations such as GUI. They help decouple observer from observable, and can give an architecture more flexibility in a lot of ways. Alas, the borrow checker isn't very amenable to that sort of style.

yup. we need to find a way to manage multiple owned borrows safely

We already have a way, reference counting and locking, the same way it's handled in most dynlangs.

Re: Advice for the next dozen Rust GUIs

#250

Post by jollybean »

kaba0 wrote: post #172
armchairhacker wrote: post #101

Earlier quoted context omitted.

yes there’s absolutely no need for UI to be multi-threaded. You can do stuff in the background but IMO multi-threaded UI is completely useless. You have an event loop where you poll for input => propagate changes => commit changes => rerender UI. Normally you might have poll => propagate => rerender, but when you delay the changes you can represent everything in a shared reference, and when commit them you have a sin…

Not really UI, but wasn’t one recentish game really performant due to it using Vulkan, but in a multi-threaded way? Not sure whether it would benefit traditional UIs though.

I think when you get to rending and composting, the multithread issue gets a little bit different and possible to distribute a bit.

It's at the 'Model Tree' layer that the UI dev 'interacts with' directly that single thread is often enforced.

Multithread seems to only be reasonably possible when you have 'control' of everything and a careful approach, and when the situation calls for it.

Post reply on HN