Hacker News new | ask | show | jobs
by skrebbel 2390 days ago
Obligatory name-drop: Zig is an awesome low level programming language targeting the same space as C and CForAll. It isn't at all compatible with C on the source level like CForAll is, but it does make it super easy to interop with C, because it can include .h files. That means it lets you move projects from C to Zig file-by-file. Because Zig benefits from decades of insights about how C could've been better, it has way fewer footguns and higher productivity.

Obviously CForAll has a learning curve advantage over Zig, being based on C directly, but for any readers not aware, I'd say, also check out Zig.

https://ziglang.org/

4 comments

I second the props for Zig. It's basically a really well designed, trimmed down C with "compile time values" that, as an emergent phenomenon gets generics, and composable allocators.

C interop is beautiful. My primary language is on the Erlang Virtual machine, and it's easier to write FFI using Zig than it is to write it in C.

Now that is an interesting combo.
if that combination is interesting to you, this is what I'm working on (on the side from my main job):

https://github.com/ityonemo/zigler

Oh, nice, I will definitely try that. Nifs in C are an eyesore and a risk, having more language options there is good and a clean integration like this is even better.
Just FYI I recommend waiting till I 0.1 it, which will definitely happen before end of January, when I'm giving a talk. I haven't tested that it works as a library yet, much less with elixir releases (it works self contained).
Ok. Even so, very nice development, this is exactly how I think it should be done, most other dual-language environments where you use one language for structure and another for speed tend to completely lose the context of the code for the optimized part. Having them blended in like this ensures that they are viewed as a whole rather than as two loosely coupled parts.
Have been doing this years Advent of Code in Zig because I've been exited to try it out for a long time now. After over the first bumps I really like how it keeps most of the simpleness and clearness of C while fixing a lot of annoyances. The really simple to grok but still incredibly powerful comptime idea is a good example. It adds generics and a much saner macro language without making something too complex or hard to understand. I still have great hopes for languages like Rust in the system programming area because of the guarantees it gives at compile time but when it comes to minimalism zig feels like a much better choice. I would really like the Std lib to be better documented though but I hear that is in the works.
Another (agruably better) option is to use Dlang's betterC feature.

https://dlang.org/spec/betterc.html

Zig is, however, unsuitable for interactive media or scientific computing due to the unfortunate lack of operator overloading (which is touted as a "feature"), rendering it less general purpose than I'd like.

Other aspects of its design look good however.

Im not super sure what specific use case you are after but are you sure you can't do this in some ways with comptime generics? I have to be able to do most generic-like stuff with comptime (though I sometimes have to change the implementation a bit). I also really value how clear the lack of overloading makes the language. This way of clearly being able to follow the control flow is one of the things I like that they kept from C.
Yes I've tried zig a fair bit and the lack of operator overloading made the use untenable. The "ability to follow control flow" is, IMO, a silly argument. I will concede that `comptime` is a nice feature.
It is obvious how operator overloading makes scientific computing easier but what about interactive media? Can you clarify?
Oh so like, dual quaternion skinning, spherical quanternion interpolation, matrix multiplication, vector sums, etc.

I use a ton of linear algebra, vector algebra, and grassmann/clifford algebra at work and not having operators is like... why would I ever do that to myself. You end up in "parentheses" hell for things that would actually be nicely coded in concise and easy-to-understand expressions.

You can use syntax of the form vec1.add(vec2), which is still better than add(vec1, vec2)