Live data from Hacker News

Integrating Zig and SwiftUI

mitchellh.com

51–58 of 58 posts

Re: Integrating Zig and SwiftUI

#51
post #42

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 ?

nah that's absolutely not the case, we support a bunch of architectures (with varying degrees of support level). can you link to the page that said that?

this is the most up to date support table for Zig:

https://ziglang.org/download/0.10.0/release-notes.html#Suppo...

Re: Integrating Zig and SwiftUI

#52
post #42

Earlier quoted context omitted.

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

nah that's absolutely not the case, we support a bunch of architectures (with varying degrees of support level). can you link to the page that said that? this is the most up to date support table for Zig: https://ziglang.org/download/0.10.0/release-notes.html#Suppo...

sorry, i can't find the link back. Maybe it wasn't on the official site but from an old website.

Another question i have : are there any kind of mechanism to ensure at least some kind of memory safety with regards to memory deallocation ?

I'm honestly halfway to try and prototype some cross-platform lib for my mobile app using zig, but this part is really the one that bugs me. I'm fine with having no GC or no ARC like go or swift, (and i'm ok with no ownership mechanim like rust), but seeing absolutely nothing new since C on that side is both a surprise (since zig has improved other aspects like slices and fat pointers), and a worry.

Re: Integrating Zig and SwiftUI

#53
post #52

Earlier quoted context omitted.

nah that's absolutely not the case, we support a bunch of architectures (with varying degrees of support level). can you link to the page that said that? this is the most up to date support table for Zig: https://ziglang.org/download/0.10.0/release-notes.html#Suppo...

sorry, i can't find the link back. Maybe it wasn't on the official site but from an old website. Another question i have : are there any kind of mechanism to ensure at least some kind of memory safety with regards to memory deallocation ? I'm honestly halfway to try and prototype some cross-platform lib for my mobile app using zig, but this part is really the one that bugs me. I'm fine with having no GC or no ARC lik…

The GeneralPurposeAllocator will tell you about memory leaks and double frees in debug mode. Take a look at the example on the front page of ziglang.org.

That said, the main feature that Zig offers for avoiding those mistakes are defer and errdefer, those really go a long way in avoiding mistakes, while also keeping things simple and explicit, which also helps avoid bugs.

ArenaAllocator is another thing that helps with memory safety, depending on what you're doing.

Finally, having to pass an allocator explicitly to all the things that need to allocate also helps with that: if you have an allocator to a struct when initing it, then you know you will most probably have to call its deinit method once you don't need it anymore.

Re: Integrating Zig and SwiftUI

#54
post #52

Earlier quoted context omitted.

nah that's absolutely not the case, we support a bunch of architectures (with varying degrees of support level). can you link to the page that said that? this is the most up to date support table for Zig: https://ziglang.org/download/0.10.0/release-notes.html#Suppo...

sorry, i can't find the link back. Maybe it wasn't on the official site but from an old website. Another question i have : are there any kind of mechanism to ensure at least some kind of memory safety with regards to memory deallocation ? I'm honestly halfway to try and prototype some cross-platform lib for my mobile app using zig, but this part is really the one that bugs me. I'm fine with having no GC or no ARC lik…

> Another question i have : are there any kind of mechanism to ensure at least some kind of memory safety with regards to memory deallocation ?

In general you probably need to learn about custom allocators and how different kinds can help you manage your memory. This applies to pretty much any lower-level language, but Odin, Zig, C++ and a few others have explicit support for this in their standard libraries.

Re: Integrating Zig and SwiftUI

#55
post #43

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…

My wording could have been better - I meant that it’s uncommon for engineers to know both iOS and Android at a deep level. Sharing code can let you share a lot of your logic, but you still need to understand the native host environment well, in fact maybe even deeper than normal since you are using unconventional approaches.

So you need engineers that have this deep iOS experience, deep Android experience, and deep C++/rust experience. If you are a solo dev with this skillset then maybe it’s a good choice. But in a team / big company setting such an unconventional stack will always be a drag chute on your velocity in all stages of the project

Re: Integrating Zig and SwiftUI

#56
post #28

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…

> The C runtime is privileged because it is already present on all 3 desktop OSes.

Yes, Ubuntu, Debian and Fedora.

On Windows, you don't get a C run time; you ship a MS Visual Studio run-time DLL if you're using Microsoft's tools (and not static linking), or something else with someone else's tools; maybe a CYGWIN1.DLL or whatever.

You get platform libraries like kernel32.dll and user32.dll; but those are not a C run-time. They are easy to call from C, but other than that, they are the OS run time.

Recently Microsoft has made an effort to create a "Universal C Run Time" for Windows; but I think you still have to download and ship that, and there may be reasons for someone to choose a different run-time. (E.g. needing a pretty detailed POSIX implementation.)

Re: Integrating Zig and SwiftUI

#57
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…

> The C runtime is privileged because it is already present on all 3 desktop OSes. Yes, Ubuntu, Debian and Fedora. On Windows, you don't get a C run time; you ship a MS Visual Studio run-time DLL if you're using Microsoft's tools (and not static linking), or something else with someone else's tools; maybe a CYGWIN1.DLL or whatever. You get platform libraries like kernel32.dll and user32.dll; but those are not a C run…

I thought msvcrt shipped with windows as early as XP; was I wrong?

Re: Integrating Zig and SwiftUI

#58
post #57

Earlier quoted context omitted.

> The C runtime is privileged because it is already present on all 3 desktop OSes. Yes, Ubuntu, Debian and Fedora. On Windows, you don't get a C run time; you ship a MS Visual Studio run-time DLL if you're using Microsoft's tools (and not static linking), or something else with someone else's tools; maybe a CYGWIN1.DLL or whatever. You get platform libraries like kernel32.dll and user32.dll; but those are not a C run…

I thought msvcrt shipped with windows as early as XP; was I wrong?

Even earlier; but that's a private system library you're not supposed to use.

Raymond Chen explains it: https://devblogs.microsoft.com/oldnewthing/20140411-00/?p=12...

Microsoft's new Universal C Run Time addresses the problem of there not being a C library on Windows that is for public use (every compiler vendor providing their own).

Post reply on HN