That seems roughly like a simplified form of what I have in GLAbstraction 
What was the main thing missing for you? Maybe documentation? 
E.g. automatic conversion is implemented by gl_convert. I haven’t fully implemented checking what uniforms/attributes a shader needs, since most of my shader use templating and insert the uniforms/attributes automatically.
I must admit, that the API has some horrible inconveniences, simply because I don’t care that much about it and it works fine in GLVisualize. A big refactor is on the way, hopefully removing these problems and making things faster and consistent!
Yes in the beginning I thought GLAbstraction is all I needed, but it turned out there is no simple alternative
to writing shaders by hand in order to achieve various non-orthodox functionality.
I find that it is really easy to work that way. Instead of abstracting away shaders , I am only abstracting away
the cumbersome and highly annoying openGL C api.
I think there is value in layers of abstraction … openGL C api → ModernGL + GLFW → Shaders → GLabstraction(Templated shaders for primitives and lighting) → GLvisualize → GLplots
this way anyone can choose the level in which they would like to tinker with things.
openCL/CUDA can benefit from this workflow as well. until the grand vision of using LLVM technology directly to write
kernels from julia code. it would be productive to have a one-liner to compile a kernel into a function and a one-liner to invoke that kernel with automatic conversions from Julia types