Lightpanda migrate DOM implementation to Zig

https://lightpanda.io/blog/posts/migrating-our-dom-to-zig

#HackerNews #Lightpanda #Zig #DOM #Migration #TechNews #ZigLang #WebDevelopment

I found fenster and decided to switch from RayLib.
It's way smaller and exactly what I needed: window with a framebuffer.

So I ported my app to it over the day. So far so good.

Builds: 32KiB Linux, 37KiB Windows - that is 10x reduction!

https://github.com/zserge/fenster

#ZigLang

I'm working on a preview scene. Kinda level editor with layers to preview tile-set.

Finally some challenge as i slow down the engine to few fps... I'm drawing each sprite as 255 individual rectangles. I need to convert them to textures or something.

#ZigLang #RayLib

A short introductory blog post about Fruits & Tails, our little video game.

https://spiffyk.cz/blog/fruits-and-tails/

#gamedev #zig #ziglang #webassembly #wasm #fruitsandtails

A short introductory blog post about Fruits & Tails, our little video game.

https://spiffyk.cz/blog/fruits-and-tails/

#gamedev #zig #ziglang #webassembly #wasm #fruitsandtails

This is interesting. #ziglang has moved to #codeberg.

I really think for open source software, they should be in open source #forges. Basically, use #git to share, not #github. 😉

https://ziglang.org/news/migrating-from-github-to-codeberg/

62 chapter open-source Zig book

https://www.zigbook.net

#HackerNews #openSource #ZigBook #programming #learning #ZigLang

@katafrakt I've updated your zig-ruby example to Zig 0.15.2. I don't use github but the code is here if you are interested: https://codeberg.org/glitchcake/zig-ruby-extension

#zig #ruby #ZigLang

I wonder what it will take to get #rakulang in the top 50 of the Tiobe index. Any thoughts?

For those that say, "a killer app" -- since I know that response is coming -- what is Raku's most likely class of killer app?

Also, congrats to the #ziglang crowd for making it into the 30's. You've earned it! I'm still of the opinion Raku can learn from Zig at the community level.

#KillerApp #programming #tiobe

I wonder what it will take to get #rakulang in the top 50 of the Tiobe index. Any thoughts?

For those that say, "a killer app" -- since I know that response is coming -- what is Raku's most likely class of killer app?

Also, congrats to the #ziglang crowd for making it into the 30's. You've earned it! I'm still of the opinion Raku can learn from Zig at the community level.

#KillerApp #programming #tiobe

The new programming language I'm learning in 2025 is Zig.

I want to use it for Advent of Code this year. If there's no AoC 2025, I'll do the 2023 version, since I was too busy to attempt it then.

I also looked at a few other languages - Gleam, Roc, Odin and Mojo. I might try the first 3 in the coming years. Not interested in Mojo.

I first wrote C when I was 12. I am too scared of memory bugs to write C professionally. I hope I don't run into Segmentation Faults with Zig. 🤞

#ZigLang

👀 Wow, hold your horses! Zig builds are apparently breaking the sound barrier now. 🚀 After years of intense labor and a bit of #LLVM yeeting, they've achieved the unimaginable: a #compiler that might finally compile something before your coffee goes cold. ☕️🔥
https://mitchellh.com/writing/zig-builds-getting-faster #ZigLang #SoundBarrier #FastCompilation #HackerNews #ngated

After almost a week of refactoring and experimenting with several different approaches, I've updated my Zig nD SIMD vector library to be compatible with the latest Zig 0.15.1, and at the same time cleaned up some internals.

The solution I settled on is a mix of techniques proposed by others, and was needed due to the removal of the struct/namespace-merging syntax in the new Zig version, which this library heavily relies on. I don't like that the new source code is now more than 2x larger and involves a huge amount of duplication to address the many special cases of supported operations for different vector sizes and types. I might still take another pass to eliminate those (by using @compileError() for unsupported cases), but that'd be an implementation detail downstream users don't have to care about. I tried AOT code generation as well, but the special case handling made this feel less maintainable...

UPDATE: The only breaking change is the handling of vector swizzles. I had to remove the hundreds of named swizzle functions and replaced them with a single (comptime optimized) .swizzle(vec, pattern), e.g. .swizzle(vec, "xxyy")...

If you're interested, the new code is here:
https://github.com/thi-ng/zig-thing/blob/main/src/vectors.zig

The readme contains details about the many supported operations:
https://github.com/thi-ng/zig-thing/blob/main/doc/vectors.md

Installation instructions in the main repo readme:
https://github.com/thi-ng/zig-thing/tree/main

#Zig#Ziglang#ZigThing#Vectors#Refactoring

Btw. It's amazing that this swizzle function gets compiled into single WASM i8x16.shuffle ops (per 4 vector components, i.e. swizzling into an 8-dimensional vector would require 2 shuffles):

https://github.com/thi-ng/zig-thing/blob/ab8566baf6f413abc29ca9ced222189bdb1f455e/src/vectors.zig#L1287-L1301

#Ziglang#WebAssembly#WASM

After almost a week of refactoring and experimenting with several different approaches, I've updated my Zig nD SIMD vector library to be compatible with the latest Zig 0.15.1, and at the same time cleaned up some internals.

The solution I settled on is a mix of techniques proposed by others, and was needed due to the removal of the struct/namespace-merging syntax in the new Zig version, which this library heavily relies on. I don't like that the new source code is now more than 2x larger and involves a huge amount of duplication to address the many special cases of supported operations for different vector sizes and types. I might still take another pass to eliminate those (by using @compileError() for unsupported cases), but that'd be an implementation detail downstream users don't have to care about. I tried AOT code generation as well, but the special case handling made this feel less maintainable...

UPDATE: The only breaking change is the handling of vector swizzles. I had to remove the hundreds of named swizzle functions and replaced them with a single (comptime optimized) .swizzle(vec, pattern), e.g. .swizzle(vec, "xxyy")...

If you're interested, the new code is here:
https://github.com/thi-ng/zig-thing/blob/main/src/vectors.zig

The readme contains details about the many supported operations:
https://github.com/thi-ng/zig-thing/blob/main/doc/vectors.md

Installation instructions in the main repo readme:
https://github.com/thi-ng/zig-thing/tree/main

#Zig#Ziglang#ZigThing#Vectors#Refactoring

Yesterday I released new versions of https://thi.ng/wasm-api (and its add-on packages), a modular and extensible bridge API & toolchain for hybrid JS/TS/Zig/WebAssembly apps, now updated to be compatible with the latest Zig version 0.15.1...

The update addresses some of Zig's breaking syntax & build system changes only, nothing on the JS/TS side has changed. As a result https://thi.ng/wasm-api-dom has a slightly revised internal structure (also a breaking change, but nothing major & unavoidable). All bundled Zig examples[1] in the repo have been updated too, take a look for reference (if needed).

FYI More details about the Zig language changes here:
https://ziglang.org/download/0.15.1/release-notes.html#Language-Changes

Specifically, the removal of usingnamespace has had a major impact on the existing handling of generated types in these wasm-api support packages (or your own) and now forces an additional level of hierarchy in terms of namespacing. This is because usingnamespace enabled a form of namespace merging, which allowed the generated WASM⭤TS interop types (written to their own sourcefile) to be merged/hoisted into the main library module.

For example, previously after importing const dom = @import("wasm-api-dom"); we could refer to a type via dom.WindowInfo. Now with namespace merging removed, we have to use dom.types.WindowInfo. As I said, it's not a major departure, but a breaking change nonetheless[2]...

The build.zig file bundled with https://thi.ng/wasm-api is now also only compatible with Zig 0.15.1 (for now). Build files for older Zig versions are still included too (in the same directory)[3].

Lastly, once more for the record: The wasm-api bridge itself is NOT tied to Zig (or a particular version), however it's the main use case/language for my own WebAssembly use cases...

[1] https://github.com/thi-ng/umbrella/tree/develop/examples (all examples starting with zig-*)

[2] The existing design of these modules helped to keep these breaking changes to a minimum in userland code and these updates are all following the same uniform pattern (i.e. exposing interop types via modulename.types.TypeName...)

[3] https://github.com/thi-ng/umbrella/tree/develop/packages/wasm-api#using-the-zig-build-system

#ThingUmbrella#Zig#Ziglang#WebAssembly#WASM#TypeScript#JavaScript#Interop

Yesterday I released new versions of https://thi.ng/wasm-api (and its add-on packages), a modular and extensible bridge API & toolchain for hybrid JS/TS/Zig/WebAssembly apps, now updated to be compatible with the latest Zig version 0.15.1...

The update addresses some of Zig's breaking syntax & build system changes only, nothing on the JS/TS side has changed. As a result https://thi.ng/wasm-api-dom has a slightly revised internal structure (also a breaking change, but nothing major & unavoidable). All bundled Zig examples[1] in the repo have been updated too, take a look for reference (if needed).

FYI More details about the Zig language changes here:
https://ziglang.org/download/0.15.1/release-notes.html#Language-Changes

Specifically, the removal of usingnamespace has had a major impact on the existing handling of generated types in these wasm-api support packages (or your own) and now forces an additional level of hierarchy in terms of namespacing. This is because usingnamespace enabled a form of namespace merging, which allowed the generated WASM⭤TS interop types (written to their own sourcefile) to be merged/hoisted into the main library module.

For example, previously after importing const dom = @import("wasm-api-dom"); we could refer to a type via dom.WindowInfo. Now with namespace merging removed, we have to use dom.types.WindowInfo. As I said, it's not a major departure, but a breaking change nonetheless[2]...

The build.zig file bundled with https://thi.ng/wasm-api is now also only compatible with Zig 0.15.1 (for now). Build files for older Zig versions are still included too (in the same directory)[3].

Lastly, once more for the record: The wasm-api bridge itself is NOT tied to Zig (or a particular version), however it's the main use case/language for my own WebAssembly use cases...

[1] https://github.com/thi-ng/umbrella/tree/develop/examples (all examples starting with zig-*)

[2] The existing design of these modules helped to keep these breaking changes to a minimum in userland code and these updates are all following the same uniform pattern (i.e. exposing interop types via modulename.types.TypeName...)

[3] https://github.com/thi-ng/umbrella/tree/develop/packages/wasm-api#using-the-zig-build-system

#ThingUmbrella#Zig#Ziglang#WebAssembly#WASM#TypeScript#JavaScript#Interop

I’m at a demoparty (Xenium) and there’s a guy coding a synth from scratch for a microcontroller (STM something) using #ziglang. Didn’t expect seeing Zig here but this makes sense - way better than using C here, also way easier than coding it in assembly.

Zig folks, what do you attribute the language's growth to? Zig is neither fully memory safe nor the first attempt at a C replacement, yet it's growing.

What can unpopular language learn from your community? #ziglang #programming

Zig folks, what do you attribute the language's growth to? Zig is neither fully memory safe nor the first attempt at a C replacement, yet it's growing.

What can unpopular language learn from your community? #ziglang #programming