[account42]

> e.g. doing a spinning cube takes several hundred lines of code

This really doesn't mean much. The second cube (or another shape) isn't going to double the line count.

> OpenGL was never "easy" but it was at least something a regular person could learn the basics of in a fairly short amount of time.

The problem is that OpenGL no longer matches current hardware so the naive way to use it is very much suboptimal for performance. Once you move to zero driver overhead techniques for OpenGL then Vulkan is not that much harder.

> Like, imagine the newest Intel/ARM/AMD chips came along and instead of being able to write C or C++, you're being told "We are dropping support for higher level languages so you can only write assembly on this now and it'll be faster because you have more control!" It would be correctly labeled as ridiculous.

Except current Intel/ARM/AMD chips don't support C or C++ and you already have to write assembly ... or use a third-party tool to do the translation from C or C++ for you. That's also the goal for Vulkan - to provide a low level standard interface for GPUs on top of which more user friendly abstractions can be layered.

[foldr]

>This really doesn't mean much. The second cube (or another shape) isn't going to double the line count.

It's like the difference between "Hello World" in Python and "Hello World" in Java. Doesn't matter in the context of a serious software engineering project, but it's a significant barrier for beginners.

[account42]

I agree with your analogy. It just so happens that Java is commonly taught as a first programming language and most people manage just fine with the class boilerplate even if they don't really understand it yet.

[pjmlp]

Yet the burden in C# and Java was consider enough of an issue versus languages like Python, JavaScript, Go, that both platforms are reducing the hello world boilerplate.

[troad]

> This really doesn't mean much. The second cube (or another shape) isn't going to double the line count.

That's an absurd standard. "Writing an OS is easy, because once you've written enough code to get Doom to run, firing up a second copy of Doom is relatively straight-forward!"

It's those first 600 lines that are the problem. There's now a steep learning curve and lots of boilerplate required for even trivial use cases, where there wasn't before. That's a loss.

> The problem is that OpenGL no longer matches current hardware so the naive way to use it is very much suboptimal for performance. Once you move to zero driver overhead techniques for OpenGL then Vulkan is not that much harder.

Again, mad standard. "Writing Vulkan shouldn't be a problem for people who write complex zero driver overhead code for OpenGL." Great. What about the other 99% of people?

I'm not against Vulkan for those applications that truly do need it, but - frankly - most graphics programming does not need it. In giving up OpenGL we're giving up a sane, standard way to do graphics programming, and exchanging it for a choice between (i) making everyone write mad Vulkan boilerplate for control they don't need, or (ii) choosing between a bewildering array of engines and frameworks and libraries, none of which work at all similarly, many of which are still very immature.

And it's obvious which one will win - whichever proprietary, SaaS monolith emerges to clean up the mess. Losing OpenGL is a huge set back for open standards, honestly. The principal beneficiaries of depreciating OpenGL will be the shareholders of Unity, in the end.

[account42]

> That's an absurd standard. "Writing an OS is easy, because once you've written enough code to get Doom to run, firing up a second copy of Doom is relatively straight-forward!"

If you can write that OS in anything close to 600 lines then yes, it is easy.

The point is that more realistic OpenGL and Vulkan projects will have a much smaller relative size difference.

> Great. What about the other 99% of people?

They can use higher-level abstractions built on top of Vulkan. Or spend some time learning to use Vulkan directly.

> I'm not against Vulkan for those applications that truly do need it, but - frankly - most graphics programming does not need it.

Disagree.

> In giving up OpenGL we're giving up a sane, standard way to do graphics programming

Sane is not a word I would use to describe OpenGL. It has managed to collect many warts over the years and as I have already mentioned, what performs well is not at all intuitive.

> (i) making everyone write mad Vulkan boilerplate for control they don't need, or (ii) choosing between a bewildering array of engines and frameworks and libraries, none of which work at all similarly, many of which are still very immature.

"Oh no, so many options". A nice problem to have.

> And it's obvious which one will win - whichever proprietary, SaaS monolith emerges to clean up the mess. Losing OpenGL is a huge set back for open standards, honestly. The principal beneficiaries of depreciating OpenGL will be the shareholders of Unity, in the end.

Wild and unfounded speculation. You can already use ANGLE, which is open source, as your middleware today if you like the OpenGL API so much.

[HelloNurse]

> I'm not against Vulkan for those applications that truly do need it, but - frankly - most graphics programming does not need it. In giving up OpenGL we're giving up a sane, standard way to do graphics programming

I cannot avoid thinking that this sort of argument was made for countless technological innovations, from steam engines vs. draft animals to boats vs. swimming.

[troad]

Haha, that's an interesting thought. Not to play devil's advocate, but can you honestly tell me the average American's weekly car need couldn't be met by a horse? (Mostly kidding.)

I think the distinguishing thing here is that those technological innovations were all adopted voluntarily by people setting aside the previous technologies, for the advantages of the new technology were obvious. Here, people are clinging to the old tech despite being threatened with its constant depreciation (already done on Apple systems), for the simple reason that using the new tech is more work for no more gain. For the average use case, Vulkan feels more like a technological regression than an advance.