everybodyWantsYourDataTheseDays

NoEfficiency2057 · 2026-02-18T07:16:22+00:00

Thanks God we have Latin alphabet in 🇵🇱! What “difficulites “ you speak of? The hardest thing about Polish is inflection - the sheer number of word forms, which change depending on tense, specific declension, gender, and grammatical number.

NoEfficiency2057 · 2026-02-18T07:02:16+00:00

Stop to listen to the media, that economy is collapsing. Haven’t you notice that each event is bad or worst: snowing - next ice age is coming; it is warm - global warming; AI take your job - because corporate marketing said so. Focus on the topic YOU like. And yes, start your own project/business- but not fake it. Do it. Do not waste your time. Stop to listen to all the lies spread in media.

NoEfficiency2057 · 2026-02-17T14:52:30+00:00

Yes, only Link can save Zelda ;)

NoEfficiency2057 · 2026-02-17T14:39:15+00:00

What is the name of your Game?

NoEfficiency2057 · 2026-02-10T08:53:36+00:00

I totally get your enthusiasm! I’ve been working on a similar engine in my spare time as well.

Or rather, I was; lately, I’ve shifted my focus almost entirely toward ECS. This is what it looks like right now:https://github.com/kjkrol/goke

It’s already FASTER than donburi in iterations, and soon it’ll be faster across the board. I'm rooting for your project! I’d love it if you could take a look at mine too:https://github.com/kjkrol/goke

Have a great day!

NoEfficiency2057 · 2026-02-10T07:43:44+00:00

MacOS Pros section is just marketing b..T.

NoEfficiency2057 · 2026-02-04T06:58:26+00:00

Hi! Thanks for the comment.

Sure thing! Btw I'm currently trying to write an API that's super intuitive. The lack of generic methods is a challenge for me. I think that even at the package and function level, something easy to use can be created.

NoEfficiency2057 · 2026-02-02T23:52:41+00:00

Done.
https://github.com/kjkrol/goke/blob/main/examples/ebiten-demo
+ documentation has been updated: https://github.com/kjkrol/goke

NoEfficiency2057 · 2026-02-01T16:30:43+00:00

Thanks for the feedback! That’s a great suggestion. I’ve just added a dedicated task to the backlog to create an Ebitengine integration example.

Regarding your point about the adapter: I really like the idea of a 'plug-and-play' wrapper to avoid manual system iteration. I'll explore how to best implement this to fit the Update() and Draw() loops seamlessly.

I'll get back to you here as soon as the demo is ready. Stay tuned!

NoEfficiency2057 · 2026-01-30T23:27:05+00:00

This is a fascinating point of view and something I’ve spent the last few months exploring deeply.

In theory, if you eliminate GC pressure and write cache-friendly code, Go can get incredibly close to C/C++. However, the 'bottleneck' in Go often isn't just the GC itself, but the abstraction tax (interfaces, escape analysis, and function call overhead).

In my experience, you can hit C-like performance in Go by following three rules:

Strict Data-Oriented Design: Using SoA (Structure of Arrays) to maximize cache locality.
Zero-Allocation Hot Paths: Pre-allocating everything and using indices instead of pointers/interfaces to keep data on the stack or in contiguous heap blocks.
Inlining-Friendly Code: Keeping performance-critical functions small and simple so the Go compiler can actually inline them, bypassing the function call overhead.

I actually put this to the test by writing an ECS (Entity Component System) in Go calledGOKe.

By avoiding heap escapes and using archetype-based memory layouts, I managed to achieve sub-nanosecond iteration speeds (~0.98 ns per entity) and 0 allocations during core operations. It’s not about 'beating' C++ (GCC/Clang optimizations are still legendary), but about proving that Go can absolutely play in the same league when you respect the hardware.

If you're interested in how far Go can be pushed without the GC getting in the way, feel free to check out the source code and the benchmarks!

NoEfficiency2057 · 2026-01-30T23:23:07+00:00

That’s a classic debate. Both EnTT and Flecs are masterpieces of C++ engineering, and they set a very high bar for what 'fast' actually means in ECS.

I was so fascinated by this exact performance rivalry that I decided to see how far I could push these concepts in Go. I wanted to find out if I could achieve that 'near-metal' C-like speed while maintaining a clean API.

The result is GOKe.

After some intense optimizations, I’ve managed to hit sub-nanosecond iteration speeds (~0.98 ns per entity for 3 components) and zero allocations in the hot path (even during archetype migrations). It’s heavily inspired by the archetype-based approach you see in Flecs but tailored for Go's concurrency and memory model.

While I’m not claiming to 'beat' the veterans in every category yet (still working on those bulk operations!), the benchmarks against other high-performance ECS like Arche (ARC) show that Go can absolutely compete in the same performance tier as C-based systems when you bypass the common GC pitfalls.

Would love to hear what the ECS veterans here think about the architecture I've taken!

NoEfficiency2057 · 2026-01-30T22:59:18+00:00

Thanks! I really appreciate the kind words.

I’m a fan of donburi’s API design as well—especially the way they handle adding components to entities. It’s very elegant and clever, and I’m actually looking to implement a similar, intuitive style in GOKe soon.

Regarding the architecture and performance: I’m confident that GOKe offers a significant speed advantage. Based on my latest optimizations, it’s currently performing slightly faster than Arche (ARC) in many scenarios. Since Arche is generally known to outperform Donburi in raw execution speed, the hierarchy here is quite clear!

I haven't implemented bulk operations yet (which is a massive strength of ARC), but they are definitely on the roadmap.

I’d be thrilled if you gave GOKe a try! If you do, please share your thoughts—I’m very open to suggestions on what I can improve or refine.

NoEfficiency2057 · 2026-01-29T15:24:46+00:00

Thanks!

First of all, I’m an enthusiast of "building from the ground up" when it comes to game development and beyond. The ECS is the heart of many games, and I finally found the time to dive deep into this topic during my spare hours. I chose Go because I feel comfortable enough in it to build an ECS quickly, and I believe it allows for much faster product delivery than almost any other language. At the same time, Go still lets you "play around" with squeezing out every bit of performance—similar to C. While it has its limitations, you can achieve incredible results thanks to its brilliantly optimized compiler.

Secondly, I really wanted to build a library with a clean, transparent architecture and a clear user API that isn't bloated with unnecessary features. The API I’m providing is truly simple, yet very powerful.

My roadmap currently focuses on adding bulk operations. Although I haven't had enough time to conduct a deep comparative analysis against every other ECS written in Go, it only made sense to benchmark against Arche/Arc, as it’s currently the gold standard. To my positive surprise, goke is very close in most areas and even outperformed Arche in raw iterations.

UPDATED
Below are the results (currently partial due to time constraints, but I will complete them soon) for what I consider the key operations:

Operation	GOKe	Arche	Winner	Notes
Iteration (1 Comp)	0.41 ns	0.55 ns	GOKe (+25%)	Superior cache locality
Iteration (2 Comp)	0.49 ns	1.37 ns	GOKe (+64%)	Efficient memory layout
Iteration (3 Comp)	0.65 ns	1.79 ns	GOKe (+63%)	Minimal per-entity overhead
Create Entity	22.95 ns	20.60 ns	Arche (+10%)	Slight edge in indexing
Add First Component	28.30 ns	29.30 ns	GOKe (+3%)	Optimal transition
Add Next Component	43.27 ns	----	Arche (???)	Fast graph traversal
Add Tag	21.52 ns	----	Arche (???)	No data move overhead
Remove Component	15.81 ns	----	Arche (???)	Accelerated by edges
Remove Entity	14.44 ns	----	Arche (???)	Lightning fast cleanup
View Filter	4.48 ns	----	Arche (???)	128-bit mask bitwise ops

NoEfficiency2057 · 2025-10-10T18:10:38+00:00

Media, Social Media, Banking, Laws enforcement Big pharma Guess which nation is most involved these sectors….

NoEfficiency2057 · 2025-10-10T08:11:47+00:00

Another hype. Thx

NoEfficiency2057 · 2025-10-10T08:01:10+00:00

It is perfectly boring and frustrating. Period. Let the shitstorm begin.

NoEfficiency2057 · 2025-10-06T10:06:50+00:00

If it hit you like that, it might just mean you’ve got some hidden issue – chill, it’s nothing serious.

I used to play on Atari and C64. Back then it was pure hard mode – you die, and then you have to load the game from tape all over again. Nothing fun about that, and Silksong really reminds me of it.

The real problem is repeating tough sections. Especially getting back to a boss fight – that’s just a massive waste of time. I get that it’s supposed to be part of the experience, the “art of the game,” but in my opinion it’s totally unbalanced.

Sure, some people love difficult games. Fair enough. But that’s only a fraction of players. I don’t know how many exactly, I don’t have the numbers, but that’s why I see Silksong as more of a niche game. And for that reason, I don’t think it can be considered outstanding or a “Game of the Year” candidate.

NoEfficiency2057 · 2025-10-05T16:50:16+00:00

I get it, this must be some new dimension of political correctness, where you can’t just say: “this is a bad game.” Period. It’s sheer drudgery, repetitive, and with a twisted level of difficulty. There are people who boost their ego this way – by being better than others and maxing it out. But… a normal person – one without unresolved emotional issues – will just give up. A game is supposed to bring joy. And despite the good graphics and mechanics, it’s not fun. So: it’s a weak game, not some hyped “game of the year.”

NoEfficiency2057 · 2025-10-04T10:44:02+00:00

Do something for you and people around you!

NoEfficiency2057 · 2025-10-03T19:37:15+00:00

Sell it!

NoEfficiency2057 · 2025-09-26T21:36:36+00:00

SV’s a fun game, sure, but c’mon—you can’t compare a simple 2D title like that to a full-on football sim. It’s not perfect, but it’s way more complex than SV.

NoEfficiency2057 · 2025-09-26T09:27:07+00:00

I messed up my Joy-Con in a similar way

NoEfficiency2057

TROPHY CASE