|
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.
|
|
|
|
|
Richard Andrew x64 wrote: That's why they put so much effort into making Platform Invoke work so well. Only because they put so much effort...
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I challenge your second requirement for regex. Unless your project is a web based regex explainer/tester, regex is a tool and not an end user visible requirement.
|
|
|
|
|
You can challenge it all you want. That means nothing to me.
Now, I'm just gonna assume you're not flat-out lying about this little CTO thing you got in your bio... But, if you reread the post, I mention needing to handle web requests. Now, can you imagine the need to able to parse a body response that many or may not be what you anticipated? Ever use the web before, where people say they're RESTful but they're not... especially in error conditions?
I could go on, but you already missed the entire point of the post man.
Jeremy Falcon
|
|
|
|
|
breath Jeremy.
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.
|
|
|
|
|
|
lol, you are clearly passionate about what you are doing. I recognize the psych profile.
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.
|
|
|
|