Is Zig suitable for scientific programming?

[gritty marten]

Is it too low level? How much does absence of operator overloading impact? I certainly know Zig works very well with existing C libraries. But can someone with experience implementing some sort of complex mathematical model say something about usability of other aspects of the language?

[wary tinsel]

It's very good at the performance aspect, but scientific folks tend to prefer stitching together low level bits of code using higher level languages like Julia or Python

Since those languages are a bit easier to use and have operator overloading etc, which makes mathsy code more readable

So personally I'd say use a higher level language, then rewrite portions of the code in Zig if you need more performance

[gritty marten]

So, I am evaluating Zig for an application where only some part is scientific compute code, and wondering if the system reaches some amount of complexity Rust might be a better choice

[hoary shard]

Generally all scientific computing happens in languages that are even higher than Rust or zig

Only the processes happening in low level for performance reasons

[gritty marten]

Yes, I know. For prototyping or publishing papers, I'd use Julia

But I am looking to make a game where a significant portion is scientific computation. So I need a language (that is not C++) that can do well on graphics, IO, interfacing with existing API, and scientific computing

[hoary shard]

You don't

You need to pick and choose

[gritty marten]

Zig does an excellent job in interfacing with APIs, and I can get Vulkan working pretty easily. So I am looking at Sci comp

[hoary shard]

It enters in how much you want to get involved with this scientific computation thing

For computation I'd say

go for it

is mostly C or C++ with C bindings

But if you care for ease of computation and such, a language for it might be needed

[odd cave]

Zig is a joy for math stuff, but less so for tinkering with complex threading or complex (tree-like) memory stuff.
I'm not sure how your model code will look like and how much control over memory vs ease of memory handling and threading you need.

[gritty marten]

Well, let's take something simple: a rigid body simulator (with some added conditions, etc). This would probably need to build and modify sparse matrices, solving systems of equations, integration through time, etc.. The actual solving can probably use one of the thousand existing libraries out there, but I would really like to know if Zig provides enough abstraction to do the rest of computation, those "glue" part before and after using a mathematics API ergonomically. Of course I know Zig can do it because C also can. I am just not sure if it would be harder than necessary.

[hoary shard]

as long you are happy with strings

[gritty marten]

Strings are fine. What's the matter about them?

[hoary shard]

You can use comptime to interpret strings as formulas and such

[gritty marten]

Well that would be like implementing another language on top of Zig

[hoary shard]

Sadly this adds on build time

[hoary shard]

It's the only abstraction that looks mate-y for people that I can think of

if you don't mind a.solve(b) or a.inv() and a.sum(b)

and such

[odd cave]

Probably you should just try it for a small representative problem.

[true wind]

Honestly, Odin might interest you more for stuff like that, because it supports array programming (infix ops on arrays), builtin matrices up to 16x16, and .xyw GLSL-style swizzling syntax on arrays of up to 4 elements.

[hoary shard]

probably

[gritty marten]

Interesting, but can it use C libraries well?

[true wind]

Yes. Odin is a systems programming language, just like Zig is.

While it doesn't have C autoimport, Odin comes with several C libraries 'vendored' as Odin packages that you can just import, including SDL and CGLTF, so you might already have what you need anyway.
But, if you really need to bind something yourself, there are third-party tools that can translate C headers similarly to how Zig's builtin @cImport works.
It's also not that hard to manually write bindings, and it's not like you necessarily need to bind literally everything up front, anyway.

As a related aside, you also don't need to tell it what to link when you build, because the source code already tells it; where symbols come from are associated with its equivalent of Zig's extern declarations, which means that you don't have to provide that information on the commandline.

[gritty marten]

I see. Though I had two reason in using Zig, one being the C import, other being comptime

[true wind]

Remember that the way cImport works is that it reads the C header, and generates a Zig file with the equivalent extern declarations, and types.
This is identical to what the binding generator tools for Odin do.
So there's not really any difference there.

As for comptime, that is more understandable, since Odin has more much limited CTE. But, you'd be surprised how much you don't really need it in practice.
I realise that may not sound very appealing, but I would suggest experiencing that before being set on it entirely; there's a good point to be made there. 😄
Plenty of those that use Odin do not really miss it.

[gritty marten]

Well the thing I am really worried is reports of Odin not having a working debugger. This is absolutely unacceptable when I am dealing with Vulkan at its lowest level.

[true wind]

Odin does have working debuggers, because like Zig, it just uses the same debuggers as C.
The quality of the debug info is comparable to Zig though.

[gritty marten]

Yes, I know this. I am seeing reports that it does not generate debug info properly and crashes gdb.

And I don't see reports about this being fixed

Built in AoS-SoA conversion and matrix ops do seem nice.

[true wind]

Like I said - there's comparisons I could make to Zig there.
But I agree that Zig's is better.
The main problem is that LLVM is quite a tough beast to work with, and nobody using Odin wants to touch it with a ten foot pole apart from Bill. 🤣
If someone who knew LLVM could spend a week rewriting debug info generation, then that would probably go a long way.

That will improve with time though; there's plans that will address that.

Fact is, LLVM is something of a black box that if you do something wrong it largely just crashes without telling anything - and there's not much documentation to tell you how you actually should do stuff like debinfo generation, so you kinda just have to guess.

[gritty marten]

Well, I am already treading extremely lightly with Zig...

I have only ever read DWARF info, never written it (in code)

[odd cave]

I think its more like a moving target so you have to be active in community chat and know the kinks and whom to ask.

[true wind]

Odin people have tried engaging over there IIRC, and didn't really get very far, from what I remember.

[odd cave]

Also there are debug assertions.

[true wind]

The current thought is that even using LLVM directly was a mistake 🤣

Bill considered writing his own backend originally, but thought that LLVM was wiser. Turns out, it doesn't almost nothing for you, beyond very broad strokes, and isn't really built for you to use it. As odd as that may sound.

Bill is constantly having to work around calling convention bugs, for example, because LLVM just doesn't do the right thing.

That's his impression at least.

And that's before you get to the part where even though it has a C API, they don't care if they break it, and break it damnnear every release. 🤣

[gritty marten]

Don't you usually generate LLVM IR?

[true wind]

We use the LLVM C API.

Odin used to generate the LLVM IR textually, but switched to using the actual API some years ago.