Serge Zaitsev

Copied from my reply on Lobsters (https://zserge.com/posts/better-c-benchmark/)

---

For what it's worth, we do understand that the lack of stdlib documentation is a problem. Before I expand on that, here's the current "workarounds" to be immediately productive:

https://ziglearn.org is a structured introduction to Zig that covers an introduction to Zig that is very friendly to newcomers. Chapter 2 in particular helps solving common problems and showcases some parts of the standard library while doing so.

On the Zig SHOWTIME YouTube channel there are a few videos that can help. One video in particular is about how to approach the Zig standard library today [1], while we wait for better docs.

Asking for help in a Zig community [2] is so easy it's like cheating, and it's also a door to knowing when new resources pop up.

So, what's up with the stdlib docs? We have an experimental build [3] and, as the name implies, they're incomplete and not considered good. Why are we not working on them? Because the docs are a JS interface to a bunch of metadata generated by the compiler during the build phase. We are currently transitioning to a self-hosted implementation [4] of the compiler and, until it's complete enough, we are stuck with the incomplete and buggy metadata that the current C++ compiler generates. I personally plan to get involved in the docs effort once the situation gets unblocked.

> I wish Zig had a better documentation to gain popularity before it becomes too niche…

A Scheme Machine [1] with plenty code and hardware I just found: 60 pages

The R5RS Scheme specification w/ example code: 50 pages

XML 1.0 specification for structure only: 49 pages

Sun's efficient, binary XDR: 29 pages

Wirth's Oberon Programming Language spec: 21 pages

ECMA JSON specification: 14 pages

Jsmn - portable, JSON parser [2] in C: 7 pages

I'm sure the above illustrates quite well how difficult and complex XML is. Additionally, while students everywhere implement LISP, there's a whole chapter in Beautiful Code where writing a good XML parser is an accomplishment people pay to see. Far from minimal understanding, reading XML's specification is a HOW-TO guide for how non-programmers that haven't seen superior works (eg Scheme, Oberon) try to handle data management. It was horrible, I used s-expressions/XDR instead, and implemented whole thing in a few hundred lines of straight-forward code. Best of all, unlike XML, my code could've run through a tool to prove it free of the types of bugs hackers love to exploit.

So, there's my proof that XML is garbage. Essentially everything it does can be done better by using one or more tools with less complexity, more cost-effectiveness, and more straight-forward implementation. Nobody should waste time learning it. If work demands, they should just learn a library that handles the awful details for them and internally use something else. Also, they should avoid any protocol that depends on it: that's just bad design.

[1]…

I agree with the recommendation here to read Expert C Programming: Deep C Secrets by Peter Van der Linden.

As for practice: the challenge in learning new tech is always to find a small-scale project that motivates you to build something. As a mostly-Rails developer like you I've found a couple opportunities to write C by building Postgres extensions. Here are my two:

https://github.com/pjungwir/aggs_for_arrays/

https://github.com/pjungwir/inetrange

Both of those are used in production systems and had good justification for dropping down to C.

Or here is a tiny patch to the Postgres btree_gist extension that I am hoping to get merged:

https://commitfest.postgresql.org/10/332/

The JSON support in Postgres is still pretty new. Maybe you could write some worthwhile additions for dealing with json or jsonb data? I would just look at underscore.js for inspiration.

Also if you have a collection of personal shell utilities, you could try rewriting them in C. Here is one of mine:

https://github.com/pjungwir/range

It is for printing a range of numbers like `1, 2, 3`. It is surprising how many features you can add to a tool like that! (It is a bit of a joke, and I have since learned bash gives you `{1..10}`. But something similar could still make a good learning project.)

Perhaps you could also write a ruby gem that wraps some C library. For instance I'm fond of the jsmn JSON parser [1]. Maybe a gem built around that could give performance benefits? Or maybe some way to…

Uses under 1.5 MB of memory at any one time (most of it is used for drawing the window).

Unfortunately there is no screenshot and I have no access to a Mac at the moment, but if View.c is where things actually happen, that is a huge amount of memory just for a (resizeable?) window with a little filled rectangle in it. The memory usage of a trivial app like this should be measured in kilobytes.

Comparing applications written in the same language across platforms is IMHO a good gauge of their relative efficiency. From what I've seen, Win32 and Linux (Xlib) are pretty close but Mac is clearly very "think different". I'm sure the liberal use of string constants here doesn't help either.

Here's a related interesting comparison: https://zserge.com/posts/fenster/

Actually, this is similar to what you can do in Java by using lambdas (Retrolambda for pre-Java 8, e.g. Android pre-SDK 24). Excerpt from a blog post [1] about it:

mButton.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
// do something here
}
});

can be replaced with

mButton.setOnClickListener((View v) -> {
// do something here
});

which is nice for all callbacks, but especially together with ReactiveX where they are abundant.

[1] http://zserge.com/blog/android-lambda.html