5 ms·

Nim does it better, it can be used anywhere C can; zig cannot.

Zababa 5y ago
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.
FpUser 5y ago
The first thing I look when working with any language excluding shell scripts is interactive debugging from IDE.
- pjmlp 5y ago
  And in languages that try to replace C++, better offer nice IDE tooling as well. https://devblogs.microsoft.com/cppblog/edit-your-c-code-while-debugging-with-hot-reload-in-visual-studio-2022/ https://devblogs.microsoft.com/cppblog/edit-your-c-code-whil... https://uecasts.com/courses/unreal-engine-5-introduction/episodes/unreal-engine-5-live-reload https://uecasts.com/courses/unreal-engine-5-introduction/epi... With VC++ and Unreal catching up with Lucid Energize[0], others will have to up their game. [0] - https://www.youtube.com/watch?v=pQQTScuApWk https://www.youtube.com/watch?v=pQQTScuApWk
- southerntofu 5y ago
  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.
  - FpUser 5y ago
    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.
    - southerntofu 5y ago
      > 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.
kaba0 5y ago
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.
- dleslie 5y ago
  Zig did not compile to C, yet, and so is restricted to llvm's targets.
  - jedisct1 5y ago
    Zig's stage2 compiler has a C backend https://github.com/ziglang/zig/blob/master/src/codegen/c.zig https://github.com/ziglang/zig/blob/master/src/codegen/c.zig
    - dleslie 5y ago
      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. https://github.com/ziglang/zig/releases/tag/0.8.0 https://github.com/ziglang/zig/releases/tag/0.8.0
      - dleslie 5y ago
        Self-Reply addendum: on Discord the devs claim it's nowhere near ready for general use.
  - Zababa 5y ago
    I think you can compile Zig to WASM, and then it's just a matter of finding a WASM interpreter/JIT in C.
    - dleslie 5y ago
      ... That would be terrible on, say, the Sega Genesis or 32X.
int_19h 5y ago
Can you give some specific examples?
- dleslie 5y ago
  SH2, which lacks llvm support but has C compilers available.
  - int_19h 5y ago
    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.
    - Zababa 5y ago
      > 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.
      - int_19h 5y ago
        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.

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.

FpUser 5y ago

The first thing I look when working with any language excluding shell scripts is interactive debugging from IDE.

pjmlp 5y ago
And in languages that try to replace C++, better offer nice IDE tooling as well. https://devblogs.microsoft.com/cppblog/edit-your-c-code-while-debugging-with-hot-reload-in-visual-studio-2022/ https://devblogs.microsoft.com/cppblog/edit-your-c-code-whil... https://uecasts.com/courses/unreal-engine-5-introduction/episodes/unreal-engine-5-live-reload https://uecasts.com/courses/unreal-engine-5-introduction/epi... With VC++ and Unreal catching up with Lucid Energize[0], others will have to up their game. [0] - https://www.youtube.com/watch?v=pQQTScuApWk https://www.youtube.com/watch?v=pQQTScuApWk
southerntofu 5y ago
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.
- FpUser 5y ago
  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.
  - southerntofu 5y ago
    > 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.

kaba0 5y ago

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.

dleslie 5y ago
Zig did not compile to C, yet, and so is restricted to llvm's targets.
- jedisct1 5y ago
  Zig's stage2 compiler has a C backend https://github.com/ziglang/zig/blob/master/src/codegen/c.zig https://github.com/ziglang/zig/blob/master/src/codegen/c.zig
  - dleslie 5y ago
    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. https://github.com/ziglang/zig/releases/tag/0.8.0 https://github.com/ziglang/zig/releases/tag/0.8.0
    - dleslie 5y ago
      Self-Reply addendum: on Discord the devs claim it's nowhere near ready for general use.
- Zababa 5y ago
  I think you can compile Zig to WASM, and then it's just a matter of finding a WASM interpreter/JIT in C.
  - dleslie 5y ago
    ... That would be terrible on, say, the Sega Genesis or 32X.

int_19h 5y ago

Can you give some specific examples?

dleslie 5y ago
SH2, which lacks llvm support but has C compilers available.
- int_19h 5y ago
  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.
  - Zababa 5y ago
    > 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.
    - int_19h 5y ago
      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.