1000 GitHub stars and not a single screenshot?
I presume the screenshots would look like a regular macOS app :)
macOS Apps in Rust
41–50 of 89 posts
Re: macOS Apps in Rust
#42Earlier quoted context omitted.
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.
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.
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.
Re: macOS Apps in Rust
#43Pretty 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…
> 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 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.
Re: macOS Apps in Rust
#44Earlier quoted context omitted.
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
Someone has to manually type .clone() calls.
If you don't, the compiler tells you to, as per standard Rust semantics.
Re: macOS Apps in Rust
#45Re: macOS Apps in Rust
#46Earlier quoted context omitted.
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.
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.
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.
Re: macOS Apps in Rust
#47Earlier 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…
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?
Re: macOS Apps in Rust
#48Interesting 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 iDevice…
> 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 allocati…
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).
Re: macOS Apps in Rust
#49Interesting 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 iDevice…
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.
Re: macOS Apps in Rust
#50Earlier quoted context omitted.
> 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 allocati…
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.