@phoboslab Nope, but I was thinking about making a new one with Zig and open source, sadly too busy to have time for that. BTW. I've completely switched from C to Zig now, even on my daily job, fantastic experience.
You either concieve of programming as data processing, or you concieve of it as the stitching together of black boxes (libraries and services).
Programming education should teach you how to make behavior emerge via data processing.
BUT, as you begin learn to program, you can't help but also learn about libraries.
That's because most people need some starting point. You need to have a window open where you can make things happen. Often times, the window is "just there". You don't know why it's there, or how to make it appear, except by calling a library function (or an OS API).
Most people start way higher on the abstraction ladder: you already have a library or framework that does a lot of things for you.
If you start with games, you have a framework that can draw characters and animations and play sounds and handle all kinds of things.
If you start with web, you already have a framework that handles http connections and routing requests to functions and rendering html from templates, etc.
From here, you have two divergent paths:
A) You internalize that programming is about stitching libraries together, and you keep climbing the ladder of abstraction higher and higher until you have no idea how anything works.
B) You focus on learning the essence of programming at your abstraction level (how to make computers do things), and as you gain familiarity with things at your level, you begin to go lower down the ladder and learn about how the lower layers work.
After you spend several years down either path, the attitudes and mindsets of people who went down the other route will be mind blowingly absurd.
I find it absurd that people put so much effort to _avoid_ doing actual programming (data processing) and instead spend so much effort stitching things together (configurations, libraries, frameworks).
Most people go down the black boxes path.
That's why everything sucks.
Instead of programming, you spend 90% of the time confuring tools, frameworks, databases, build tools, containers, orchestrations, external services, etc.
Jolt Physics is fast, actively maintained, MIT licensed physics engine written in C++ (https://t.co/Y2MtQV1wjV). I'm considering creating the C API for it in order to use it from other langs (#ziglang). The task is huge. Would you "github sponsor" this work? Please RT. Thanks.
@NoelFB @Polywogphony now we have `zig cc` as alternative to both compiler and build script, you may want to try (spoiler altert: a 60mb file download is enough, and you get cross-compiling support as well) https://t.co/uT25V5RmK0
@umutkarakoc Glad to see someone going similar approach, I've been making a Godot to HTML5 converter (scripts not compiled to JavaScript, but I'd like to try after seen this). Bundle size is hugely improved but performance sometimes worse. my repo https://t.co/IFBcxX1OjV
2000 white circles in a JavaScript engine vs 20000 white circles in a C++ engine built with emscripten, both running in the latest chrome. My mac is pretty old but reality still shows. Hmmm #javascript
IMO the hardest step for aspiring (commercial) indie game developers is learning to finish games consistently and efficiently - to move past game jams and prototypes but also avoid getting mired in a single project for years without end. It's a tiny sweet spot that's hard to hit.