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

macOS Apps in Rust

github.com

Post reply on HN
Print view View original

71–80 of 89 posts

Re: macOS Apps in Rust

#71

Post by olliej »

amelius wrote: post #27
olliej wrote: post #20

Earlier quoted context omitted.

You can't write good UI apps with cross platform code. The basic idioms of each platform are different. You can write your core application logic once and share it, but you need to have the interaction with the actual UI/window manager be per-platform. The reason electron apps are so bad on Mac is not that the core application logic is bad, it's that a whole bunch of basic Mac platform behaviors are broken. "modern"…

Can you give an example of something can only be done in a native app? And why wouldn't a hybrid approach work? I.e. the majority of the code using the cross platform toolkit, and a small amount of code per platform using the native API.

First off, I was not talking about native vs non-native, I was talking about toolkits. native vs non-native is a different though related problem.

> And why wouldn't a hybrid approach work? I.e. the majority of the code using the cross platform toolkit, and a small amount of code per platform using the native API.

I literally said you could/should do that?

Answering your actual question though. The issue is not "something can only be done" in X, it's a "is your app consistent with the platform it is on". And that's where "cross platform" apps are invariably annoying - none of the electron apps correctly do find on the Mac (this is largely because chrome/blink intentionally removed the correct logic from webkit and as these apps just do whatever blink does that's what we get).

The problem is that cross platform toolkits (Qt, Wx, etc) primarily target windows so all the behaviors are geared to that platform. It is very obvious whenever you are using a Mac app that is written using a cross platform toolkit, as their are just many different little ways that things behave incorrectly - a death by a thousand cuts problem.

Electron is just a special case of this: because your "app" is just a web page you don't have an actual ui toolkit, cross platform or otherwise, to handle all the usual UI behavior and have to reimplement it all yourself. That's a lot of work and very hard to get right, so generally electron apps don't even attempt to, but they're "popular" because there's literally no choice. People on Mac use discord, slack, teams, etc because there is no option - if your employer decides they're using slack or teams, that's what you have to use. The fact that the UI is janky, the cpu is high, basic key commands don't work, it doesn't handle drag and drop correctly, etc is not relevant: it's what you have to use.

Re: macOS Apps in Rust

#72

Post by Ygg2 »

riceart wrote: post #55
unstrategic wrote: post #43

Earlier quoted context omitted.

> Rust isn't some silver bullet Rust codebases extend in size and scale to larger teams fundamentally better than C++ / C. Rust offers more leverage in building ambitious system software. Since you mention Qt, imagine writing all of Qt in x86 assembly, vs. C++. "There's not particular reason this isn't doable." C++ to Rust is a similar jump. No silver bullets; just leverage. Cross-platform toolkits — especially those…

> Qt was about the best we could do in the C++ era, but a new era has dawned. Based on the way the Rust community has been spinning its wheels for years in getting something even within a light year of feature parity with Qt, if a new era has truly dawned you might need to wait for the next one. > Rust codebases extend in size and scale to larger teams fundamentally better than C++ / C. Rust offers more leverage in b…

> getting something even within a light year of feature parity with Qt.

Qt is also old as Jesus, and making a cross OS GUI is extremely hard.

And you can non-ironically say the same about non-Qt toolkit written in C++.

What grandparent probably means something that leverages parallelism and/or GPU acceleration.

Re: macOS Apps in Rust

#73

Post by lost_tourist »

olliej wrote: post #20
apatheticonion wrote: post #4

Pretty cool project, seems like it's becoming more realistic to write cross platform native desktop applications with OS-specific GUIs in Rust. It's not too far from the write-once-run-everywhere philosophy of React native, Electron and similar. One could write their UI state and application logic once while maintaining 3 entry points using the various platform GUI bindings (gtk-rs, cacao, win32?) to represent the UI…

You can't write good UI apps with cross platform code. The basic idioms of each platform are different. You can write your core application logic once and share it, but you need to have the interaction with the actual UI/window manager be per-platform. The reason electron apps are so bad on Mac is not that the core application logic is bad, it's that a whole bunch of basic Mac platform behaviors are broken. "modern"…

You can write "good enough" ones though, and I've been doing it for years.

Re: macOS Apps in Rust

#74

Post by riceart »

Ygg2 wrote: post #72
riceart wrote: post #55

Earlier quoted context omitted.

> Qt was about the best we could do in the C++ era, but a new era has dawned. Based on the way the Rust community has been spinning its wheels for years in getting something even within a light year of feature parity with Qt, if a new era has truly dawned you might need to wait for the next one. > Rust codebases extend in size and scale to larger teams fundamentally better than C++ / C. Rust offers more leverage in b…

> getting something even within a light year of feature parity with Qt. Qt is also old as Jesus, and making a cross OS GUI is extremely hard. And you can non-ironically say the same about non-Qt toolkit written in C++. What grandparent probably means something that leverages parallelism and/or GPU acceleration.

> And you can non-ironically say the same about non-Qt toolkit written in C++.

Maybe. Gtk and its related libraries don’t cover everything Qt does, but they’re not small either. It’s also fair to include the native toolkits themselves on their respective platforms that are written in a mixture of C++/C/Objective C.

I also will point out that one of the cross platform toolkits with some traction in the Rust world is amusingly fltk.

> What grandparent probably means something that leverages parallelism and/or GPU acceleration.

You mean like QtQuick/QML, skia (basically this is the effective underpinning of electron and flutter) or Dear Imgui, etc. There are a handful of widely used GPU based GUI libraries. The above examples are all C++.

> leverages parallelism

The memory model of Rust is still whatever C++ does. I get that Rust has some nice features and C++ makes it easy to fuck your self but people have been doing large scale parallel software development for years in C++.

> Qt is also old as Jesus, and making a cross OS GUI is extremely hard.

The claim was we are in a new era of “leverage” that will make the hard very easy (that’s what it sounded like at least). I found the claim at best vague and low on specifics or evidence - hence the mention of RESF.

Re: macOS Apps in Rust

#75

Post by smoldesu »

obrhoff wrote: post #57
tcfhgj wrote: post #30

Earlier quoted context omitted.

afaik not a problem with apps written in something like react native which use platform specific widgets and common business logic.

It actually is. Fortunately, the quality of apps dropped significantly, allowing these technologies to compete.

To the contrary. Developing native apps is so painful that the average S&P500 company will treat it like a root canal. Given how meaningless native functionality is to them, they won't hesitate at the opportunity to serve you a shitty Electron app. Many of them are only successful because they didn't waste time writing native apps for each platform.

Re: macOS Apps in Rust

#76

Post by pjmlp »

xanathar wrote: post #58
pjmlp wrote: post #51

Earlier quoted context omitted.

Automatic Reference Counting. Writing by hand isn't the same.

Except that even Apple's ARC is not automatic - try passing the pointer to a GArray, or putting it on a malloc'ed linked list or any other data structure not implemented in Swift or ObjectiveC (provided that you compile objectiveC with the correct build flags). The point is: you can't leak, you can't end up keeping a reference without incrementing the refcount and you don't events have to worry about any of the refco…

Moving goalposts.

We are speaking about the normal development experience, not corner cases or unsafe code.

Re: macOS Apps in Rust

#77

Post by WastingMyTime89 »

duped wrote: post #50
kitsunesoba wrote: post #48

Earlier quoted context omitted.

From the bits of Rust code I've seen, it seems like while memory management isn't exactly manual, it needs to be given a fair amount of thought, what with borrow semantics and such. When writing Swift I very infrequently have to give it any thought at all, beyond avoiding retain cycles (which is usually as simple as using weak references to self in closures).

There's no obligation to pass everything in references. You can wrap most things in Box/Rc/Arc and move on with your life.

But why bother using Rust then?

If you are going to use it like a garbage collected language, you would be better served by one of the slew of other languages with the same features but which are easier to use. The memory management is what sets Rust apart.

Re: macOS Apps in Rust

#78

Post by pjmlp »

unstrategic wrote: post #43
riceart wrote: post #14

Earlier quoted context omitted.

> Something that isn't talked about much in the GUI world (outside of mobile development) is how essential multi-threading is to a great application experience. Yes it is. Heavyweight desktop GUI applications like DAWs or CAD or image/video editing are old established technology. > This has the advantage of a project feeling natural to the platform while still allowing for code reuse between platforms Having written…

> Rust isn't some silver bullet Rust codebases extend in size and scale to larger teams fundamentally better than C++ / C. Rust offers more leverage in building ambitious system software. Since you mention Qt, imagine writing all of Qt in x86 assembly, vs. C++. "There's not particular reason this isn't doable." C++ to Rust is a similar jump. No silver bullets; just leverage. Cross-platform toolkits — especially those…

> Qt was about the best we could do in the C++ era, but a new era has dawned.

Nope, the best is C++ Builder with VCL, Visual Basic/Delphi like experience with C++.

However very few have tried it out unless they work for big corporations.

Re: macOS Apps in Rust

#79

Post by Ygg2 »

riceart wrote: post #74
Ygg2 wrote: post #72

Earlier quoted context omitted.

> getting something even within a light year of feature parity with Qt. Qt is also old as Jesus, and making a cross OS GUI is extremely hard. And you can non-ironically say the same about non-Qt toolkit written in C++. What grandparent probably means something that leverages parallelism and/or GPU acceleration.

> And you can non-ironically say the same about non-Qt toolkit written in C++. Maybe. Gtk and its related libraries don’t cover everything Qt does, but they’re not small either. It’s also fair to include the native toolkits themselves on their respective platforms that are written in a mixture of C++/C/Objective C. I also will point out that one of the cross platform toolkits with some traction in the Rust world is a…

> Maybe. Gtk and its related libraries don’t cover everything Qt does

And therein lies the problem. Qt is semi-open (the parent company tried to close source it[1]). If a commercial company has no interest in maintaining it, there is even less hope for other open source approaches.

Best cross OS system are almost always backed by a commercial supporter. See Skia - Google, Java Swing - Oracle, Qt - QtCompany, etc.

OSS offerings were always runner ups (e.g. Gtk - Gnome).

> The memory model of Rust is still whatever C++ does. I get that Rust has some nice features and C++ makes it easy to fuck your self but people have been doing large scale parallel software development for years in C++.

Memory model of Rust is undefined[2]. It might be anything Rust does to accomodate C++ bindings, but I don't think they really settled on one.

I'd like to add - people have been doing large scale parallel software development for years in C++, in spite of C++. What is a line of comment in C++ in Rust is a type system constraint.

It's a difference between having a seatbelt (Rust) and holding a piece of seatbelt (C++).

Rust was literally made to address C++ shortcomings when it comes to parallelism.

> You mean like QtQuick/QML, skia (basically this is the effective underpinning of electron and flutter) or Dear Imgui, etc. There are a handful of widely used GPU based GUI libraries. The above examples are all C++.

No. I mean like WebRenderer[3], Lyon[4]. Most things should be parallelized and done on GPU/SIMD. Layout, font shaping, etc.

[1]https://news.ycombinator.com/item?id=25656932

[2]https://doc.rust-lang.org/reference/memory-model.html

[3]https://github.com/servo/webrender

[4]https://docs.rs/lyon/latest/lyon/

Re: macOS Apps in Rust

#80

Post by riceart »

Ygg2 wrote: post #79
riceart wrote: post #74

Earlier quoted context omitted.

> And you can non-ironically say the same about non-Qt toolkit written in C++. Maybe. Gtk and its related libraries don’t cover everything Qt does, but they’re not small either. It’s also fair to include the native toolkits themselves on their respective platforms that are written in a mixture of C++/C/Objective C. I also will point out that one of the cross platform toolkits with some traction in the Rust world is a…

> Maybe. Gtk and its related libraries don’t cover everything Qt does And therein lies the problem. Qt is semi-open (the parent company tried to close source it[1]). If a commercial company has no interest in maintaining it, there is even less hope for other open source approaches. Best cross OS system are almost always backed by a commercial supporter. See Skia - Google, Java Swing - Oracle, Qt - QtCompany, etc. OSS…

> No. I mean like WebRenderer[3], Lyon[4]. Most things should be parallelized and done on GPU/SIMD. Layout, font shaping, etc.

https://www.reddit.com/r/rust/comments/vwdxim/announcing_lyo...

https://www.reddit.com/r/rust/comments/vwdxim/announcing_lyo...

Also neither of your examples do any text shaping on the GPU. Lyon doesn’t do text and Webrender (which depends on freetype) does regular old glyph cache built in CPU texture rendering. Neither involve GPU shaping.

https://github.com/servo/webrender/blob/master/wr_glyph_rast...

Still trying to understand what earth-shattering, "leverage" levering feature this brings compared to Skia.

> Memory model of Rust is undefined[2]. It might be anything Rust does to accomodate C++ bindings, but I don't think they really settled on one.

> I'd like to add - people have been doing large scale parallel software development for years in C++, in spite of C++.

Do you not see at least some level of contradiction to these statements?

This is probably the more relevant explanation: https://doc.rust-lang.org/nomicon/atomics.html. "At very least, we can benefit from existing tooling and research around the C/C++ memory model."

Perhaps respect your elders a bit more?

Post reply on HN