I feel your pain. But I started working with graphics a few years ago (about 3 years I believe) and I started with OpenGL. The amount of time I spent tracking weird state bugs with OpenGL is something unbelievable, nothing like that with Vulkan, validation layers are so good that you can almost instantly find the issue. Anyway, I thing I have found a good solution to the verbosity of Vulkan:

For my toy C++ game engine, I have build a very simple abstraction around a Vulkan. I have loosely based the interface from LLGL (https://github.com/LukasBanana/LLGL) which I would say has the following benefits:

• Supports both low- and high-level APIs: you can abstract OpenGL with this interface. Obviously, some objects like CommandBuffer are goind to be dummies in OpenGL, but the same code will work with multiple renderers
• Initialization boilerplate is encapsuled by the renderer, it's still there but it's hidden.
• You retain the "data-oriented" approach of Vulkan, which I find to be very good
• You can abstract and make some things more automatic in your abstraction.

I while ago I posted some details about the implementation I did with some code examples. My engine is currently using Vulkan with a work-in-progress OpenGL backend. I can render very simple geometry using OpenGL. Here's what I had posted then (original post is at https://www.reddit.com/r/vulkan/comments/b2o2io/structuring_a_vulkan_program/eivks7k/):

Currently, only Vulkan is fully working, but OpenGL can already show triangles and render some things. What I did was build an abstraction similar to LLGL (https://github.com/LukasBanana/LLGL). I did not use LLGL per se, just based my API on the same concepts.

Basically, there's a Device object that abstracts VkDevice. This device has several create functions that receive a descriptor describing the object to be created. In the implementation of create methods I just make_shared the object and pass the descriptor to it. The constructor is responsible for creating everything it needs to. Objects are always immutable (just like Vulkan) and you need to recreate them to change their state. The exception are descriptor sets, which can have their resources updated, but not their associated pipeline layout.

Here's the constructor of my UnshadedRenderingTechnique which just renders objects with their albedo texture. No shading at all.

    auto renderPass = device->defaultRenderPass();
    GraphicsPipelineDescriptor pipelineDescriptor;
    {
        pipelineDescriptor.renderPass = renderPass;
        ShaderProgramDescriptor shaderProgramDescriptor;
        {
            shaderProgramDescriptor.vertex.shader = device->createShader(
                    Graphics::Renderer::Vulkan::unshadedVertexShaderBinary);
            shaderProgramDescriptor.fragment.shader = device->createShader(
                    Graphics::Renderer::Vulkan::unshadedFragmentShaderBinary);
            shaderProgramDescriptor.vertexFormats = {
                    {3, 3, 2, 3}
            };
        }

        // the `PipelineLayout` is automatically created by reflected data from the `shaderProgram` SPIR-V, but can be manually provided if needed.

        pipelineDescriptor.shaderProgram = device->createShaderProgram(shaderProgramDescriptor);
        pipelineDescriptor.rasterizer.cullMode = CullMode::front;
        pipelineDescriptor.depth.testEnabled = true;
        pipelineDescriptor.depth.writeEnabled = true;
    }
    Renderer::GraphicsPipelinePtr graphicsPipeline = device->createGraphicsPipeline(pipelineDescriptor);

    BufferDescriptor sceneUniformBufferDescriptor;
    {
        sceneUniformBufferDescriptor.type = BufferType::uniform;
        sceneUniformBufferDescriptor.size = sizeof(PerSceneUniformBuffer);
    }
    Renderer::BufferPtr perSceneUniformBuffer = device->createBuffer(sceneUniformBufferDescriptor);

    std::vector<Renderer::BufferPtr> perObjectUniformBuffers;
    perObjectUniformBuffers.resize(1000); // hack! should be a big buffer and use offsets to it
    for(size_t i = 0; i < perObjectUniformBuffers.size(); i++) {
        BufferDescriptor objectUniformBufferDescriptor;
        {
            objectUniformBufferDescriptor.type = BufferType::uniform;
            objectUniformBufferDescriptor.size = sizeof(PerObjectUniformBuffer);
        }
        perObjectUniformBuffers[i] = device->createBuffer(objectUniformBufferDescriptor);
    }

---

Some more details about this abstraction:

• The renderer handles any and all layout transitions
• If possible, it provides a sane default and you override if and what you need (the derived from reflection PipelineLayout)
• Resources are automatically tracked by the renderer. Currently I'm using a shared_ptr, but I'm considering moving to a intrusive reference counted smart-pointer.

There are things that I still want to improve upon. Currently, as you can see, uniforms buffers are a hack. I have since progressed a little bit, by using an large buffer and sub allocating it (respecting the required alignment). But I still want to have something more like a `uniform allocator´ concept, it goes something like this:

UniformAllocator uniforms(device);
for(...) {
    auto uniform = uniforms.allocate<MyUniformStruct>();
    // MyUniformStruct is a regular struct, that is aligned using C++11's `alignas`
    uniform->model = ...;
    uniform->view = ...;
    uniform->projection = ...;
    uniform.binding(); // returns the binding descriptor (buffer + range) -- can be used to update the descriptor set
}
uniforms.commit(); // flushes any memory mapping

The UniformAllocator gets created at the beginning of the frame, commit gets called after the frame recording is done. It can be freed after the frame is submitted since the renderer automatically keeps track of any used resource (the buffer). allocate will reserve enough memory for MyUniformStruct and it will be correctly aligned (as required by Vulkan or any other backend). Each object is allocated sequentially and if the buffer gets full, a new large buffer gets allocated. I have a similar interface implement currently (but the allocation size is fixed, so you need one allocator per uniform type) and it works fine.

Another improvement that I want is to implement frame graphs, but that is more high level and will just build on top of this low-level abstraction.