It's simple, easy to embed using C FFI. Handles most of what is needed. And also because of tsoding.

I’m using Raylib-go and i love it. This framework gives you just the right amount of abstraction, so you have all of fundamental blocks of functionality for all basic aspects of the engine (that’s made very easy), yet you are not bound to the engine, you are free and productive

I've had some limited exposure to SDL couple years back and it felt ancient. No wonder there is such demand for a simple unifying API with bindings for a lot of languages that's also not older than you. Where else are these people supposed to go?

Cos tsoading using it lol?

I just started learning go and I plan to use raylib for gui elements of programs and experiments more than I do games.

I've been messing with raylib for the past week and was excited when I realized how easy it was to load and render a 3d model. But as soon as I tried to add lighting I hit a brick wall and couldn't do it. The basic lighting example program works but when I add my own model it won't light it. So I dug into the code and it appears no less complicated than doing it straight in opengl. Perhaps even moreso because raylib is automatically assigning uniforms and it's a huge pain in the ass to figure out what the hell is going on or what is going wrong.

Raylib is also good for statistical and simulation visualization when there is a lot of particles and nodes

i wish the C bindings didn't clash with Windows API, preferably had some sort of optional rl_ prefix

What I'd add to the library vs GUI engine is it really matters if you are working on the game solo, or if you need to collaborate with non-programmer artists. If you are collaborating with artists and level designers, the GUI is more for them than for you. Level designers need a "Halo Forge Mode," if you will.

that comparison with game engines isn't very apt. yes obviously something like raylib is awesome for getting into game engine programming without building absolutely everything from scratch, but if you set out to make an actual *game*, you're going to end up reimplementing the same patterns and abstractions present in pretty much every game engine ever in some shape or form. it doesn't really mean anything that it's "more familiar" to a non-videogame programmer, because making any game that holds up to any sort of modern standard (not talking about AAA, this applies to anything that sells as a game on steam for at least a dollar, or something you see made for a 48 hour game jam) will require you to learn how to program a *game*, which is something very complex and deep, which programmers with experience in other fields might see as very alien. so in any case, what you'll be doing will be unfamiliar. a proper game engine (i.e. Godot) allows you to only need to get familiarized with some basic abstractions like scenes and nodes (which typically exist in other engines with names such as rooms and entities), but not have to deal with any of the heavy lifting that requires months if not years of study like collision, lighting, shading, rendering, optimization, and so on. the programming itself is exactly the same, thus the barrier of entry ends up being far lower than if you had to code your own game from scratch.

I think start citizen uses lumber yard

I use Bevy and want to transition to just wgpu, ECS and my utils

So its like a Util? well at that size its a framework i guess...