szanni

I am rather surprised the article does not mention the shared hunting technique of pursuing prey until exhaustion as a possible link.

Many hunter gather tribes apparently employed this technique and it can still be found today in Africa with the San people.

Sharing food or stealing wolf puppies were probably part of the domestication but was this because humans possibly hunted alongside wolves? Humans possibly being capable of pursuing for longer distances due to better body temperature control through sweating while wolves being better at tracking.

At least that would be my take.

I would love to see that too, but believe this is rather unlikely for any major Linux distro. Why? Because there is no guarantee the required kernel symbols will stay available.

This has for example happened with the linux-rt branch that decided to change the license of some of the exported kernel symbols to GPL, which prevents the ZFS module from compiling.

As far as I can tell, the kernel developers make sure to not break user space but no such guarantees are given for the kernel modules. Having the driver for your root file system possibly not compile on the next kernel update seems like a nightmare to support for any distribution.

>If I may, my only piece of feedback (as someone who looked at Zig with fresh eyes) is that the syntax has lots of special chars (@, !void, .{}, &, etc). Is there a rationale published for these and other design choices (even if it's "I like it that way"). I would have expected a language with ambitious goals like Zig to take a stab at coming up with a grammar that's even simpler and cleaner than C.

That is sadly my gripe with a lot of the newer languages too. I have been looking for something to replace C for a long time, something that makes it easier to not shoot yourself in the foot. I just find most of them significantly less readable than C.

Rust seems to be going down the route of C++, hence I do not deem it a safe language at all, as I have an exceedingly hard time parsing the source and figuring out what is going on.

Zig is WAY better in that regard, but as OP mentions: all the special characters make things more difficult to parse. Calls like these (taken from the introduction page) contain so much visual clutter:

  try expect(@call(.{}, add, .{3, 9}) == 12);

I sadly doubt any of this is possible to change at this stage anymore. Zig definitely seems the most promising C replacement with regards to tooling, especially cross compiling and C interop are a breeze. Truly inspiring work!

The only new C-like language that really nailed it for me syntax wise would be Nim. Very clean and easy to reason about, which - from a programmer perspective - makes it exceedingly safe to program in. It just seemingly lacks most of the safety guarantees that the compilers of other, newer languages provide.

This looks like a nice and concise library. Single header file, many useful functions, and a usable license. The only thing I really dislike are all of the typedefs.

  zpl_u64 zpl_crc64(void const *data, zpl_isize len);

Const correctness, good! But why is the size parameter signed? Why not use size_t and uint64_t like the C stdlib?

This is precisely the reason: a doctor’s interpretation as well as the liability that comes with it.

Good luck on reading an EKG graph yourself. It is apparently not even easy for a trained doctor to discern what exactly is going on.

Source: I worked on a long term ECG holter monitor sold by GE.