Build a PinePhone App with Zig and Zgt
lupyuen.github.io
lupyuen.github.io
So I am curious, what about the process was Pinephone specific?
Turns out those computers in our hands are actually just regular computers and all those dinks at Apple/Google are trying to nefariously lock us in!
I built several apps that are aimed for Mobile linux, and the only reason I build them specifically on the Pinephone is because I need to test it with the modem.
I wrote mmsd-tng, the backend to giving MMS on the Pinephone: https://gitlab.com/kop316/mmsd/
vvmd/vvmplayer, which enables Visual Voicemail: https://gitlab.com/kop316/vvmd https://gitlab.com/kop316/vvmplayer
And phosh-antispam, which hooks into calls to hang up on Spammers: https://gitlab.com/kop316/phosh-antispam
Turns out it is the same reason most consumers and commercial developers don't care about Desktop Linux.
This article is obviously a beginner's tutorial to deploying a Zig app to the PinePhone.
??? What does "deploy to the Pinephone" mean? Ctrl+F "deploy" returns nothing.
AFAIK, It looks like all of the development/coding/compiling is all done on the Pinephone over SSH, so I am not sure what makes it Pinephone specific.
> VSCode Remote/debugging to the PinePhone
That's just how to use SSH with VSCode? That's not Pinephone specific.
> This article is obviously a beginner's tutorial to deploying a Zig app
I get that, my point is aside from a small screen and a modem that can Call/send SMS, there isn't anything special about developing for the Pinephone vs. an ARM linux distribution. That's why I was curious.
But I don't think you're actually curious, I think you're just angry about something, when you should be moving onto the next post.
Not sure how useful it is to compile on the phone instead of doing a cross-compile on a “proper” dev box but I guess to just get up and running it works.
Makes me want a PinePhone because I have an idea or two and have no idea how to program a simple app for my iPhone. I’d probably just use C though because I gasp like programming in C/simple C++.
True, that just isn't specific to Zig, which is why I was confused. It is neat that building the GUI isn't too hard, building a GUI in C/GTK involved a lot of boilerplate and isn't easy to start.
For GTK: I just end up using this: https://gitlab.com/sadiq/my-gtemplate/ As my start point.
> Not sure how useful it is to compile on the phone instead of doing a cross-compile on a “proper” dev box but I guess to just get up and running it works.
That depends. I tend to develop on the phone so I am aware of the screen size limitation, but you can emulate that. I also develop on the phone because the apps I make need access to the Modem (calls/SMS/MMS/VVM) for me test. I have thought about putting an EG-25 into my laptop to develop on my laptop, but that's been a low priority since using the Pinephone is easy enough.
> Makes me want a PinePhone because I have an idea or two and have no idea how to program a simple app for my iPhone. I’d probably just use C though because I gasp like programming in C/simple C++.
You should! The community is very friendly and helpful. All of the programs I developed are in C, so you aren't alone.
:)
I have dismissed Zig in the past in favor of Rust. But I've since found Rust difficult to keep up with since it's developing so rapidly and I don't use it daily.
Zig seems like it has similar goals to Rust, but with a gentler learning curve. I know the Zig community isn't as big as Rust's, but maybe I wrote off Zig too soon.
Anyone know of any objective comparisons out there? Is Zig gaining traction in a similar space to Rust?
I have only really kick the tyres, but it seems to me that Zig is to C what Rust is to C++, ie they both try to be the next-gen with better safety and features, but Rust's type modeling is more extensive than, and can contain complexity better than Zig, in the same way that C++ OOP is better than raw C.
Zig has a good future though, and the metaprogramming facilities are superior to most languages IMO.
On the other hand, a complicated language also encourages you to use those complicated features to express yourself in more complicated ways. And this sort of thing, exercised without restraint, can lead to unreadable code. There is a lot to be said for a simple language that encourages you to write simple code and puts an emphasis on readability and maintainability over sheer power. Is Zig that language? I don’t know, but it seems like it’s aiming to be. Only time will tell whether its big statement, that we should prefer comptime code over fancy new language features or powerful macros that let us extend the language in a million ways the way we did with Lisp. I am interested to see how things develop!
For example, matklad (the author of rust-analyzer, one of the preeminent Rust programmers and someone I'd expect to get code right) made a recent blog post on "Caches In Rust" (https://matklad.github.io/2022/06/11/caches-in-rust.html). The cache is built around https://docs.rs/elsa, which is built around https://docs.rs/stable_deref_trait/latest/stable_deref_trait..., which is unsound for Box and violates stacked borrows in its current form (https://github.com/Storyyeller/stable_deref_trait/issues/15). However, the rules may be relaxed or more ergonomic alternatives added (https://github.com/rust-lang/unsafe-code-guidelines/issues/3...), it's uncertain right now.
(Also I go by "they".)
Zig's metaprogramming is not far off being as powerful as lisp. Of rust and zig, I'd expect zig code to be more capable of turning into a hot mess more quickly.
Hopefully its simplicity and the niche it is targetting will help the community keep it somewhat in check.
You can get away with not writing macros in most languages that have them. But a lot of static languages makes you use generics (parametric polymorphism) pretty frequently. And this two-stage evaluation (something like `funny(@comptime T: Type, a: T, …)`) is the simple-code flagship feature, in your book?
This seems like you're comparing the most basic usage of C++ templates to the full generality of Zig comptime. But isn't this ignoring the fact that people write absurdly complicated template metaprograms in C++ that are very difficult to understand and debug? C, C++, and Rust require you to learn a second language to do metaprogramming, Zig doesn't.
Zig's sweet spot is C, and it really helps that it was made to extend C, not completely replace it.
These guys genuinely just want to make a practical, simple, common sense system programming language that let's you talk to the hardware, the operating system, and shovel bits around conveniently.
I love Zig myself but for these questions I'd say you'd need to hold off a minimum of 3 more years before you get really meaningful answers or come to any conclusions. In the meantime if language development/languages for fun doesn't interest you I'd probably not bother with Zig in that time.
For context, I was using Rust for hobbyist stuff because I value provable correctness and I love tools to yell at me if I try doing something stupid. But Rust moved too fast for me. Every time I sat down to use it, I spent more time catching up on the developments I'd missed than actually being productive.
I'm choosing instead to learn how to write C in a modern, sustainable way since at least the ecosystem won't shift from under me any time soon.
To be completely clear, I don't hate Rust. I'm not ragging on it. If I used it in my day job, the experience of keeping up with it would be a totally different story. But for hobby and personal stuff, I need something where I can be productive whenever I find the time to devote to it.
In most cases that's true, but not all. ARM MTE + quarantine has just 1-2% overhead as tested on Chrome:
https://security.googleblog.com/2022/05/retrofitting-tempora...
Perhaps we'll see such techniques used in newer languages like Zig.
(This doesn't detract from your main point, of course - yes, Zig is simpler because it has less safety.)
Yeah, quarantining forever is going to have much more memory overhead. It might be fine for some use cases, but not a browser or anything else complex + long-running, I agree.
i want to control lifetimes and memory management, so i can target the hardware i want, and i can play with memory the way i want to do tricks and optimizations that could not be possible with a rigid language like rust(that is very slow btw)
the day zig adds borrowchecker or some lifetime enforcment shenanigan will be the day i'll look for an alternative
Not a fan of Rust too though and like the zig idea in general.
It's a shame, too, because there are a lot of really exciting ideas in the language. But unless you're working at NoRedInk with the lead developer, you might be better off sticking with tech that's a little more boring and less cutting edge, especially if the thing you're using it for is supposed to be making you money.
Zig has neither, and the sad truth is most developers will not make the jump from C and C++ and throw decades of skills out of the window unless they really have a lot to gain. This is true for Rust: you get compile time guarantees that your programs are memory safe and have no data races. That is enough for most to conclude that Rust has a shot to replace C/C++. But Zig? Like Hare, V, .. it mostly boils down to syntactical sugar, and then you have not only to compete with the rest of the crop of "C replacement tools", but with C + a static analyzer too.
If you forget a defer, you will leak memory, and if you have to deal with Valgrind and the likes anyway you are better off sticking with C and static analysis tools - with the added bonus that it's vastly easier to find skilled developers.
I know, I'm personally a language nut and I love using new languages, but personal preferences are not a great factor when pushing for wider adoption, because most developers out there don't really care about that and would rather use a tool they already know about and they are confident with.
What might make Rust success will be the fact it saves people time and money, and that is demonstrably true. Project Managers will definitely listen more to that argument than to "but it's shiny and new".
But that's exactly Zig's killer feature. As a C or C++ developer you don't need to throw your decades of skills out of the window. Instead you can start coding productively in Zig in a weekend. And you don't need to throw away your C (or C++, or Objc) code either, you can just integrate it into your Zig project and it's exceptionally easy to do so.
If that isn't "revolutionary" compared to other, bigger languages which try too hard to be revolutionary but then go on to build out their own little island paradise separated from the rest of the world I don't know ;)
(also if you're looking for an actually revolutionary single feature in Zig, check out how elegantly Zig's comptime feature enables generics and reflection)
"If you forget a defer, you will leak memory"
There is a bit more to it than just plastering defer all over. If you are designing something in a system programming language like a data structure you must know how to achieve memory safety, and might even want other properties like liveness guarantees. It's not like Rust can do this for you automatically in all, but the more trivial cases. There is unsafe Rust, and it's strictly worst than Zig as a C replacement.
On the other hand for simple API-consuming applications Rust is needlessly complicated. You throw time and money out of the window with it.
Rust's sweet spot is replacing C++.
But I am impressed with the idea of running vscode remote against the phone and compiling directly on the device.
Have things improved?
I say it's at the point where it's worth a reassessment - if you're the kind of person who gets nostalgic about the first years of Gentoo, as desktop. It can be worth it to try Plasma, Phosh and SXMO (Wayland unless you already have an opinion).
While it lasts multiple days in idle now, I'd get at least one spare battery for longer outings.
https://news.ycombinator.com/item?id=31806639
I have been using a Librem5 for the past six months full time, here is my comment on usage from ~week ago: https://news.ycombinator.com/item?id=31727098
[1]: https://wiki.pine64.org/index.php?title=PinePhone_Software_R...
[2]: https://wiki.pine64.org/index.php?title=PinePhone_Software_R...
wonder how it would do on like Android.
I don't understand why you'd want to drag the web into a phone GUI.
Please don’t…
Assuming you want to have people download a massive electron app to look at cat videos.
But the hardware is very slow compared to pretty much any other modern phone, you will struggle to get decent performance from web technology.
Of course you can run UIs for Zig programs in Sciter, just like you can do it for C or C++ programs...