Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig 0.11

ziglang.org

Post reply on HN
Print view View original

181–190 of 193 posts

Re: Zig 0.11

#181

Post by bsder »

tialaramex wrote: post #144
bsder wrote: post #72

Earlier quoted context omitted.

Zig has a decent chance of being an actual embedded device (ie. no operating system) programming language. In my opinion, Zig seems likely to grow the necessary bits to be good at embedded while Rust is unlikely to figure out how to shrug off the clanky bits that make it a poor fit for embedded devices. However, I'm a personal believer that the future is polyglot. We're just at the beginning of shrugging off the C AB…

> clanky bits that make it a poor fit for embedded devices. What do you see as "clanky bits that make it a poor fit" for such a broad range of stuff as "embedded devices" ? Embedded goes at least as far as from "It's actually just a Linux box" which is obviously well suited to Rust, to devices too small to justify any "high level language" where even C doesn't really fit comfortably. Rust specifically has no ambition…

Example clanky bit: memory ownership rules.

There are lots of systems where memory changes hands. Game programming, for example. You allocate a big chunk of memory, you put some stuff in it, you hand it off to the graphics card, and some amount of time later the graphics card hands it back to you.

Rust gets VERY cranky about this. You wind up writing a lot of unsafe code that is very difficult to make jibe with the expectations of the Rust compiler. It's, in fact, MUCH harder than writing straight C.

Example clanky bit: slab allocation

You often don't really care about deallocation of objects in slabs in video games because everything gets wiped on every frame. You'd rather just keep pushing forward since you know the whole block gets wiped 16 milliseconds from now. Avoiding drop semantics takes (generaly unsafe) code and work.

Re: Zig 0.11

#183

Post by djur »

jedisct1 wrote: post #128
tarcio wrote: post #5

What are the use cases for zig? The website says general purpose and tool chain but people who have used it, what it excels at?

For WebAssembly, Zig really excels. It's very memory efficient, everything compiles of the box to WebAssembly (freestanding or wasi), the resulting code is compact and fast, and it can take advantage of the latest WebAssembly extensions (threads, SIMD, ...) without any code changes. If you are using a webassembly-powered cloud service and not using Zig to write your functions, you are wasting money. Seriously. Unsurp…

Your link is really interesting, but it shows that Zig was the most popular language for writing games for a WebAssembly-based fantasy console with constrained resources, not that it's the most popular language for WebAssembly-based games overall.

Re: Zig 0.11

#184

Post by throwawaymaths »

packetlost wrote: post #164
DeathArrow wrote: post #31

Earlier quoted context omitted.

What advantages does Zig have over C?

Namespaces. Real enums, modules, etc. A compile-time execution system (effectively replaces the preprocessor/macro system). Syntax that is easier to `grep -r` for without complex regex. Tests are a first-class citizen. Safer type system. Really, just a bunch of things that should've been added to C 20 years ago.

Zig is very pedantic about how you're using your pointers and arrays, which c desperately needed.

Re: Zig 0.11

#185

Post by throwawaymaths »

captainhorst wrote: post #56
msavara wrote: post #7

Anybody here who is using zig on daily basis?

I use Zig for all my hobby projects: - A pixel art editor https://github.com/fabioarnold/MiniPixel - A Mega Man clone https://github.com/fabioarnold/zeroman - Zig Gorillas https://github.com/fabioarnold/zig-gorillas And most recently I had the opportunity to build a visualization for TigerBeetle's database simulator: https://sim.tigerbeetle.com Before I was using C++ and Zig has been an improvement in every way.

How did you not name that zigorrilas?

Re: Zig 0.11

#186

Post by throwawaymaths »

grumpyprole wrote: post #23

Zig is not memory safe and therefore at risk, just like C/C++, of future government legislation that outlaws the use of memory unsafe languages for some or all projects. The risk of such legislation is not insignificant: https://www.itpro.com/development/programming-languages/3694... Personally I do not see the point of building an entirely new language and ecosystem that does not fully address this issue.

Someone will eventually build a static safety checker for zig. No reason memory safety has to be in the compiler.

Re: Zig 0.11

#187

Post by throwawaymaths »

lmm wrote: post #33
quic5 wrote: post #28

Earlier quoted context omitted.

That totally misses the point of quality software. What good is memory safety if you medical device crashes because of an out of memory error? What I'm trying to say: There are use cases where areas of safety are required other than memory safety.

There are use cases where safety beyond memory safety is required. But there are no use cases where memory unsafety is desirable, yet alone required.

> But there are no use cases where memory unsafety is desirable, yet alone required.

Operating system bootstraps?

DMA management/volatile driver access?

Doubly linked lists?

Re: Zig 0.11

#188

Post by rafram »

richardwhiuk wrote: post #101
bsder wrote: post #80

Earlier quoted context omitted.

I retort that almost all of the concurrent data structures are obnoxious to represent in Rust. A lock-free ConcurrentHashMap, for example, is by no means a straightforward data structure in a non-GC language. Even if you somehow dodge Rust's pedantry, you still have to figure out who owns what, who pays for what and when they pay for it--and there are multiple valid choices! Non-GC allocation/deallocation in concurre…

You should always know who owns some data, even if you aren't using Rust!

Garbage collection means the VM owns it! And that’s great. How it should be.

Re: Zig 0.11

#189

Post by tialaramex »

bsder wrote: post #181
tialaramex wrote: post #144

Earlier quoted context omitted.

> clanky bits that make it a poor fit for embedded devices. What do you see as "clanky bits that make it a poor fit" for such a broad range of stuff as "embedded devices" ? Embedded goes at least as far as from "It's actually just a Linux box" which is obviously well suited to Rust, to devices too small to justify any "high level language" where even C doesn't really fit comfortably. Rust specifically has no ambition…

Example clanky bit: memory ownership rules. There are lots of systems where memory changes hands. Game programming, for example. You allocate a big chunk of memory, you put some stuff in it, you hand it off to the graphics card, and some amount of time later the graphics card hands it back to you. Rust gets VERY cranky about this. You wind up writing a lot of unsafe code that is very difficult to make jibe with the e…

I see, so by "embedded systems" you meant a video game console ?

Re: Zig 0.11

#190

Post by lylejantzi3rd »

captainhorst wrote: post #56
msavara wrote: post #7

Anybody here who is using zig on daily basis?

I use Zig for all my hobby projects: - A pixel art editor https://github.com/fabioarnold/MiniPixel - A Mega Man clone https://github.com/fabioarnold/zeroman - Zig Gorillas https://github.com/fabioarnold/zig-gorillas And most recently I had the opportunity to build a visualization for TigerBeetle's database simulator: https://sim.tigerbeetle.com Before I was using C++ and Zig has been an improvement in every way.

That mega man clone is great. The movement feels exactly how I remember mega man 3 feeling. You absolutely nailed it. I also appreciate how you've set up the code, with the build script being written in zig. I checked the code out, compiled it, ran the web server and bam! It just worked. It doesn't seem like that should be a big deal, but competence is such an exotic bird in these woods that I appreciate it whenever I see it.
Post reply on HN