|
Please no zealot type replies. Looking for intellectual discourse amongst those not afraid of change, based on real life experience, etc. I also realize the target audience here will always lean towards C-style languages, so please be objective.
But, I'm torn. For this project I'm about to embark on, I have two mandatory requirements. Everything is optional.
1) It's gotta be able to do web requests.
2) I gotta be able to know I can do regex... should I need it. Regex has saved my butt so many times I will never use a language without. Just won't happen.
So, back in the day, in C at least, for these two solves I would just use libcurl and libpcre2.
I don't know about you guys, but that got old. It's a hell of a lot easier to handle these requirements in higher level languages. But, I need the speed here because I want this application to represent the best of what I can do... not half arse it because it's easy. I wanna be proud of this; otherwise, I'd just use JavaScript/Node.js.
So, that brings me to Zig (yes, I said it  ). If I were to give a 2 second overview, Zig is to C as Rust is to C++. And that really, really got me interested. I'm an old fart, and this is a new smell. Cool.
However... Despite all the niceties of Zig, it's still young with 1.0 being years away I'm sure. It can do web requests, but that just came out months ago and it cannot connect to some TLS servers. Which means, I'd still be using libcurl anyway to be able to reliably do web requests... just in Zig. I'm sure it'll improve in time, but that may be a couple years from now. It's still so young.
Same thing goes with regex, there are some regex libraries by people, but nothing official as part of the language yet. And, the ok "zig style" third party ones I've seen don't support UTF-8 for instance. So, for now, I'd still be using libpcre2 as well. Edit: There is POSIX regex, but ideally this app would be cross platform and that would still be C-style anyway.
I want something new (a lot); I'm not afraid of moving on from C if I can find something that has the same philosophy of it (KISS). But, I also want things to work reliably. And unfortunately, it may be that Zig is still too young for this for the next couple of years.
There's absolutely nothing preventing me from using C libraries in Zig. So, I can use these libraries and just eventually migrate over to the "zig way" in the future. That's the route I'm leaning towards. But, there's something in the back of my head saying... if you're doing it the C way, just use C - duh. It's your buddy. It's your pal. Y'all have been places together.
So, am I being stupid or am I just overthinking this or both? 
Jeremy Falcon
modified 24-Aug-24 11:55am.
|
|
|
|
|
IMO, the risk with a "young" language is that the original team behind it gets tired of it and the rest of the community isn't large or committed enough to keep it going, and it becomes an unsupported dead-end. It's a Catch-22, it's gotta have the traction to keep going, but you need to have enough people with a vested interest to do so.
That's the first question I'd ask myself. Do you get a feeling that if the entire team suddenly died in a plane crash, the project would go on?
Without a contingency plan, the risk is entirely on you. Cool syntax and all technical wizardry under the hood seem entirely irrelevant without that.
My 2c anyway...
|
|
|
|
|
dandy72 wrote: IMO, the risk with a "young" language is that the original team behind it gets tired of it and the rest of the community isn't large or committed enough to keep it going, and it becomes an unsupported dead-end. It's a Catch-22, it's gotta have the traction to keep going, but you need to have enough people with a vested interest to do so.
100% agree. That's why I've ignored most newfangled languages. Zig is different. Yeah they're young (compared to old farts), but the peeps behind it are serious and pretty smart. There's already an established foundation behind it that just got $21.1m in their series B and a community that's really growing. I'm completely confident this language will continue to grow and mature.
dandy72 wrote: That's the first question I'd ask myself. Do you get a feeling that if the entire team suddenly died in a plane crash, the project would go on?
I think so. Been wrong before, but this one is different than languages like Odin (these kids watch too many cartoons I swear). I could be wrong again, but I'm not sure the Odin project would survive without the one dude behind it.
dandy72 wrote: Without a contingency plan, the risk is entirely on you. Cool syntax and all technical wizardry under the hood seem entirely irrelevant without that.
100% agree buddy.
Dang, this should be easy to choose. 
Jeremy Falcon
modified 24-Aug-24 10:38am.
|
|
|
|
|
Jeremy Falcon wrote: I'm completely confident this language will continue to grow and mature.
Well you can cross that out from the 'cons' list then. The shorter that list, the closer you get to your answer. 
|
|
|
|
|
Do you have time/energy to do both Zig and C, side-by-side? Could be some useful results from that, both for you and others, and if you start seeing problems on the Zig side, you've got a fallback.
modified 26-Aug-24 6:52am.
|
|
|
|
|
Good question... not sure I do have the energy.  If I had to pick one (to do both) though I'd have to stick with C. Zig ships with a C translator to Zig but nothing exists the other way around.
Jeremy Falcon
|
|
|
|
|
A couple of questions;
1) Is time a factor?
2) Is this a personal project of for client/
Years ago we did a job for a power plant, control hardware/software.
Problem was the project manager selected BETA software to run the plant. We spent months debugging their software and in the end cost me a marriage, no lose there but the company got sued.
Upshot is: If you have the time for ZIG to evolve and mature, use it if there are constraints I'd say go with what you know.
Just my two sense. 
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: 1) Is time a factor?
Yes and no. No in the fact I don't have a deadline, but I'm not gonna do this is in assembly.
Mike Hankey wrote: 2) Is this a personal project of for client/
Personal. I'd never use Zig in the enterprise just yet. It's too young and the docs/books aren't out there. Which means it would be harder to find and train devs on it. Maybe in 10 years, but definitely not now.
Mike Hankey wrote: Problem was the project manager selected BETA software to run the plant.
Mike Hankey wrote: We spent months debugging their software and in the end cost me a marriage, no lose there but the company got sued.
Ha ha ha ha ha. To that point, I'd never use a language I can't unit test in. Fortunately, I can unit test in C and Zig.
Mike Hankey wrote: Upshot is: If you have the time for ZIG to evolve and mature, use it if there are constraints I'd say go with what you know.
I do as I can at least do things C-style for now. I think I'm just having a hard time of letting go of my old buddy... sitting back in the corner saying "did you forget about me? sniff sniff"
Mike Hankey wrote: Just my two sense.
Great points man.
Jeremy Falcon
|
|
|
|
|
I would throw out one other consideration that we sometimes overlook at the beginning of a project: Language performance is sometimes (sometimes) misleading. Yes, a language with garbage collection does not fit a situation with real time requirements. But if you break your work up into transactions, for the sake of a white board, where is the time spent? You mentioned network requests. Those can typically run forever compared to most of the processing between. I'm not recommending Python, but why do folks use it? It's got to be at the far end of slow. Development is fast, but that may not make up for the slowness. Oh, got large matrices? Lots of matrix math? It's the choice. Languages such as GO and Swift often compensate for their performance flaws with access to great algorithm libraries and debug tools. For myself, I always want a good development and debug environment. Also, you identified one important requirement: whatever language you choose, it needs to be able to call out to C libraries. If you meet this last requirement, then it seems that you are good to go. Good luck and wishing you fun times with your project.
|
|
|
|
|
Great points all around.
Bill_M wrote: Good luck and wishing you fun times with your project.
Thanks man.
Jeremy Falcon
|
|
|
|
|
|
PIEBALDconsult wrote: : cough : D : cough :
That's what she said. 
Seriously though, if I was gonna use D, I'd just use Rust. Rust is already in the Linux kernel, backed by Microsoft and Mozilla, and has a much larger ecosystem.
Jeremy Falcon
|
|
|
|
|
Quote: So, am I being stupid or am I just overthinking this or both?
Of course not. The only way to put an eyeball on a new development tool/language is to do a significant project with it. Not "hello world". I took a look at Blazor by doing a project for a Pi. Something for commercial? Maybe take a look in your crystal ball for support.
>64
It’s weird being the same age as old people. Live every day like it is your last; one day, it will be.
|
|
|
|
|
I would warmly recommend you to recommend you to take a peek at Go. It is very C-style, has amazing libraries, generous tutorials, and it can hardly be called a "young" language anymore (Born in the USA, 2009).
If you like the look of it, I am pretty sure you will never be disappointed by the [set of] libraries.
For example:
Go by Example: HTTP Client[^]
Go by Example: Regular Expressions[^]
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
Keep in mind, I did ask to keep the zealotry out of it. I realize it was a warm suggestion, but let me put this way... 99% of devs that lack hardcore experience tend to think the language they chose is the best one. I passed that stage a loooooong time ago. I need facts, empirical data, the voice of experience, to make sure I'm being heard, etc. to ever convince me of anything these days.
Currently, I'd use Rust before I used Go. Go is still garbage collected and incurs a runtime penalty. While Rust has some runtime abstractions as well, it's not as much as Go. I have absolutely nothing against Go. It's just not what I want for this project.
The whole idea behind my choice in a lower gen language is raw speed. While Go is most certainly faster than say JavaScript, it's still not bare metal. So, then it would be a "good enough" situation where I still know I could do better, in which case I may as well just stick with JavaScript/Node.js (what the app is currently in) if "good enough" is the standard I'm willing to accept.
Jeremy Falcon
|
|
|
|
|
I never said Go "best". I too am old enuff to to agree that "best" does not exist. I might have read your post (and requirements) a tad to quickly, still I dunno why the word "zealotry" had to be repeated.
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
Bruh... bro... dude...
You uh, eggshells much?
Jeremy Falcon
|
|
|
|
|
Uh, brohan, from someone who doesn't give a crap either way, he could be saying the same to you.
|
|
|
|
|
I'm sure you feel better now, but nope... try again dude.
Jeremy Falcon
|
|
|
|
|
Practically any standardised language (and many that are not) have libraries that can meet your requirements. I'd say that more depends on the target environment.
On Windows, I would choose C# or C++. On Linux, I would choose C++, Rust, or C# (if the Mono environment meets your requirements).
Having said that, I'm sure that these days you can even find libraries for Fortran and COBOL.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Totally agree buddy. I like Zig, but it's not a standardized language yet. It's just so new to the party. So, now I gotta decide if I want to be cool or stable. 
Daniel Pfeffer wrote: I'm sure that these days you can even find libraries for Fortran and COBOL.
Real talk, there's a masochistic part of me that thinks doing it in COBOL would be funny.
Jeremy Falcon
|
|
|
|
|
Thanks man. It seems to be the best compromise would be to use the C libraries in Zig, but I have years of experience working with C so what's the real gain ya know? Maybe I just need to man up and make a choice already.
Jeremy Falcon
|
|
|
|
|
Just out of curiosity, is Zig binary compatible with C? Can it do COM?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Richard Andrew x64 wrote: Just out of curiosity, is Zig binary compatible with C? Can it do COM?
Keep in mind I'm still new to it, but the short answer is yes.
From a pure binary perspective it'll be 100% compatible with clang or any compiler using LLVM. There are talks in the future to replace LLVM, but that's no biggie as it'll still support C ABIs. One of the core features is you can easily use a C library in Zig and you can easily use a Zig library in C. So, even if LLVM is dumped, that'll never change.
As far as COM goes. I haven't used Zig on Windows yet, but in theory as long as there are C bindings for COM, you can use it in Zig. You can use the Win32 API, so it should work.
Besides the little tiny "oh that's cool" things, the two biggest sales pitches to Zig are interoperability with C and comptime (which is waaaaaaaay nicer than macros).
Jeremy Falcon
|
|
|
|
|
I agree that interoperability is crucial. Microsoft certainly thinks so. That's why they put so much effort into making Platform Invoke work so well.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
