Why wouldn’t Zig be applicable anywhere where c is applicable? Afaik it can also compile to C as a target other than the many architectures it supports.
That's not released or finished, last I checked a few weeks ago.
Edit: Oh, looks like it was released just a few days after I last checked; ha. Although, it's not clear to me whether it's intended for end-user use yet.
Nim is elegant, relatively safe, and not interpreted; its performance is within a stone's throw of C, and roughly on par with Zig; but with better safety guarantees.
As I've said somewhere else, don't think in terms of languages but in terms of use cases. Nim can make a lot of sense for some cases where C is used, and not much for others. The same is true for Zig. There is no and there will never be a "C replacement", just other options depending on what you are doing.
My two cents as a non-professional programmer: i've found hacking on someone else's codebase to be very hard with/without a debugger in dynamic languages like JS/Python where most things are untyped and you get runtime exceptions upon eg. trying to call a method on a nil object.
BUT back on the thread's topic, since i started programming in Rust, the only time i've felt it was hard to wrap my head around the compiler's output was with complex async programming. Otherwise, every single time i felt like a simple text editor was more than enough with rustc's output to understand what's going on, because in Rust everything is very explicit and statically typed with clear lifetimes, and the compiler has very helpful error messages often including suggestions on how to fix the error.
For me, everything (non-async) Rust is a clear win in terms of understandability/hackability, compared to all other languages i've tried before (admittedly not a lot of them). I think complex IDE tooling can ease the pain, but proper language design can help prevent the disease in the first place.
EDIT: i should add, since i started programming in Rust, i've only once or twice seen a runtime panic (due to array indexing error on my side). Otherwise, literally all of the bugs i had written were caught by the compiler before the program ran. For me it was a huge win to spend one more hour to please the compiler in exchange for spending days less debugging stuff afterwards.
While I use scripting languages when needed my main languages were always compiled with static typing. And I did not need debugger for hacking code. I need debugger mostly for tracing my own code when I have some bugs mostly related to algorithmic errors, not with the program blowing up on me.
I did not program in Rust so I can not really judge the language but I doubt that it is so nice and expressive comparatively to modern C++ that suddenly the types of bugs I am hunting will magically disappear.
> I need debugger mostly for tracing my own code when I have some bugs mostly related to algorithmic errors, not with the program blowing up on me.
Then you're a much better programmer than i am! :)
For algo debugging i just use pen and paper. For more surprising results, print statements are usually all i need.
> suddenly the types of bugs I am hunting will magically disappear
Maybe not, but i'd recommend to give it a try, if only to offer a different perspective. For me personally, strict and expressive enums, mandatory error handling and Option/Result types as language core features (among others) have definitely eliminated most bugs i write. Well i still write those bugs, but at least the compiler doesn't compile like everything is fine, and instead lets me know why my program is flawed.
Oh, you mean target architectures. But stuff like SuperH is used only for embedded these days, where even C is often rather idiosyncratic. For most coders, Zig is comparable to other mainstream languages in terms of supporting mainstream platforms.
Anyway, this is really a matter of implementation, not a language issue. There's nothing about Zig that makes it inherently impossible to support SH2 or any other platform - indeed, as others have noted, they already have a C backend in the works, so the endgame is to support everything that has a C compiler.
Also, as far as C interop goes, if I remember correctly, Nim can't just take a C header and expose everything declared in it - you still have to manually redeclare the functions and types that you want in Nim, no? You can use c2nim, of course, but that's not really any different than generators for other languages, and requires extra build steps etc. Zig handles it all transparently.
> Anyway, this is really a matter of implementation, not a language issue.
I think separating the two is a bit artificial. Python being slow is partially an implementation issue but the fast implementations can't run everything. When you compare languages, you have to compare implementations, otherwise it's meaningless.
You have to compare ecosystems, but when doing so, you still have to compare PL design and PL implementation separately, because they have different implications. A quality-of-implementation issue means that something can be done, but isn't done by this particular implementation. A language limitation applies to all implementations.
That's not really true, you can go around language limitations. Go has codegen for generics, JavaScript has TS for static types, Babel for """macros""". Lots of propositions that are not in JS now can be used with Babel. Python has C extensions.
TypeScript is a different language from JavaScript, and C is a different language from Python, so I don't think those are good examples. Similarly, various macro languages that sit on top of something else are also languages in their own right.
And sure, you can always "fix" a language by designing a derivative higher-level language that transpiles into the old one. In fact, this is a time-honored tradition - C++ was originally just such a transpiler (to C). But the very fact that you have to do this points at the original design deficiencies.
> Anyway, this is really a matter of implementation, not a language issue.
That's kind of what people are getting at in this whole conversation though isn't it, ecosystems around languages matter. They can't be an afterthought.
Of course - which is exactly why Zig is not ignoring this. But we still have to compare apples to apples, and oranges to oranges. My original comment was about languages - specifically the ability of the language to consume libraries from another language with minimal hassle, and the response was that Nim somehow does it better.
I'm not even sure why arch support was brought up in this thread, to be honest, because it's not relevant at all? If your problem is unsupported architecture, it's a blocker long before you need to use any libraries...
