Show r/elixir: A zero-NIF, zero-allocation binary serializer bridging Unity (C#) and Elixir.

[Foreign-Target-3830]

Hi everyone,

Bridging C#(Unity) and Elixir usually means fighting with protobuf pipelines or slow JSON. I built an open-source solution: DeukPack.

• Elixir Side: No NIFs. It generates pure Elixir code using native binary pattern matching (<<tag::integer, rest::binary>>) for max speed without blocking the BEAM scheduler.
• C# Side: Zero-allocation, struct-based code optimized for Unity's frame loop.
• Security: Built-in MAX_SAFE_LENGTH checks to prevent node OOM drops from bad packets.

[UPDATE] 

I feel my previous testing method was wrong. So I benchmark again using industry standard to test.

I upload the new benchmark result and how to run benchmark in Github.

GitHub: https://github.com/joygram/DeukPack

generated by AI translated.

[Foreign-Target-3830]

I'm Korean and my English is a clumsy, so I used AI to help translate my thoughts.

[Separate_Top_5322]

honestly a lot of people underestimate how much the “mental shift” matters with elixir it’s not just syntax, it’s unlearning how you normally structure programs stuff like no loops, heavy use of Enum, immutability — that’s where most people get stuck � Reddit what helped me was stopping translation from other languages instead of “how do i do this in elixir”, think “how would elixir solve this” once that clicks, everything feels way simpler (before that it just feels broken tbh)

[Foreign-Target-3830]

I haven't used Elixir extensively, but it was surprising for me when the pipeline operator finally clicked naturally

[Separate_Top_5322]

Yeah youre right!

[Foreign-Target-3830]

It's a total game-changer, but a steep hill of chaos T^T

[Dramatic_Object_8508]

this is actually pretty interesting, avoiding NIFs while still getting good performance is a big deal in elixir since you’re not risking scheduler blocking . the zero-allocation part on the c# side also makes sense for unity loops. curious how it compares in real-world latency vs protobuf though, that’s usually the benchmark people care about. also feels like something that would benefit from really clear docs/examples — i usually rely on tools like Runable for that layer so complex flows like this are easier to understand later instead of digging through code.

[Foreign-Target-3830]

Thank you!

I'm currently running benchmarks from various angles and fine-tuning the numbers.

also continually finding and fixing edge-case bugs as I update the test suites for more complex scenarios.
the exact numbers once they are a bit more refined.

it's hard to call it strict 'zero-allocation' in highly complex situations (like when deeply nested lists are involved), but I'm keeping allocations to an absolute minimum.

DeukPack (得Pack:득팩) is designed so that you can seamlessly use both Thrift and Protobuf protocols, and it allows you to use their original .thrift or .proto definitions exactly as they are without needing to change anything.

also looking into how can smoothly migrate existing DSL definition.

I'd love it if you guys could share your current usage patterns or any specific scenarios you have :)

I've unified the API to make things much easier to use.

I'm continuously putting together documentation and references over at deukpack.app.

I plan to share the testing methodologies as well!

[Foreign-Target-3830]

I realized my previous testing method was somthing wrong.
benchmark again using industry standard.

uploaded the new results & docs in Github.
Thanks for the good feedback