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

251–260 of 279 posts

Re: Advice for the next dozen Rust GUIs

#251

Post by tene »

worik wrote: post #245
tjoff wrote: post #235

Earlier quoted context omitted.

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…

For most people working a career as a programmer, how much of their time in that career is going to be spent as an inexperienced beginner programmer?

I agree that Rust is a professional tool, designed for professional use. It's designed for professional use, instead of being optimized for inexperienced beginners like Python is.

I just don't really see "inexperienced beginners can easily contribute productively to this code base" as something that would have been valuable for any of the professional work I've done over the past couple of decades of my career.

If you're an amateur, or if you're programming recreationally, or if you're writing some low-reliability low-impact throwaway code, sure, it's great to use happy-path-oriented languages. When you want to write something that people actually rely on to run a business, you should use professional-grade tools instead.

Re: Advice for the next dozen Rust GUIs

#252

Post by verdagon »

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.

In a language like Rust, one has to carefully orchestrate the dance between Ship, &mut Ship, and &Ship... and Rc and RefCell and Cell and Rc> and Box. In the kind of programming most people do, that is harder than GC which doesn't have any of those distinctions. It's all just Ship.

If that isn't hard to you, it's probably because you've gotten so used to that mental overhead that you don't notice the drag any more, or because it's worth it for your case so you don't feel it. More power to you, but the rest of programmers don't want to have to deal with that, and don't need to. They'd rather get the feature done and go home to their families.

Re: Advice for the next dozen Rust GUIs

#253

Post by anon291 »

Const-me wrote: post #226
anon291 wrote: post #145

Earlier quoted context omitted.

> though I can't even fathom what that might be. One of the reasons why is that the notion of a GUI is ill-specified. Most ui frameworks, including the excellent ones, like QT, have corner cases where they fail. It's just that we've gotten to the point where coders kind have it in their bag of tricks to avoid these situations by defensive programming. Until we have a proper model of graphical UI, it'll be hard to mak…

We do not have such a flawless model for CLIs. Command-line apps have their corner cases as well, and they fail too. Many CLI programs were designed in the assumption the display size never changes, like 80x25 characters. That's not true anymore, users resize their windows, the text in the terminal may or may not stay good after that. Terminals have a GUI state: cursor position, and current text attributes. That stat…

> Terminals have a GUI state: cursor position, and current text attributes. That state may cause issues, especially when a program quits suddenly, like a crash.

I have never in my life witness a terminal crash so hard that I couldn't fix it and get back all my other state. In 100% of cases, just typing Ctrl+C, Ctrl+Z, etc, followed by 'r', 'e', 's', 'e', 't', enter seems to have always done the trick.

Re: Advice for the next dozen Rust GUIs

#254

Post by Const-me »

anon291 wrote: post #253
Const-me wrote: post #226

Earlier quoted context omitted.

We do not have such a flawless model for CLIs. Command-line apps have their corner cases as well, and they fail too. Many CLI programs were designed in the assumption the display size never changes, like 80x25 characters. That's not true anymore, users resize their windows, the text in the terminal may or may not stay good after that. Terminals have a GUI state: cursor position, and current text attributes. That stat…

> Terminals have a GUI state: cursor position, and current text attributes. That state may cause issues, especially when a program quits suddenly, like a crash. I have never in my life witness a terminal crash so hard that I couldn't fix it and get back all my other state. In 100% of cases, just typing Ctrl+C, Ctrl+Z, etc, followed by 'r', 'e', 's', 'e', 't', enter seems to have always done the trick.

> In 100% of cases, just typing Ctrl+C, Ctrl+Z, etc, followed by 'r', 'e', 's', 'e', 't', enter seems to have always done the trick.

Can confirm, these things helped me as well.

Still, just because there's an easy workaround doesn't cancel the fact the observed behavior is a weird UI bug.

Otherwise, one could argue web apps don't have weird bugs because there's F5=Refresh key which fixes 99% of them.

Re: Advice for the next dozen Rust GUIs

#255

Post by pjmlp »

worik wrote: post #248
pjmlp wrote: post #194

Earlier quoted context omitted.

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.

With the small difference that Swift compiler is RC aware and optimizes them away, unlike Rust, first point.

Second point, exactly because it is opaque, its ergonomics are way better than Rust code.

No Rc, Arc, RefCell, clone(), Pin, pollution across the source code.

Re: Advice for the next dozen Rust GUIs

#256

Post by tjoff »

verdagon wrote: post #252
tjoff wrote: post #235

Earlier quoted context omitted.

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.

In a language like Rust, one has to carefully orchestrate the dance between Ship, &mut Ship, and &Ship... and Rc and RefCell and Cell and Rc > and Box . In the kind of programming most people do, that is harder than GC which doesn't have any of those distinctions. It's all just Ship. If that isn't hard to you, it's probably because you've gotten so used to that mental overhead that you don't notice the drag any more,…

The point is that the mental overhead with memory must always be there. Why not let the language guide you?

Sure, they'll get the feature "done". And then they'll suffer for it later, adding up to much more work and a much less rewarding code base than if they'll done it properly in the first place.

Re: Advice for the next dozen Rust GUIs

#257

Post by zigzag312 »

Nadya wrote: post #51
wmf wrote: post #45

Earlier quoted context omitted.

I think it's more a desire for branded UI rather than Web apps. Adobe wants their UIs to be instantly identifiable as Adobe, Slack wants to be instantly identifiable as Slack, MS Office as you said, etc. Personally, I doubt this benefits users (do you really need to market to people who already bought your product?) but I'm sure the logic is compelling to decision makers and it's cheaper to "design once, run everywhe…

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…

Could you give an example which inconsistencies are the most offending to you?

I agree that some platform specific behavior is important. But only behavior that relates to OS, like window management, system dialogs, accessibility etc.

IMHO we are focusing too much on what does and doesn't look like platform UI. Big part of native widgets is also about branded UI. Arguing weather Apple or Adobe is more important brand for the UI is kind of pointless.

Consistent UI across multiple platforms affects more than just people who are using multiple OSes. For example, user watching a tutorial, expects to be able to replicate instructors actions. Imagine the joy of discovering in-app menus on his machine are different, because instructor was using the app on a different OS. Also, greater cost of designing and developing widgets for different platforms means there is less budget left to design custom task-specific UIs with better UX.

For UI "inside" the app, we should be focusing on what is a best possible UX of human-computer interaction for a task at hand. Just blindly using native widgets for everything can actually lead to bad user experience. For example, I hate it when an app uses Win32 Color Dialog for color selection. It's a widget with a bad UX for 99% of use cases.

To me, as a user, UI with good human-computer interaction experience is much more important that use of branded platform-native widgets.

Re: Advice for the next dozen Rust GUIs

#259

Post by buildartefact »

pjmlp wrote: post #255
worik wrote: post #248

Earlier quoted context omitted.

Are you afraid of RC? Everything in Swift is RC, but opaquely.

With the small difference that Swift compiler is RC aware and optimizes them away, unlike Rust, first point. Second point, exactly because it is opaque, its ergonomics are way better than Rust code. No Rc, Arc, RefCell, clone(), Pin, pollution across the source code.

Optimises what away exactly?

Re: Advice for the next dozen Rust GUIs

#260

Post by pjmlp »

buildartefact wrote: post #259
pjmlp wrote: post #255

Earlier quoted context omitted.

With the small difference that Swift compiler is RC aware and optimizes them away, unlike Rust, first point. Second point, exactly because it is opaque, its ergonomics are way better than Rust code. No Rc, Arc, RefCell, clone(), Pin, pollution across the source code.

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.

Post reply on HN