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

Integrating Zig and SwiftUI

mitchellh.com

Post reply on HN
Print view View original

41–50 of 58 posts

Re: Integrating Zig and SwiftUI

#41

Post by kristoff_it »

turdprincess wrote: post #11
WhereIsTheTruth wrote: post #4

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…

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 me…

> even something trivial like not being able to set breakpoints in the shared code

I think your overall point still stands, but you can setup breakpoints in Zig and have the normal tooling work correctly with it.

Re: Integrating Zig and SwiftUI

#42

Post by bsaul »

kristoff_it wrote: post #40
bsaul wrote: post #39

this approach gets me really interested. What are the improvements i should expect in zig compared to C ? And how does zig stdlib compare to something like the go stdlib ( which to me remains the gold standard)

>What are the improvements i should expect in zig compared to C ? https://ziglang.org/learn/overview/ >And how does zig stdlib compare to something like the go stdlib the stdlib is still work in progress and not the current focus of development. right now things get added to it organically (ie things needed by the compiler itself, the toolchain, or as a proof of concept for other important functionality, like an even…

i just read the doc and saw a page saying stdlib only targets x86 arch at the moment ? so no arm ?

Re: Integrating Zig and SwiftUI

#43

Post by jb1991 »

JimDabell wrote: post #38
jb1991 wrote: post #32

Earlier quoted context omitted.

> It’s somewhat uncommon to have engineers known just iOS This is very common in the iOS world. Not sure about other areas.

Why did you break off mid-sentence? If you continue reading the rest of the sentence, you will see that they are saying the opposite of what you think they are: > It’s somewhat uncommon to have engineers known just iOS and Android, let alone a 3rd language / stack.

> If you continue reading the rest of the sentence

who stops reading a sentence in the middle?

I did not include Android or other stacks because I don't know about them (as I said, "not sure about other areas"). But for iOS it is not uncommon for developers to solely specialize in it, yet the comment claims it is uncommon. I wonder if you misread my comment or the one I replied to? Or perhaps the original comment is grammatically ambiguous.

Re: Integrating Zig and SwiftUI

#44

Post by 59nadir »

felipefar wrote: post #23

Nice post! I'm not sure if the same result is applicable to most software projects. A console emulator doesn't need several types of GUI objects, while most other projects need to display and handle input for several different types of data. In most projects I've worked on, the proportion of GUI code to business code was different: I saw apprx. 70% GUI code to 30% business code. So a cross platform GUI layer saves a…

> In most projects I've worked on, the proportion of GUI code to business code was different: I saw apprx. 70% GUI code to 30% business code.

Is it just me or is this a sad indictment of GUI libraries/frameworks in general? I'm not saying that the majority of situations I've seen are different, but while looking at these percentages it's actually sad that they seem likely, especially when you consider the lack of control most modern GUI solutions afford you and how you constantly have to work around their bad design. We're paying a lot for very little in the modern GUI landscape.

Re: Integrating Zig and SwiftUI

#45

Post by justincormack »

aidenn0 wrote: post #28
bestinterest wrote: post #19

Noob question, What makes languages like Zig, Rust, C and C++ the best fit for cross platform applications over many garbage collected languages? Why is bringing the language runtime a problem? What does it mean to compile to a C-compatible library? EDIT: I decided to ChatGPT my question instead. https://chat.openai.com/share/9a5f9f7a-0f5d-4cf6-95fc-4e0ec9...

Pretty much every modern language (Zig, Rust, C, and C++ included) depends on a runtime. The C runtime is privileged because it is already present on all 3 desktop OSes. It is also a lot smaller than most other runtimes, which makes bundling the C runtime with the program more palatable. A "C-compatible library" is a library (i.e. a collection of functions) that is callable in the same way that functions written in C…

That is somewhat conflating the calling convention and the runtime - C really doesn't have much that you can call a runtime outside the calling convention, although some libraries (eg pthreads say) have a little runtime which matters in practise for integrations, but these are libraries not parts of the language itself.

Re: Integrating Zig and SwiftUI

#46

Post by aatd86 »

mitchellh wrote: post #16
parhamn wrote: post #12

How does the api and "bridge" look in this type of setup? I'm trying to wrap my head around which parts you'd keep in the cross-platform layer (and whether that layer might be very thin in many applications I've built). If the application is heavy in UI state, does this sort of thing still make sense? I can't imagine what hell bidirectional data binding would be in this setup.

OP here. UI state lives in the GUI code. For a GUI toolkit like SwiftUI, that's quite important ergonomically. I'm unsure how to really describe how the "bridge" code looks. All GUI interaction code happens in Swift, and when buttons are pressed and so on, I call functions back into Zig, and so on. There are certain scenarios where my Zig code calls back into Swift (via function pointers provided). For example, reque…

Interesting.

I am thinking of writing such bridge for ly use case using Wasm (Wazero) with Go.

Hoping the perf impact of crossing the bridge will not be too high.

Re: Integrating Zig and SwiftUI

#47

Post by aidenn0 »

justincormack wrote: post #45
aidenn0 wrote: post #28

Earlier quoted context omitted.

Pretty much every modern language (Zig, Rust, C, and C++ included) depends on a runtime. The C runtime is privileged because it is already present on all 3 desktop OSes. It is also a lot smaller than most other runtimes, which makes bundling the C runtime with the program more palatable. A "C-compatible library" is a library (i.e. a collection of functions) that is callable in the same way that functions written in C…

That is somewhat conflating the calling convention and the runtime - C really doesn't have much that you can call a runtime outside the calling convention, although some libraries (eg pthreads say) have a little runtime which matters in practise for integrations, but these are libraries not parts of the language itself.

malloc and free are part of what I would consider a runtime. As are the file objects opened for standard I/O.

It's a very small runtime, but all the code before main is properly runtime initiation

Re: Integrating Zig and SwiftUI

#48

Post by ItsHarper »

jb1991 wrote: post #43
JimDabell wrote: post #38

Earlier quoted context omitted.

Why did you break off mid-sentence? If you continue reading the rest of the sentence, you will see that they are saying the opposite of what you think they are: > It’s somewhat uncommon to have engineers known just iOS and Android, let alone a 3rd language / stack.

> If you continue reading the rest of the sentence who stops reading a sentence in the middle? I did not include Android or other stacks because I don't know about them (as I said, "not sure about other areas"). But for iOS it is not uncommon for developers to solely specialize in it, yet the comment claims it is uncommon. I wonder if you misread my comment or the one I replied to? Or perhaps the original comment is…

They were saying that it's uncommon for a single developer to specialize in both iOS and Android

Re: Integrating Zig and SwiftUI

#49

Post by felipefar »

filleduchaos wrote: post #27
felipefar wrote: post #23

Nice post! I'm not sure if the same result is applicable to most software projects. A console emulator doesn't need several types of GUI objects, while most other projects need to display and handle input for several different types of data. In most projects I've worked on, the proportion of GUI code to business code was different: I saw apprx. 70% GUI code to 30% business code. So a cross platform GUI layer saves a…

Is 70% of the code actually GUI code, or is it business-and-platform-logic-coupled-to-GUI code?

New kinds of widgets, composition of classic widgets, view models, event handling (selection state, drag and drop, user inputs), visuals, shortcuts and accessibility.

Re: Integrating Zig and SwiftUI

#50

Post by Daimanta »

bsaul wrote: post #42
kristoff_it wrote: post #40

Earlier quoted context omitted.

>What are the improvements i should expect in zig compared to C ? https://ziglang.org/learn/overview/ >And how does zig stdlib compare to something like the go stdlib the stdlib is still work in progress and not the current focus of development. right now things get added to it organically (ie things needed by the compiler itself, the toolchain, or as a proof of concept for other important functionality, like an even…

i just read the doc and saw a page saying stdlib only targets x86 arch at the moment ? so no arm ?

According to https://ziglang.org/documentation/master/#Targets the only fully supported targets are x86-64. This does not mean that the entire stdlib will only work on x86-64 but that specific functions that require information about the inner workings of an architecture is only guaranteed to work on x86-84.

If you'd be interested in a hash function like CRC32 you can see in the source code that there is no dependency on arch specific functionality, which makes it likely that it will work fine on other (LE?) architectures. This is on a case-by-case basis at the moment though. The advice from the Zig community is to check the source code in case of doubt. I have always found the source to be accessible, so this hasn't been an issue for me.

Post reply on HN