ZIG programming language.

Isoux

Isoux

Is there an affinity to use the ZIG programming language for BSD OS development as well as RUST?

I'm in the middle of gradually rewriting the system C code of my hobby OS to ZIG code. I'm very happy with the "results" and easy implementation of Zig compilation unit to C/C++ projects...
 
I see a syntax resemblance of javascript in example code. I assume that zig is not native/compiled language and that is a big no no is OS development mostly.
 
I so often see these new languages that are like: wow it's C but, the type name comes after the variable name, not before, and look...  colons:
Code: 
myVar :: int;
Imagine. With just a bit of retraining, you too could be using these colons!
Even Google is pumping out this stuff (carbon).
The first I heard of Zig was when I was browsing the issues on www.dwarfstd.org and saw a ticket by Zig's inventor who was sore that Zig wasn't explicitly mentioned and given its own hexadecimal code in the standard, like C and FORTRAN. Lol.
 
ayleid96 said:
I see a syntax resemblance of javascript in example code. I assume that zig is not native/compiled language and that is a big no no is OS development mostly.
Click to expand...
I'm not knowledgeable enough to judge, but it seems to me that the similarity of javascript syntax in the example code at ZIG is to a much lesser degree than at the RUST lang that is slowly entering OS development.
 
Where the variable type goes is not important these days. In the old days, you had single pass compilers which fit in some KB of memory. There it makes sense to not save the type from the beginning of the statement and apply it to all names seen later. You added the names to the list and applied the type later, saving the memory space for the type to keep around the maybe recursive parsing. It makes sense. These days, the language designers think anything goes, and that leads to syntax like javascript or the rest.

ZIG may have it's use, but the benefit for using it seems too small to be an argument for transition of ther code bases to it. The dimishing return does not pay enough here. Development of the system will continue in C where needed, C++ where possible and that will be it.
 
Crivens said:
Where the variable type goes is not important these days. In the old days, you had single pass compilers which fit in some KB of memory. There it makes sense to not save the type from the beginning of the statement and apply it to all names seen later. You added the names to the list and applied the type later, saving the memory space for the type to keep around the maybe recursive parsing. It makes sense. These days, the language designers think anything goes, and that leads to syntax like javascript or the rest.

ZIG may have it's use, but the benefit for using it seems too small to be an argument for transition of ther code bases to it. The dimishing return does not pay enough here. Development of the system will continue in C where needed, C++ where possible and that will be it.
Click to expand...
A very well argued explanation!
 
The main problem with new languages is that they need a very big + on their + side to outweight the huge accumulated + every older language has. Heck, even Fortran (as weird as it is) has a HUGE momentum in numerics due to all the math libraries and code already written for it. Or even worse, Cobol (in another realm). You simply can not dethrone that by syntax candy or paradigma alone. C/C++ is so huge it is practically part of the DNA of IT these days. I'm sorry but the cake is eaten when it comes to new languages. You need a really REALLY REALLY big advantage in a new language to shift any amount of usage to it from already existing realms of computing. There simply is not enough free real estate in the language world to create something new and ground breaking. Maybe we will see something new with quantum computing, as they need completely new kinds of description to match their machine model.
 
I am not an expert and have only been learning rust for a few weeks, so I just wanted to chime in with a few things beside what people mentioned here already on the two, because this argument seems to come up a bit in the unix world. I think at this point I've read more articles than I read manuals/code, especially on rust, so not sure what you are aware of.
As for Zig, the language is still way too young for anything production, let alone OS. It's interesting, (and maybe you caught Dave's garage on yt), but it is not even v1 release yet. (I like rust but would switch to it instead if it was on par with Rust atm, for crates, frameworks etc. I'm interested in web frameworks like sycamore and game engines like bevy; not any OS part. And I like bun, nodejs replacement written in zig. )

One issue with rust, although the technical details is beyond my knowledge, is that it has some limitations in favor of safety regarding memory (I believe), which not everyone is thrilled to work with (as in, even working with unsafe or whatever it is that you need to do), to the point that it is not the first article I've seen where people even start to dislike rust or regret starting the project with rust in the first place when they then start having to deal with that area. So, add that to what Crivens said above, about needing a huge advantage to adopt, and you also have to consider what the engineers are happy using. With pure Rust OSes like Redox, the developers seem like fans of the language and willing to go all in, where as with something like FreeBSD, that is not the main purpose or priority.
One positive I have seen though, if it interests you, is with driver development, but I have no idea what gaps that would fill in FreeBSD. There was some debate not too long ago, when rust was still being considering for linux, where one article in favor of rust was explaining how easier it was to write a device driver in rust. Maybe there is stuff that doesn't work on freebsd yet that would be easier to implement (sorry, impl) with any of the two languages.
 
@lsoux I just wanted to add, I wasn't trying to denigrate your hobby OS by disparaging Zig. I know that a solo OS takes an immense amount of work, even more than a compiler, and I'm sorry if it came across that I was detracting from that.
I have an issue with "programmer pride" and I feel this is particularly bad amongst the inventors of languages, and for no good reason...
 
ProphetOfDoom said:
@lsoux I just wanted to add, I wasn't trying to denigrate your hobby OS by disparaging Zig. I know that a solo OS takes an immense amount of work, even more than a compiler, and I'm sorry if it came across that I was detracting from that.
I have an issue with "programmer pride" and I feel this is particularly bad amongst the inventors of languages, and for no good reason...
Click to expand...
Dear ProphetOfDoom, don't worry at all. I did not experience your message so dramatically at all, on the contrary ...

I barely switched from assembler to C language, and to be short, ZIG is defined as a language that is above assembler and below the C, that attracted me as well as that than all C-C++ files can be compiled with ZIG ... Add "a Zig compilation unit to C/C++ projects; cross-language LTO is enabled by default."
I have many other reasons that attracted me, but this is not the place to discuss them.

Maybe my mistake here is that I stated to rewrite the base code in ZIG instead of just leaving the question.
 
I think you're underestimating how difficult is it to write an operating system; let alone a stable, performant one. Then there's drivers..
 
Beastie7 said:
I think you're underestimating how difficult is it to write an operating system; let alone a stable, performant one. Then there's drivers..
Click to expand...
I do not underestimate at all, and how difficult it is to start even a hobby OS with the main goal of learning something, I feel the most painfully on my own skin...

Besides, the beginning of my interest in OS is one of the main reasons why I came here. As well as my enthusiasm and desire to study FreeBSD OS (In my opinion the best OS today).
 
macbias said:
One issue with rust, ...
Click to expand...
As long as such problems are not resolved Rust is a no-go for base-FreeBSD:

github.com

How to deal with breaking changes on platform ? [BSDs related] · Issue #570 · rust-lang/libc

I open an issue on libc because it is here the problems will start to show up. Depending the solution or the way to deal with, modifications could occurs in rustc repository too. At OpenBSD, we don...
github.com github.com
github.com

Drop support for FreeBSD 10 and 11 from std · Issue #89058 · rust-lang/rust

Rust's standard library currently uses a FreeBSD 10 compatible ABI. But FreeBSD 10 went EoL on October 31, 2018. And now FreeBSD 11 will itself be EoL on September 30, 2021. Isn't it finally time t...
github.com github.com
 
Zig is great! Andrew, the creator, seems really smart and I find myself aligning with a lot of his design choices.

I like C a lot, but I typically only use it for smaller projects. Larger projects where I might use C, I would be more comfortable using Zig. I've tried Rust a bit, but it did not spark joy in the way Zig did for me. I don't mind Rust's borrow checker (I think it is a great tool), I just don't like complexity of the language like Traits and such. Zig's allocator design is really interesting in that you can detect memory leaks.

Zig is still in early stages, but I think it has a lot of potential. I'm excited to use it once the package manager lands. Then it will have the convenience of cargo.

It will fit really nicely in userspace, but be more friendly to bootstrapping and packaging than Rust is.
 
Many people want to be inventors. What to invent - programming language. "C is difficult - I will make it easier." And we have the next thing like ZIG. Unfortunately we have also too many (stupid) upgrades of C and especially C++.
 
Since is this not the first time, this kind of question occured,
if to use another language for FreeBSD (had it not so long ago with Rust):

Simple point is:
It doesn't matter, if a language is great/better/...whatever its benefits are,
and which downsides C and C++ have.
Nearly all the source is written in C or C++

If you want to switch to another language,
you'll have to rewrite everything,
which, you guessed right, would be nearly the same,
as writing a complete new OS from the very start.

Otherwise you have two choices:
1. mix up sources from different languages, which is a bad idea for several reasons.
2. stick to the used ones.

Besides that,
after what I figured out from several blogs, and benchmarks (others made),
C still produces the fastest machine code.
For an OS, especially a kernel with multitasking, this is something quite important.
Some may even say #1 priority.
 
6502 said:
Unfortunately we have also too many (stupid) upgrades of C and especially C++.
Click to expand...
I agree. Whilst some replacements are nice languages in their own right, you lose many of the benefits from directly using C.
C++ and Obj-C at least are on the right track in that they are "C with more stuff". However different languages entirely such as Rust and Go with requirements for FFI/binding generators is not going to work in the long run in my opinion. People are going to lose many hours here.

I keep hearing that Zig has direct interop with C but it doesn't look like that is true? If I am missing something and it *does*, then at least that does bring Zig in line with the C++, Obj-C approach of building upon C which I do tend to agree with. Cgo was close with the comment preamble stuff, but not quite.
 
kpedersen said:
I agree. Whilst some replacements are nice languages in their own right, you lose many of the benefits from directly using C.
C++ and Obj-C at least are on the right track in that they are "C with more stuff". However different languages entirely such as Rust and Go with requirements for FFI/binding generators is not going to work in the long run in my opinion. People are going to lose many hours here.

I keep hearing that Zig has direct interop with C but it doesn't look like that is true? If I am missing something and it *does*, then at least that does bring Zig in line with the C++, Obj-C approach of building upon C which I do tend to agree with. Cgo was close with the comment preamble stuff, but not quite.
Click to expand...
The interop isn't quite like C++ where you can drop the file in your project and it is ready to go. However, it is a bit easier than others. You import and then all the functions from that import are available, in other languages this would be a lot more ceremony. In this case the docs aren't too descriptive, but tutorials illustrate it pretty well. Here is an example:


A big benefit is that Zig as a language isn't too different than C so you don't have to constantly fight different abstractions.
 
You must log in or register to reply here.
Back
Top