What N64 code are you working on? I am intrigued.

Current progress is here: https://fsl.yellowapple.us/zig64/dir?ci=trunk

Right now it's just a bunch of WIP Zig interfaces for the N64's hardware, but the end-goal is to get it developed enough for homebrew gamedev.

Wow - will follow. Awesome!

> 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.

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.

> 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.

> 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.

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()) ...

I also choose Perl most of the time, but I think this is the first time I've ever heard anyone call it super nice to read

My Perl code is super nice to read. :D

My perl code isn’t. But neither is my Python, or Java, or C, or JavaScript or bash or anything.

Clearly the problem is all these languages, and not me.

Could be... or readable by who, who do not know these languages at all? :P

I've heard it called a "write-only language"

It's more readable than C++, C or Rust though

100% depends on how it’s written. It gives a ton of flexibility regarding incorporating “magic variables” which can lead to incredibly abstruse code. The language motto is “there’s more than one way to do it”, and that’s implemented to a fault.

Same with C or C++. Only recently there came up some examples of well-written C++ code. But most of old cooperate, Microsoft or Stroustrup code is just horrible, worse than hard-core perl nonsense.

Real Programmers can write FORTRAN in any language.

Making a large code base easy to read is very hard. People often work on tiny code bases and talk about how easy it is to read, not understanding that they are comparing something with a couple thousand lines of code to something with tens of millions.

> Only recently there came up some examples of well-written C++ code.

I'm not sure what you're referring to (link?) but note that whether C++ code is good or bad can depend strongly on the tooling. Certain coding patterns can be fantastic when your tooling can adequately detect their misuse, and awful when it doesn't. Which means sometimes you can't tell just look at code and tell whether it is good or bad.

> But most of old cooperate, Microsoft or Stroustrup code is just horrible, worse than hard-core perl nonsense.

I got the impression Microsoft's C code was always pretty good, their C++ not so much a decade ago - not sure how their C++ is now.

Paraphrased quote from one of my professors years ago:

Writing readable perl is easy, just code it like it's LISP.

Granted, he was working with it in AI/bioinformatics.

One of my classmates who moved into the IT/management side of things historically got much quicker responses from the dev team whenever he volunteered to code something, as he was always going to do it in perl.

So true.

Perl with list comprehensions do look a bit like line noise...

https://en.wikipedia.org/wiki/Comparison_of_programming_lang...

... but not really worse than most other languages there.

By contrast, its "higher order functions" are useful but relatively speaking, read like someone shook a box of leftover syntax all over them.

https://en.wikipedia.org/wiki/Higher-order_function#Perl

Even though C# has a seizure in the middle, Perl still seems the clunkiest.

Depends on who wrote it. My own Perl code, and plenty I've seen, is extremely clean and readable; sadly, a lot isn't. I'm sure clean and readable C++ exists, but the stuff I have to work with - big codebases with tons of history - is not. "Terrifying" would be more apt in most cases.

The Perl code I write today is much cleaner and easier to follow than what I wrote 30 years ago. I hope that's true of my programs in other languages too.

They call it like that, but it depends on the programmer as always. The problem is, that it is really flexible, more so than python or javascript, so it gives you all the tools to shoot yourself in the foot and take away the leg with it.

An example, you can rewrite the calling program in a module.(https://metacpan.org/pod/Acme::Bleach orhttps://metacpan.org/release/DCONWAY/Lingua-Romana-Perligata...)

While cool for jokes or serious DSL's, it may lead to difficult to understand code. (Nothing wrong with Damian Conway btw, I just remembered he used source filters in interesting ways).

> They call it like that, but it depends on the programmer as always.

There are different styles, but in general they are concise, and I like them.

perl use various sigils to remain concise, while other languages take a lot of room on the screen: too many letters in the usual function names, not enough sigils within the language.

It's like if everything was in binary or hex, instead of using the full range of ASCII: while technically possible, it may be harder to fit into your head

Python has one sub-style I dislike the most: using tabs for indentation, because how much EXTRA room they use on the screen.

It must not just be me, as there are solutions for coloring the spaces (I forked https://github.com/csdvrx/indent-rainbow to focus on black-and-white and using spaces instead of tabs)

I use space to limit the issue, but I can't make python less verbose.

> it gives you all the tools to shoot yourself in the foot and take away the leg with it.

python isn't innocent either: I recently traced a issue where exit(0) wasn't working to a threading problem, making a bad use of atexit.

> tabs for indentation

I don’t know a single Python project that does it. You can’t mix space and tabs for indentation.

4 spaces is the default for Python formatters like black, ruff (not sure whether it is configurable—never tried to change).

Big indent is a feature—deep nesting is a code smell.

> Python has one sub-style I dislike the most: using tabs for indentation, because how much EXTRA room they use on the screen.

Can you not adjust your tab stops?

I hate it too, because tabs look like spaces and they have a different syntactic meaning

I can, in vim it's simple. It just bothers me that it is the default and I have to take care of tabs with the rainbow, or a toggle shortcut like:

function TabCollapse_Toggle() abort

    if &tabstop ==1

        set tabstop=8

    else

        set tabstop=1

    endif

 endfunction

BTW if you hate tabs looking like other characters and other invisible characters (like spaces at the end of line, non breaking spaces...), I have a solution in CuteVim (https://github.com/csdvrx/CuteVim : just run the portable executable) where I mapped it by default to a Fxx key

If you already use vim, here's the relevant part: assuming your Shift-F11 is free, add to your vimrc:

" Default is off, `se list` to turn on and `se nolist` to turn off

" Traditional with ISO-8859-1:

"set listchars=tab:»·space:_,trail:·,eol:¶

" Or cuter with unicodes:

set listchars=tab:↹⇥,space:_,nbsp:␣,trail:•,extends:⟩,precedes:⟨,eol:↲

set showbreak=↪

inoremap <silent> <S-F11> <Esc>:set list!<CR>

noremap <silent> <S-F11> :set list!<CR>

Shift-F11 will then become a toggle, to show you tabs: you will see ↹ where the tab starts, and ⇥ for how long it is

>Can you not adjust your tab stops?

I've used this in vim for years:

:se expandtab tabstop=4 shiftwidth=4

(those can be abbreviated, check docs)

Then:

I use only tabs for indentation.

All the tabs get expanded to four spaces each.

Indenting and unindenting lines or blocks of lines, moves them by four spaces.

Never had a problem.

Maybe there are more fancy ways, but this works fine for me.

> I use only tabs for indentation.

> All the tabs get expanded to four spaces each.

Then Python will not work (?)

Sure it will work. Even before I discovered this method (which is simple), I was using four spaces typed manually, for indentation in Python, for years.

Maybe it is you who "will not work".

Did you try it before commenting? I already said it works fine.

e.g. for tabstop, use ts, and for shiftwidth, use sw.

Also called executable line noise, like Python is called executable pseudocode.

But I like Perl (and other languages) too.

Variety is the spice of life.

> I've heard it called a "write-only language"

A frequent opinion. Easy way to fit in for people who never bothered to learn the language. Which is all the more sad that Perl is super easy to learn (one layer at a time).

Maybe he's used to K?

The joke used to be that Perl code looked like an explosion in an apostrophe factory.

I once accidentally piped an SSL certificate into Perl and got 40+ warnings before it realised it wasn't Perl. I'm not joking.

That's why Larry Wall said he'll be certified before Perl is (when asked about the prospect of standardizing the language).

It's one of his well-known quotes.

https://quotefancy.com/quote/1497280/Larry-Wall-I-think-I-m-...

I posted a link to many of his quotes:

https://news.ycombinator.com/item?id=43287809

Now try piping Perl into itself. #@$%&^*!

A homopipic / homeopathic language?

Similiia similibus curentur.

https://www.google.com/search?q=similia+similibus+curentur

It may looks chaotic ("explosion") when you don't see the structure.

When you do, you appreciate the density of information.

When I read perl it's like I read a poem: to take a simple example, 'while/until' instead of 'while/while not' creates more beautiful code

Or executable line noise (I think I heard that one from slashdot)

Larry Wall has said he likes parenthesis in his LISP like he likes fingernails in his oatmeal. xD Hence, Perl's abilit to forgo parens in many cases.

Or like an explosion in a sigil pottery :)

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

I like perl, because the code i wrote 20 years ago still works without issues.

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!

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.

> 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.

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

Sadly the job market looks dead

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 :)

What’re you doing with Zig and N64? Sounds awesome.

Eventually, I hope to use Zig for N64 homebrew.

To get there, though, I need to implement Zig-ish interfaces to the N64's hardware, which is slowly-but-surely happening at https://fsl.yellowapple.us/zig64/dir?ci=trunk