macOS Apps in Rust(github.com)
github.com
macOS Apps in Rust
https://github.com/ryanmcgrath/cacao
88 comments
> 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 cross platform native applications: This is a pain in the ass to do well - and there isn’t a particular reason this hasn’t been doable in C/C++ since forever - Rust isn’t some silver bullet. “Abstracting” away the native GUI/UX seems to be a common pitfall for junior devs - how hard can it be they think - then they learn why Qt exists.
> It's not too far from the write-once-run-everywhere philosophy of React native, Electron and similar.
Electron is about as far removed from the philosophy of targeting platform native toolkits as one can get.
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 cross platform native applications: This is a pain in the ass to do well - and there isn’t a particular reason this hasn’t been doable in C/C++ since forever - Rust isn’t some silver bullet. “Abstracting” away the native GUI/UX seems to be a common pitfall for junior devs - how hard can it be they think - then they learn why Qt exists.
> It's not too far from the write-once-run-everywhere philosophy of React native, Electron and similar.
Electron is about as far removed from the philosophy of targeting platform native toolkits as one can get.
> 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 aiming to abstract over native UI/UX patterns — are an ambitious, if not Sisyphean domain. Qt was about the best we could do in the C++ era, but a new era has dawned.
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 aiming to abstract over native UI/UX patterns — are an ambitious, if not Sisyphean domain. Qt was about the best we could do in the C++ era, but a new era has dawned.
> 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 building ambitious system software.
I like Rust - but this is classic RSF/RIIR copypasta.
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 building ambitious system software.
I like Rust - but this is classic RSF/RIIR copypasta.
> 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.
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.
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.
> 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/
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/
> 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?
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?
> Also neither of your examples do any text shaping on the GPU.
Sorry, font rendering. I thought font shaping is part of it. Pathfinder and Lyon were libs.
> Do you not see at least some level of contradiction to these statements?
No? They are discussing Simd and generic interactions.
Sorry, font rendering. I thought font shaping is part of it. Pathfinder and Lyon were libs.
> Do you not see at least some level of contradiction to these statements?
No? They are discussing Simd and generic interactions.
> Sorry, font rendering. I thought font shaping is part of it. Pathfinder and Lyon were libs.
They don't do GPU font rendering either.
Pathfinder isn't widely used -- see my original post about "spinning wheels".
GPU font rendering hasn't demonstrated much real world value for GUIs. Where it does get used a bit is games - an industry that is overwhelmingly C++ for the foreseeable future.
> No? They are discussing Simd and generic interactions.
I was responding to this: "I'd like to add - people have been doing large scale parallel software development for years in C++, in spite of C++."
Regardless, Rust still depends entirely on the years of research and development in C++ for a memory model which is a core underpinning of parallel programming.
They don't do GPU font rendering either.
Pathfinder isn't widely used -- see my original post about "spinning wheels".
GPU font rendering hasn't demonstrated much real world value for GUIs. Where it does get used a bit is games - an industry that is overwhelmingly C++ for the foreseeable future.
> No? They are discussing Simd and generic interactions.
I was responding to this: "I'd like to add - people have been doing large scale parallel software development for years in C++, in spite of C++."
Regardless, Rust still depends entirely on the years of research and development in C++ for a memory model which is a core underpinning of parallel programming.
> Pathfinder isn't widely used
Ofc. Servo was shut down before anything could happen with it. Making production-ready GPU font rendering is hard.
It's not spinning wheels anymore than OSS life cycle is spinning wheels (author needs functionality X author makes a useful lib for X -> it becomes popular -> amount of work increases -> due to pressure/changes in life author abandons lib -> another author has needs functionality X -> ...)
> I was responding to this: "I'd like to add - people have been doing large scale parallel software development for years in C++, in spite of C++.
Saying Rust has issues doesn't negate C++ having massive issues but also a bigger mindshare.
Ofc. Servo was shut down before anything could happen with it. Making production-ready GPU font rendering is hard.
It's not spinning wheels anymore than OSS life cycle is spinning wheels (author needs functionality X author makes a useful lib for X -> it becomes popular -> amount of work increases -> due to pressure/changes in life author abandons lib -> another author has needs functionality X -> ...)
> I was responding to this: "I'd like to add - people have been doing large scale parallel software development for years in C++, in spite of C++.
Saying Rust has issues doesn't negate C++ having massive issues but also a bigger mindshare.
> Rust codebases extend in size and scale to larger teams fundamentally better than C++ / C
There are about 3-4 orders of magnitude more large C++ projects developed by large teams compared to Rust projects as of now.
This might change in future, but your claim seems a bit premature.
In a previous company I worked at, we were forced to rewrite a greenfield project in C++ because it was going too slow with Rust. The team managed to ship the thing in a few months, compared to spending a month getting nowhere with Rust.
There are about 3-4 orders of magnitude more large C++ projects developed by large teams compared to Rust projects as of now.
This might change in future, but your claim seems a bit premature.
In a previous company I worked at, we were forced to rewrite a greenfield project in C++ because it was going too slow with Rust. The team managed to ship the thing in a few months, compared to spending a month getting nowhere with Rust.
> 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.
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.
C++ to Rust is not a similar jump as assembly to C++.
Qt may be the best toolkit so far. If Rust is going to let us make a big jump, I can’t wait to see that happen. What are the best contenders so far?
Qt may be the best toolkit so far. If Rust is going to let us make a big jump, I can’t wait to see that happen. What are the best contenders so far?
I do have a naive view on native GUI development because I have little real experience in it - I very much appreciate your insight.
> “Abstracting” away the native GUI/UX seems to be a common pitfall for junior devs
I would like to know more about what you mean here; my description of a "virtual UI" that you bind to from the native toolkit is an abstraction to the UI - but it's not an abstraction like Flutter which tries to merge all native widgets into abstracted widgets. My concept still requires you to write multiple native entry points using the UI kits of the target platforms.
` (GTK entry || Cacao entry || Win entry) => Virtual UI => application logic `
The idea is that the virtual UI would be an in-memory representation of the UI (have virtual buttons, labels, etc). It would be the job of the entry to correctly represent/bind to that virtual UI with the relevant presentation tool kit. The output binary would be specialised to the platform/UI kit used in the source entry point.
It seems sensible on the surface to decouple the UI from the native presentation as it minimizes the requirements of the native side to constructing the UI and binding to the virtual UI - but I would love to hear your thoughts.
I have not tested this architecture outside of web development but I imagine adding new UI targets (like web assembly, QT, etc) would be easier as it wouldn't require any changes to the virtual UI or application logic and would be a matter of creating a new entry point representing the UI for the new target.
> then they learn why Qt exists
Does QT feel native on MacOS, Windows and Gnome?
> Yes it is [talked about]
Could be my personal echo chambers talking here - but multithreading is almost never spoken about and/or often intentionally disregarded in modern web/electron applications.
It sucks because so many applications are written using Electron or other similar web wrappers.
> there isn’t a particular reason this hasn’t been doable in C/C++ since forever - Rust isn’t some silver bullet
Not dismissing this, I was more impressed that Rust offers a thread safety guarantee through its ownership model making it interesting from a contributor scalability standpoint.
I was thinking that it might make it easier to have more engineers working on a high performance GUI project because it would be significantly harder to break.
As an example; I could imagine if a company assigned a team of TypeScript/JavaScript developers with different experience levels onto a GUI project written in something like Go, there would be a lot of thread safety issues and seniors would spend a lot of time combing PRs for thread safety issues.
Rust, while perhaps not as simple from a syntax/types/symbols standpoint, offers an interesting development modality for these sorts of projects. I would expect that it would result in a more hands off contributor experience.
> Electron is about as far removed from the philosophy of targeting platform native toolkits as one can get.
Sorry I wasn't describing Electron as targeting platform native decorations - just that it promises an OS agnostic UI framework (write once run anywhere) at the expense of a diminished native experience and poor performance.
My point was that it might be interesting to explore the idea that a multi-entry native toolkit application fulfils the same "write once run 'anywhere'" promise but without the downsides.
> “Abstracting” away the native GUI/UX seems to be a common pitfall for junior devs
I would like to know more about what you mean here; my description of a "virtual UI" that you bind to from the native toolkit is an abstraction to the UI - but it's not an abstraction like Flutter which tries to merge all native widgets into abstracted widgets. My concept still requires you to write multiple native entry points using the UI kits of the target platforms.
` (GTK entry || Cacao entry || Win entry) => Virtual UI => application logic `
The idea is that the virtual UI would be an in-memory representation of the UI (have virtual buttons, labels, etc). It would be the job of the entry to correctly represent/bind to that virtual UI with the relevant presentation tool kit. The output binary would be specialised to the platform/UI kit used in the source entry point.
It seems sensible on the surface to decouple the UI from the native presentation as it minimizes the requirements of the native side to constructing the UI and binding to the virtual UI - but I would love to hear your thoughts.
I have not tested this architecture outside of web development but I imagine adding new UI targets (like web assembly, QT, etc) would be easier as it wouldn't require any changes to the virtual UI or application logic and would be a matter of creating a new entry point representing the UI for the new target.
> then they learn why Qt exists
Does QT feel native on MacOS, Windows and Gnome?
> Yes it is [talked about]
Could be my personal echo chambers talking here - but multithreading is almost never spoken about and/or often intentionally disregarded in modern web/electron applications.
It sucks because so many applications are written using Electron or other similar web wrappers.
> there isn’t a particular reason this hasn’t been doable in C/C++ since forever - Rust isn’t some silver bullet
Not dismissing this, I was more impressed that Rust offers a thread safety guarantee through its ownership model making it interesting from a contributor scalability standpoint.
I was thinking that it might make it easier to have more engineers working on a high performance GUI project because it would be significantly harder to break.
As an example; I could imagine if a company assigned a team of TypeScript/JavaScript developers with different experience levels onto a GUI project written in something like Go, there would be a lot of thread safety issues and seniors would spend a lot of time combing PRs for thread safety issues.
Rust, while perhaps not as simple from a syntax/types/symbols standpoint, offers an interesting development modality for these sorts of projects. I would expect that it would result in a more hands off contributor experience.
> Electron is about as far removed from the philosophy of targeting platform native toolkits as one can get.
Sorry I wasn't describing Electron as targeting platform native decorations - just that it promises an OS agnostic UI framework (write once run anywhere) at the expense of a diminished native experience and poor performance.
My point was that it might be interesting to explore the idea that a multi-entry native toolkit application fulfils the same "write once run 'anywhere'" promise but without the downsides.
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" cross platform UI toolkits are no better than Java. To paraphrase Ford: "you can do any platform you like, as long as it's windows".
[edit: to be very clear, I include "catalyst" in the cross platform toolkits that make noticeably worse apps on Mac. Trying to share a single interface "language" for different platforms just leads to what is at best mediocre UI.]
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" cross platform UI toolkits are no better than Java. To paraphrase Ford: "you can do any platform you like, as long as it's windows".
[edit: to be very clear, I include "catalyst" in the cross platform toolkits that make noticeably worse apps on Mac. Trying to share a single interface "language" for different platforms just leads to what is at best mediocre UI.]
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.
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.
> Can you give an example of something can only be done in a native app?
Accessibility, text field behaviors, control animations looking right, window resizing behaviors, any system settings related to UI applying properly, printing, export to PDF, rich text copy and paste, normal power and memory use, the engineers working on the next OS release being able to fix your app if they break it, your app updating to the next OS version's UI changes automatically…
Accessibility, text field behaviors, control animations looking right, window resizing behaviors, any system settings related to UI applying properly, printing, export to PDF, rich text copy and paste, normal power and memory use, the engineers working on the next OS release being able to fix your app if they break it, your app updating to the next OS version's UI changes automatically…
afaik not a problem with apps written in something like react native which use platform specific widgets and common business logic.
There's more to a UI layer than individual controls. Like spacing between them fitting platform conventions, and window resizing and text size needs them to coordinate.
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.
why should it? it makes no sense to me; you can do anything
It just might be that you don't go all the way, because you think a 80% sufficient result is enough for you
It just might be that you don't go all the way, because you think a 80% sufficient result is enough for you
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.
> 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.
Cross platform toolkits are a way of getting something good enough, quickly. Our standards may be different, but I would say you can get something good. You likely won’t get something great though.
I agree with your statement about modern toolkits being no better than Java, but Java is pretty good. I’d have no problem starting a new project with it today.
All that said, I’d much rather have a well written native application than a well written cross platform application.
I agree with your statement about modern toolkits being no better than Java, but Java is pretty good. I’d have no problem starting a new project with it today.
All that said, I’d much rather have a well written native application than a well written cross platform application.
If anything, many of them are much worse in capabilities.
https://www.oreilly.com/library/view/filthy-rich-clients/978...
https://www.oreilly.com/library/view/filthy-rich-clients/978...
Yet among the most used apps a lot of them are cross platforms: chrome, ableton live, vscode, figma, any game under the sun, slack, discord, …
I would even argue that very few still develop directly with native ui toolkits directly.
You mean the slew of electron apps that are well known to be annoying to use and inconsistent with the rest of the software on a Mac? Games not so much because they aren't using any platform toolkit.
But also "developers using cross platform toolkits because it's cheaper" does not undermine my argument "you can't make good apps", I could make the exact same argument about cross platform Java apps.
But also "developers using cross platform toolkits because it's cheaper" does not undermine my argument "you can't make good apps", I could make the exact same argument about cross platform Java apps.
You can write "good enough" ones though, and I've been doing it for years.
The GUI bindings are usually the hard part.
Speaking of, does anyone know how Qt bindings for Rust are these days? Last time I looked, there were several awkward Rust APIs for Qt, suffering in part from the fact that Qt's API is inheritance-based.
I think it's pretty difficult mapping the Qt memory management model to Rust, for the same reason we haven't seen working Golang bindings for Qt either. I have some experience with the Python bindings (PySide or PyQt) and both of them use pretty extensive wrapper generator frameworks specially developed for the task (SIP in the case of PyQt, Shiboken in the case of PySide), coming up with something like that is not an easy task at all. And Python is a language that was pretty much intended to act as a foreign function wrapper around low-level languages, while Rust & Golang are not primarily intended to be wrappers for other languages.
> https://github.com/therecipe/qt
Do these not work? (Not a rhetorical question - I haven’t tried them.)
Do these not work? (Not a rhetorical question - I haven’t tried them.)
They used to work until the big modules change a few golang releases ago. Now, nothing works anymore unless you exhume a sufficiently old golang compiler.
The project also seems dead since 2020 or so, a current fork is https://github.com/bluszcz/cutego/ But I haven't tried that one.
The project also seems dead since 2020 or so, a current fork is https://github.com/bluszcz/cutego/ But I haven't tried that one.
I see what you mean about this particular project, but more generally, you can certainly use pre-modules Go code with current Go compilers. See e.g. https://github.com/golang/go/issues/37797 (a case of someone not RTFMing, but the response illustrates how it's done).
If you just want to pretend modules never happened, then export GO111MODULE=off and use the latest Go compiler.
If you just want to pretend modules never happened, then export GO111MODULE=off and use the latest Go compiler.
In most cases, these things would work, but not here. Tried everything, nothing works except using a pre-modules-compiler.
In general, golang seems to work best with golang-only projects. As soon as there are other languages in the mix, like C++ here, things get very ugly very fast.
In general, golang seems to work best with golang-only projects. As soon as there are other languages in the mix, like C++ here, things get very ugly very fast.
Ah, I think I misinterpreted what you meant by "nothing works anymore". I thought you were saying that no old Go projects were usable with new Go compilers. I believe you that this particular project may not work with the current toolchain.
Ah, yes, that wasn't sufficiently clear in my text. In almost all projects I've done/used, go modules work fine and are nice. It is just this one library that I know ceased to work.
There is a recent article about this on r/rust https://blog.logrocket.com/build-desktop-app-qt-rust/
Interesting to see that AppKit is fully supported before UIKit, usually it's the reverse (if AppKit is supported at all). I suppose it kind of makes sense… the case for sharing a Rust core across platforms is stronger on macOS, because on iOS the optimizations you're trading away (such as the native network stack scheduling requests from apps to fire while the antenna is already awake) have a bigger impact on iDevices.
Tangentially related, I'd to dabble in Rust at some point but the syntax and memory management leave me trepidatious, and I'm not sure that it'd be the tool I reach for when developing apps with UIs… from a distance it feels better suited for CLI tools, back ends, and the nuts'n'bolts parts under the hood of UI apps. In comparison it makes some tradeoffs but I really enjoy writing UI apps in Swift (albeit in UIKit/AppKit — SwiftUI needs more time in the oven).
Tangentially related, I'd to dabble in Rust at some point but the syntax and memory management leave me trepidatious, and I'm not sure that it'd be the tool I reach for when developing apps with UIs… from a distance it feels better suited for CLI tools, back ends, and the nuts'n'bolts parts under the hood of UI apps. In comparison it makes some tradeoffs but I really enjoy writing UI apps in Swift (albeit in UIKit/AppKit — SwiftUI needs more time in the oven).
> Tangentially related, I'd to dabble in Rust at some point but the syntax and memory management leave me trepidatious [...]
Assuming your trepidation is because memory management is somehow more manual in Rust I would argue that it's actually not. This isn't something I'm saying because I want to convince you to use Rust; I'm actually of the opinion that Rust doesn't give you enough direct control of memory allocation and has iffy support for custom allocators on top.
Rust's memory management is much more like a garbage collected language in practice, hence why I consider it too indirect.
Assuming your trepidation is because memory management is somehow more manual in Rust I would argue that it's actually not. This isn't something I'm saying because I want to convince you to use Rust; I'm actually of the opinion that Rust doesn't give you enough direct control of memory allocation and has iffy support for custom allocators on top.
Rust's memory management is much more like a garbage collected language in practice, hence why I consider it too indirect.
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.
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.
More tangential, is there a good, in-depth resource for learning how to build an app in AppKit w/ Swift?
Unfortunately I can't point you at a single comprehensive resource.
Instruction for building apps in AppKit has always been kind of spotty. When I first started learning it alongside Objective-C in the 2000s, the best a beginner could really do was sift through random blogposts and mimic patterns seen in FOSS Mac apps. The best resources at that point were probably the various books on the topic (such as the Big Nerd Ranch Cocoa books I'd seen recommended frequently) but at that point I was a broke teenager so buying books was off the table.
I would like to at some point build a one stop shop for learning all the most pertinent parts of building a Mac app with AppKit and Swift, but that takes a lot of time… if it happens it'd probably be when I'm inbetween jobs so I can dedicate the resources required to make such a thing good.
Instruction for building apps in AppKit has always been kind of spotty. When I first started learning it alongside Objective-C in the 2000s, the best a beginner could really do was sift through random blogposts and mimic patterns seen in FOSS Mac apps. The best resources at that point were probably the various books on the topic (such as the Big Nerd Ranch Cocoa books I'd seen recommended frequently) but at that point I was a broke teenager so buying books was off the table.
I would like to at some point build a one stop shop for learning all the most pertinent parts of building a Mac app with AppKit and Swift, but that takes a lot of time… if it happens it'd probably be when I'm inbetween jobs so I can dedicate the resources required to make such a thing good.
Gotcha, thanks for the reply. I think you'd have the market on this domain cornered if ever you'd produced a comprehensive text since its very much still blog posts and reading extant code.
Author here. :)
AppKit is first because this was extracted from a cross platform GUI library I was building years ago, and it’s just less cumbersome to iterate on.
AppKit is first because this was extracted from a cross platform GUI library I was building years ago, and it’s just less cumbersome to iterate on.
> I would be surprised if we didn't have another ~5+ years of support
Five years would shock me. I’d say more like ten. It’s gonna take a huge concerted effort to get rid of objc in macos, and idk if it’s worth it
Five years would shock me. I’d say more like ten. It’s gonna take a huge concerted effort to get rid of objc in macos, and idk if it’s worth it
There’s a proposal to allow C++ and Swift to interact in the same way that objc and C++ interact, and if that were to eventually become part of swift then objc’s days are numbered. Right now, one of the most significant reasons to continue using objc is that you don’t have to wrap everything in a C API.
Forgot the link: https://www.swift.org/cxx-interop-workgroup/
FWIW, I’m the author and I think I wrote that line close to 5 years ago already… so you may be right. :)
A tangent: does anyone have recommendations for a library for easy Swift-Rust interop? This is a cool tool, but I’d much rather make a GUI natively with e.g. SwiftUI and then call out to Rust for business logic. The previous times I’ve looked into this, both languages had to communicate through a C intermediate, and handling more complex types became a chore…
A bit late, but swift-bridge (https://github.com/chinedufn/swift-bridge) does this intelligently, and is probably what you're looking for.
Mozilla's uniffi-rs is really good. You write a common IDL and the bindings are generated automatically. It supports Swift, Kotlin, Python, Ruby and JavaScript (not in the official repo).
https://github.com/mozilla/uniffi-rs
https://github.com/mozilla/uniffi-rs
There was a talk given on this subject at iOSoho if ya want to take a peek:
https://youtu.be/8ApcIOZe9qg?t=1921
https://youtu.be/8ApcIOZe9qg?t=1921
This is off topic, but thinking about portable desktop apps, why didn’t JavaFx become more popular? What is JetBrains using for its sophisticated GUIs? Is it just Swing? It would be great if Rust could be used to write portable high quality desktop apps.
> why didn’t JavaFx become more popular?
Oracle ditched it a long time ago [0]
> What is JetBrains using for its sophisticated GUIs? Is it just Swing?
They use custom Swing components [1]
0: https://www.infoworld.com/article/3261066/javafx-will-be-rem...
1: https://plugins.jetbrains.com/docs/intellij/user-interface-c...
Oracle ditched it a long time ago [0]
> What is JetBrains using for its sophisticated GUIs? Is it just Swing?
They use custom Swing components [1]
0: https://www.infoworld.com/article/3261066/javafx-will-be-rem...
1: https://plugins.jetbrains.com/docs/intellij/user-interface-c...
If you use the Cocoa API with ObjC or Swift, you get Automatic Reference Counting (ARC), generated by the compiler. I guess with this you'd have to retain / release your objects manually again?
No.
Rust has RAII so you can have retain on 'clone' operations and release on drops, just like the native Rc/Arc types do.
This is, incidentally, how the servo bindings to core-foundation work (I prefer those bindings where there is overlap).
Servo bindings: https://github.com/servo/core-foundation-rs
Other crates of interest on this topic: - https://crates.io/crates/objc - https://crates.io/crates/block
This is, incidentally, how the servo bindings to core-foundation work (I prefer those bindings where there is overlap).
Servo bindings: https://github.com/servo/core-foundation-rs
Other crates of interest on this topic: - https://crates.io/crates/objc - https://crates.io/crates/block
Someone has to manually type .clone() calls.
If you don't, the compiler tells you to, as per standard Rust semantics.
Automatic Reference Counting.
Writing by hand isn't the same.
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 refcounting as long as the code you write is sound according to Rust rules.
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 refcounting as long as the code you write is sound according to Rust rules.
Moving goalposts.
We are speaking about the normal development experience, not corner cases or unsafe code.
We are speaking about the normal development experience, not corner cases or unsafe code.
[deleted]
Rust has ARC too so I very much doubt it.
Nope, someone has to manually type .clone() calls.
That's irrelevant (and barely different to having to type `=`). The salient point is that you don't need to manually call free/release.
That is more than relevant, otherwise we are comparing oranges to apples, pun intended.
Automatic Reference Counting.
Since = is the same as .clone() in character count?
Automatic Reference Counting.
Since = is the same as .clone() in character count?
Yes I'm aware that the A stands for Atomic in Rust, not Automatic. But it is still automatic because you do not need to increment and decrement the counter manually.
> Since = is the same as .clone() in character count?
Why does character count matter? I think you're getting a bit distracted from the point.
Will you need to manually free/release objects? No you will not.
> Since = is the same as .clone() in character count?
Why does character count matter? I think you're getting a bit distracted from the point.
Will you need to manually free/release objects? No you will not.
[deleted]
Author here.
Nope, retain on create/etc and release on drop happens automatically.
Nope, retain on create/etc and release on drop happens automatically.
Is it a backend library for Slint?
No. This is rust bindings to the native apple UI toolkits, UIKit and AppKit (on iOS and macos respectively). Using a library like this, your software will have a fully native look and feel. The result should be indistinguishable from the equivalent Swift or Obj-C app from the point of view of a user. Including all accessibility hooks, fully native widgets and things like that.
The downside is that code written against this api will not work on any other platform.
The downside is that code written against this api will not work on any other platform.
I’d take that downside over having to mix languages on each platform. UI toolkit Rust bindings for all the platforms I want to target would let me just write Rust instead of also having to write Swift, Java, JavaScript, etc.
1000 GitHub stars and not a single screenshot?
Author here - it’s a rust crate, run one of the many examples in the project. :)
I presume the screenshots would look like a regular macOS app :)
Is... the name a Portlandia reference?
It could be a Portland reference. The city had a gourmet chocolate shop called Cacao that served "drinking chocolate" from 2005 until 2020. I know because I went in there after getting lost and drenched in a Portland February, and the staff there were kind enough to bring me towels and let me wait out the downpour while I sipped chocolate.
But more than likely it's just a reference to Apple's Cocoa api.
But more than likely it's just a reference to Apple's Cocoa api.
Am I missing something, is the name/reference just "cacao"?
Many languages spell cocoa that way, so I would take the name as cocoa-but-exotic or cocoa-but-foreign.
Author here.
Never seen Portlandia, so no. Just a Cocoa pun!
Never seen Portlandia, so no. Just a Cocoa pun!
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 state.
This has the advantage of a project feeling natural to the platform while still allowing for code reuse between platforms - though you would still need to rewrite widgets/components for each platform independently.
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. After all, you can't horizontally scale a client device so it's important that an application is able to maximize its use of the available hardware. Rust's borrow checker/ownership model eliminates dangerous multi-threaded code which makes it practical to write highly efficient GUI applications.
Could be good for projects like cross-platform terminal emulators or code editors.