|
Yes, it's Zig. Forgive me because I'm becoming a wordle post. 
But, I just gotta say, this is how extremely easy it is to use C code in Zig...
const c = @cImport({
@cInclude("unistd.h");
});
pub fn main() void {
const res = c.write(2, "Hello C from Zig!", 17);
}
Jeremy Falcon
|
|
|
|
|
You almost got me ready to learn it.
When it will run on ARM, I will definitely consider.
A home without books is a body without soul. Marcus Tullius Cicero
PartsBin an Electronics Part Organizer - Release Version 1.4.0 (Many new features) JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|
Mike Hankey wrote: You almost got me ready to learn it.
You're in luck, it already supports ARM cross compilation. Zig cross compilation I haven't tried it for ARM yet, but that's what the site says.
The main reason I'm learning it, is it's meant to be a direct successor to C... not C++ but C. You have projects like D or even Rust that creep into the overly complicated theory territory. Zig is like, nah screw that, this be C 2.0.
Don't get me wrong, you can kinda mimic interfaces in Zig as an example, but it just feels way more like C than most other languages out there. But, with some newer features that came about since the 70s... like a standard package manager that every other language besides C has standardized by now and built in unit testing. Which IMO is awesome.
It's still a young language (only started 8 years ago), but they recently got 21 million in funding for their series B. So, it's gonna continue to mature and evolve. Probably take several years to finally get to 1.0 though, so just be aware. The current release version is 0.13.0 and it'll be a bit before 0.14.0 is out. But, still... gotta start somewhere.
Jeremy Falcon
modified 21-Aug-24 21:34pm.
|
|
|
|
|
Damn another project. 
A home without books is a body without soul. Marcus Tullius Cicero
PartsBin an Electronics Part Organizer - Release Version 1.4.0 (Many new features) JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|
Oh, I should say there aren't any beginner books on it yet. It's all still so new. There are some scam books that are AI generated and wrong on Amazon, but not legit ones. One is being worked on though, and I'm sure others will arrive in the future.
So, for right now, it's gonna be online resources like ziglings, ziglang.org, zig.guide, reddit, Google, etc.
Here's a list of projects using Zig, including editor plugins, etc. Zig Learning Guide & Project Lists
Reminds me of getting in on Linux during the early days though. Kinda exciting.
Jeremy Falcon
|
|
|
|
|
Sooo... it really just wants to be C when it grows up?
|
|
|
|
|
I mean I know this is a joke... so the obligatory har har har... har har har. 
Buuutttt, and I know I'm sounding like a fanboi, but it's doing things that apparently the peeps behind C are too old to care about. Like, I mean, Zig sounds silly in name but I'm sure C is ran by grandpas still using an outhouse.
Let me just give you a simple example here, every other modern language has a concept of lambda type expressions (using C# nomenclature), but not C. Now, Zig doesn't do that 1 for 1, but let me just show you with code.
for (0..10) |i| {
}
Of course you can do that in C by manually declaring crap, but it's so much more verbose and a waste of typing.
Or what about a while block that supports a counter.
while (n <= 20) : (n += 1) {
}
Or and this is where things get crazy, being able to name blocks and break out of them.
namedBlock: {
break :namedBlock 42;
}
I could go on, but I'd be writing a book here. But stuff like comptime makes C macros look like a joke. I say this as a dude who loves C. I'm not a hater; I'm just a realist.
I mean like it or not man, history has shown us that things die out if they don't evolve. Nobody is speaking much Latin these days despite the fact it used to dominate the world. We're just too close to C to realize it's gotten very little love for a long time. Been 50 years man. That's half a century. The world has moved on.
Jeremy Falcon
|
|
|
|
|
"the peeps behind C are too old to care about"
sigh... that's racist. lol. Not really, but I'm trying to fix something that works in the real world. I already have some thoughts about your posts.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
charlieg wrote: sigh... that's racist. lol
Touché, buddy.
Jeremy Falcon
|
|
|
|
|
"I'm sure C is ran by grandpas still using an outhouse."
Okay Mr. Falcon, you're getting edgy here and somewhat triggered me. I would point out that there is beaucoup code out there happily running all written in C. The good news is that we - us grandpas and great grandpas - have a STABLE compiler. It's only worked for decades. But lets take a look at your code examples. Now, I don't know anything about "zig" other than it's another open source compiler to continue to confuse crap... so fair disclaimer.
"pub fn main() void {"
Great, so for decades the suggestion has been to make your variable names readable in whatever language is native to you. Looks like zig has reduced public to pub and function to fn. Not a good start.
"const res = c.write(2, "Hello C from Zig!", 17);"
does not impress me. Why? I'm supposing c.write assigns the output to res.
- Is res a dnamically allocated variable? String? Buffer of x bytes? Again, I don't know zig, but I have further issues.
- What does the 2 do?
- 17. Hmm, why not let the compiler handle the null terminated string? If I change the string, boom, the # is wrong.
Fights on Everything I just posted is meant in technical respect.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
charlieg wrote: The good news is that we - us grandpas and great grandpas - have a STABLE compiler.
I should say, C is and will always be my favorite language. It's served me well over the years and will always have a special place in my heart. I promise I'm not one of these zealot hater types.
But, ya know... I will joke about it. 
charlieg wrote: Great, so for decades the suggestion has been to make your variable names readable in whatever language is native to you. Looks like zig has reduced public to pub and function to fn. Not a good start.
I'm a realist, so there are things in Zig I'm not crazy about. IMO they should've made the syntax a bit more C-like to be C 2.0. But, the good outweighs the bad. So, I overlook stuff like fn instead of function.
I totally agree with the point that we should be moving away from too many abbreviations though, 100%.
charlieg wrote: Is res a dnamically allocated variable? String? Buffer of x bytes? Again, I don't know zig, but I have further issues.
It's the same as using that C function in C. No different. Zig just allows you use that C function so you don't have to abandon decades of code on the C side. So, write would return the number of bytes.
charlieg wrote: - 17. Hmm, why not let the compiler handle the null terminated string? If I change the string, boom, the # is wrong.
Actually, the compiler does handle that. I was just being lazy and writing a simple example.
charlieg wrote: Fights on  Everything I just posted is meant in technical respect.
Fair enough. Just know I love C. I do wish it evolved a bit more in the past 50 years though. Adding new features doesn't mean you have to break compatibility.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: Forgive me because I'm becoming a wordle post.
Could be worse, could be a CCC post.
|
|
|
|
|
So, here I am... n00bing it up in a new language and getting my learn on. Wut wut. And I come accross a feature that's postponed for now as the language is still young... async routines. Ok, I get it. It's new to the party. I can still do multi-threading, so not end of the world should I need to block something that would otherwise be non-blocking.
Buuuuuuuttt, ran across a few posts online with the typical "I never used it so I hate it" mantra. And it got me wondering, do people really hate the concept of asynchronous routines? Seems to me the only people that hate it just don't know it. Like at its core (using JavaScript as a reference) all it does is reduce complexity with what would otherwise be non-blocking code. Fail to see why that's so bad.
Using pseudocode...
function bruh() {
const response = fetch('/stuff');
console.log(response);
}
async function bro() {
const response = await fetch('/stuff');
console.log(response);
}
Like, why is that so bad? I bet these people would freak out over the concept of generators. I just don't see why people would hate this. Am I not alone with this thought?
Jeremy Falcon
|
|
|
|
|
Not a fan of async methods myself (in C#). I had never experienced them before, but I recently had to figure how to call them synchronously in order to use some third-party software which insisted -- for no reason that I could tell.
|
|
|
|
|
Unfortunately, I mean you know how it is, when a new buzzword is created so many peeps jump on the bandwagon as a excuse to use just to sound cool. So, I could totally see it being unnecessarily used. But, I don't see that as a problem with the simplified syntax. I see is as a people problem not really bothering to learn crap.
There are things that inherently should be asynchronous. File IO, Network IO, etc. Your application should never lock up if there's a problem or it's slow, etc. However, it's also nice to be able to simply say in simple syntax wait for this crap because because because. It's really nothing more fancy than that.
Maybe there should be two hotlines... one for macro abuse and another for async/await abuse.
Jeremy Falcon
|
|
|
|
|
Certainly. And maybe using threads can be confusing to some.
But I spin up threads whenever I need to. And not when I don't.
|
|
|
|
|
Touché
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: should be asynchronous. File IO, Network IO,
Uh, say what? I don't see it.
|
|
|
|
|
If you have a potentially long running process (because of a timeout on failure, etc.) your application shouldn't lock up because of it. Too many instances of trying to cancel a command line app or use a GUI that just locks while it's off just chillin.
Jeremy Falcon
|
|
|
|
|
Maybe you are thinking only of GUI applications?
I write mostly command-line utilities and they take and long as they take. I tend to have them log something every ten seconds or so so you know it's still at it and not just gone down to the pub.
In a WinForms application, I might spin up a thread, and use a ProgressBar or something if possible.
|
|
|
|
|
Same applies on the console. If you cannot cancel a long running process then that's no bueno. If data integrity is a concern then making operations atomic should be a consideration. It's never a good idea to look up a computer more than a second or so.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: never a good idea to look up a computer more than a second or so.
Bullpuckey.
Ctrl-C kills most console utilities anyway. Not a problem.
|
|
|
|
|
Gotta disagree there, it sends a signal like SIGINT which can totally be ignored if a program hangs. I've had way more than one app just tell me "whatever bro" after smashing Ctrl+C over and over.
Jeremy Falcon
|
|
|
|
|
Never, not once. But then again, I don't write utilities which hang.
And Ctrl-Z on OpenVMS.
|
|
|
|
|
I dunno what apps you've used, but clearly we've used different ones. Either way, looks like we're gonna disagree on whether or not some things should be non-blocking. I still still think non-blocking is cool and the way to go, if possible.
Oh the upside, it's Saturday and there's ice cream to be had.
Jeremy Falcon
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
