[HN Gopher] Integrating Zig and SwiftUI
___________________________________________________________________
Integrating Zig and SwiftUI
Author : ingve
Score : 54 points
Date : 2023-05-27 19:09 UTC (3 hours ago)
(HTM) web link (mitchellh.com)
(TXT) w3m dump (mitchellh.com)
| conradev wrote:
| Rust also works quite well from Swift, in the same way
|
| The key to a nice developer experience is making the build from
| source flow as easy/integrated as possible
|
| I use a build script in Xcode to build a Rust static library
| automatically when building an app. This is the latest version in
| a project I am helping with:
| https://github.com/hackclub/burrow/blob/main/Apple/NetworkEx...
|
| It would be cool to write a similar adapter but to run build.zig!
| synergy20 wrote:
| the key to 90% programmer is though, zig seems to be 100 times
| easier to master.
|
| to me, use zig for c,use rust for c++
| WhereIsTheTruth wrote:
| SwiftUI shines because you get to write Swift code and embrace
| the DSL
|
| You'll never be able to write that kind of code with Zig, or C or
| C++, it's impossible: https://github.com/amosgyamfi/open-swiftui-
| animations
|
| So the main advantage here would be to be able to consume your
| Zig code/libraries with your Swift application, and that does
| look interesting, so you could write your crossplatform app logic
| in Zig, and only use Swift the UI
|
| That's the advantage that should be advertised, Kotlin tried with
| Kotlin-Native, seems like a good strategy
| FpUser wrote:
| >"So the main advantage here would be to be able to consume
| your Zig code/libraries with your Swift application"
|
| I've heard that BS from MS reps when they visited our company
| sometime in 90s. They were telling us how we should have
| monkeys drawing forms in VB and gurus making main code in
| C/C++. Then I showed them Delphi. You had to see how sour their
| faces turned.
|
| >"You'll never be able to write that kind of code with Zig, or
| C or C++"
|
| Your statement looks totally wrong. Looking at code seems like
| simple "fluent" notation that is quite possible in languages
| you mentioned.
| [deleted]
| benatkin wrote:
| Are you suggesting that Zig never lets you just think about the
| problem? That's some terrible preoccupation with an idealized
| concept of a DSL.
|
| The swift code examples look kinda slick but it isn't a
| different paradigm any more than JSX is for building HTML.
|
| It seems like a form of The Bipolar Lisp Programmer.
| https://www.marktarver.com/bipolar.html
|
| > Lisp is like wielding an air gun with power and precision.
|
| Those Swift examples you show are very exciting, but it's best
| not to get carried away. It's the same as those that say that
| vim is terrible because it's modal and don't believe that vim
| programmers can think about the problem while they're typing
| because their brain is distracted with switching between modes.
| nusaru wrote:
| Second paragraph in OP:
|
| > One approach to building a native GUI for a cross-platform
| application is to write all of the business logic in a cross-
| platform language (C, Rust, Zig, etc.) and then write the
| platform-specific GUI code. This is the approach I take with my
| my terminal emulator and it works really well. As of the
| current date writing this post, 93% of my repository is
| business logic in Zig and C, and 4% is macOS-specific GUI code
| in Swift.
| turdprincess wrote:
| The downside of this kind of strategy is that for an engineer
| to work on it, they need to be proficient in iOS, Android, and
| zig/c/c++. It's somewhat uncommon to have engineers known just
| iOS and Android, let alone a 3rd language / stack.
|
| Another issue is maintenance and debugging - even something
| trivial like not being able to set breakpoints in the shared
| code can be a significant slowdown to an engineer. Not to
| mention the extra wrapping layers your native code needs to
| smooth out the interactions between the shared and native
| layers.
|
| For sure there are settings where it makes sense to take this
| approach, especially if code is shared across more than two
| platforms. But just for iOS and Android I wouldn't necessarily
| say it's a more efficient solution.
|
| Working on such shared code is also pretty stressful. In a pure
| native codebase I can simply make the change and test it, but
| with shared code I have to worry about consequences across many
| platforms - did I just fix something on one platform only to
| introduce an issue on another?
| Arathorn wrote:
| this is also how the Element X rewrite of the Element Matrix
| client works - although with Rust rather than Zig. We had to add
| async support to uniffi for a good experience from Swift (and
| Kotlin) tho! https://youtu.be/eUPJ9zFV5IE?t=1280 has some deets.
| ellis0n wrote:
| Good job. Please add a few words about debugging.
___________________________________________________________________
(page generated 2023-05-27 23:00 UTC)