commented:
Forgive me my question but how sokol is different from bgfx? Never
heard of sokol before, curious to know pros/cons (also I might compare
2 completely different projects, sorry in this case)

  commented:
On a surface level: bgfx is a C++ project with auto generated C
bindings, sokol is a C project (with auto generated bindings in e.g.
Rust).

  commented:
Don't know bgfx well, but sokol is a relatively small and minimalist
one-header-style wrapper over platform libs.  With a bit of digging it
looks like the core source code is similar in magnitude though, bgfx
is about 85k lines and sokol is about 50k lines.

  commented:
does bgfx also handle windowing and inputs? because if it's only
graphics, you should compare it against only sokol_gfx.h which is a
little over 25kloc
in my experience sokol libs are very easy to integrate into a project.
i think that's one of the main things that sets it apart.

  commented:
My full-time indie project relies on Sokol. (Hoping it's not a
self-plug.)
I'm building a cross-platform desktop application, and Sokol gives me
a unified set of data types and vanilla C routines for all graphics
rendering. It will transpile things down to Direct3D, Metal, or OpenGL
as needed (There's browser support too.) Sokol also offers APIs
windowing and input if that matters to you.
These libraries are all small and single-header files, so I call it
SDL's little cousin. This makes their Vulkan work a big deal, as it's
now competitive with SDL3 and their new GPU API!

  commented:

Deprecating the OpenGL backend won’t happen for a while, but
personally I can’t wait to free sokol-gfx from the ‘shackles of
OpenGL’ ;)

Something is deeply, deeply wrong with people who are willing to throw
away many decades of excellent software in the name of something
totally unclear.

  commented:
having to support opengl makes some apis suboptimal. it makes sense
when you note that of all the backends supported so far, opengl is the
odd one.
the way opengl deals with shaders and bindings is very different from
the other supported apis. if you look at some sokol_gfx code you can
notice some params are there just because of opengl
so basically removing its support enables sokol_gfx to be simpler for
the user
.