800 lines of code to render a triangle. OK.

I understand the need of being explicit, but why not include some reasonable defaults? When you need that last drop of performance, you could opt out of those defaults, but specifying everything by hand...

OK, OK, I understand. Perhaps Vulkan is a compiler target. It was never intended for someone to write Vulkan code by hand. Just code in some higher-level API or language and get everything compiled into low-level Vulkan calls. I surely hope so, for the sake of my sanity. Right? Right?

It's not intended for someone to use Vulkan to render a triangle. If you want to render a triangle (or merely a million triangles), just throw together some simple OpenGL code and you'll have no problems assuming basic optimizations (large batches).

If you really need Vulkan's advantages, you are committing yourself to a whole lot more than 800 lines of code, Vulkan or no. The setup code will be done once, then you'll move on to many thousands of lines of pipeline code that will take the vast majority of dev time. The GL vs Vulkan question is more about what you get in the end. GL takes care of a lot for you, but that makes writing a highly specialized pipeline more complicated. Vulkan makes everything complicated because specialization is presumed to be the goal.

Firstly, I am worried that OpenGL development seems to be stalled and it looks like its going into maintenance mode, where Vulkan is where all action happens. It is increasingly pushed as a replacement to OpenGL, implicitly or explicitly, and if it will be the only mainstream alternative, I am somewhat worried.

Secondly, I am worried that there are no mid-level 3D graphic toolkits. We have low-level (very very low-level) like Vulkan, or high-level stuff like Three.js and game engines (which are not what I need, as I write realtime scientific visualization code). What I want is something like imgui (https://github.com/ocornut/imgui), but for 3D. Simple, powerful, and bloat-free. However, I can't find anything like this.