Comment by yellowapple

2 months ago

I've pretty much settled on Zig at this point, if only for how dead-simple it is to cross-compile for other hardware platforms. The process of compiling working code for oddball platforms (in my case the Nintendo 64) was way easier than I expected it to be.

The only downside is the stdlib being as fast-moving of a target as it is. Right now I've had to put a pin on getting panic stack traces to work on my N64 code because apparently the upcoming release changes a bunch of stuff around panic/stacktrace handling (and it's already changed quite a bit over the years even before these new changes).

53 comments

yellowapple

Reply
archargelod  1 month ago

> how dead-simple it is to cross-compile for other hardware platforms

The fact that zig can compile C code makes it useful for other languages too. I recently started using `zig cc` to cross-compile Nim for lots of different platforms within the same environment.

It takes no time to setup and, honestly, works like magic.

  • Galanwe  1 month ago

    > The fact that zig can compile C code makes it useful for other languages too

    Agree, C interop is IMHO the big feature of Zig. There are plenty of systems programming languages in 2025, but where Zig shines is its pragmatism: a single standalone binary containing compiler, libc, build system, code formatter and test runner for C and Zig.

    As of late though, I've been concerned with some "holy wars"/"ideological postures" that the dev team started which IMHO departs from the original "let's be pragmatic" mantra.

    - There's a bunch of places where the stdlib just crashes on unreachable assertions, and that won't be fixed "because the kernel should have better error reporting".

    - There are a bunch of kernel syscalls which are just not possible to call "because C enums should not allow aliases"

    - etc

    I hope this trend fades away and it gets back on a more pragmatic stance on these issues, nobody wants a systems programming language that plays the programming police.

    Otherwise, C3 looks promising as well (though not as nice than Zig IMHO), but currently it's a bit too barebone to my taste. There no stable LSP, no nvim plug-in, etc.

  • csdvrx  1 month ago

    I like Perl mostly because it's poetic (the code is super nice to read, with variable types standing out thanks to sigils), but another core strength is how very fast and light it is.

    Instead of "cross-compiling" or just running a native perl interpreter (there's one for about every platform!), I prefer how Actually Portable Executables make Perl multiplatform with just 1 binary asset running everywhere!

    I wanted to write a webserver processing CGI to learn more about the "old school web", so I wrote https://github.com/csdvrx/PerlPleBean and the simplicity of just downloading and running the .com on anything is very nice

    I'm now trying to do the same in Python3, but it's not as fun - and I'm not yet to the part where I will try to safely run python code within the python webserver, either through restrictedpython or ast.parse(), ast.walk(), eval(compile()) ...

    • yellowapple  1 month ago

      Perl was my first "real" language, i.e. the first one that actually "clicked" for me. Still holds a soft spot in my heart, even though I don't use it much these days. It's one of the few languages (along with Ruby, Erlang, and Zig) that I feel have made me a better programmer by learning them.

    • phatskat  1 month ago

      Just wanted to say that I really dig your enthusiasm! I read most of PerlPleBean’s README and was smiling the whole time - APE was so exciting to read about when it came out, and your project may just inspire me to look more into what it can do!

    • kamma4434  1 month ago

      Importing stuff fron CPAN used to be a nighthmare but I admit I have a sweet spot in my heart for Perl.

Galanwe  1 month ago

> The only downside is the stdlib being as fast-moving of a target as it is.

Ah that's an interesting take, my opinion is that the stdlib doesn't move fast enough.

In its current state it's pretty broken, most of the "process", "os" and "posix" modules are either straight up raising unreachable in normal scenarios, or simply badly designed. I would like the stdlib to be much more fast moving and fix all these issues, but I had the impression most work on it is frozen until 0.15 or 0.16, after incremental compilation is done.

  • brodo  1 month ago

    You are right, the stdlib is not the highest priority right now. There are major improvements coming in 0.14 though. The new default allocator for example. I think the problem you describe can be solved by having more contributors focussing on the standard library. With the compiler, there are bottlenecks which make onboarding new people hard. This is a smaller problem in stdlib.

    • Galanwe  1 month ago

      > I think the problem you describe can be solved by having more contributors focussing on the standard library.

      I don't think so, my impression is that stdlib improvements are volontarily frozen for now, not because of a lack of contributors but because of a lack of clear plan as to what the stdlib should look like. There are a number of issues and PR of people willing to contribute to stdlib that are stalled.

      That's not to say that's its bad per se, "we don't have a plan for now and don't want people to commit time for an unclear target" is a perfectly OK answer.

epolanski  1 month ago

I'm picking up zig as my first system programming language myself and I love it.

Sadly the job market looks dead

  • azthecx  1 month ago

    It's such a new language, not even in 1.0.0 You won't really find companies willing to bet their livelihoods at such an early stage.

    You can make your own though :)