I mean... Let's pause for a minute and remove the year, and remove the language / framework. What are we trying to accomplish?
If we know something really well and there are enough developers to support an ecosystem and the talent pool in your is big enough just use whatever you want.
PHP in 2018? SURE.
C++ in 2018? SURE (You masochist)
Rails in 2018? Youre damn right I would.
GO in 2018? OK. Fine. Whatever.
This is highly opinionated, but our jobs are to make stuff that works in a predictable, less risky way. Do that.
"C++ in 2018? SURE (You masochist)"
I know this is tongue in cheek, but if one is doing anything related to real time graphics programming I'm not aware of any good alternatives.
> I'm not aware of any good alternatives.
Vulkan/C? Metal/ObjC†/C? From C libs you can probably get to bindings to other languages like D, Haskell, Rust, Go†.
† depending on your definition of "real time" (soft vs hard), both kernel-wise and GC-wise.
"Vulkan/C? Metal/ObjC†/C? "
Vulkan and C are a sane option. Although, with C and linear algebra one starts to miss C++ operator overloading and existing libraries like eigen [0] or glm[1] with their graphics and computational geometry targeting API:s really soon.
If one deploys only to OS X/IOS, Metal and ObjC, sure.
"From C libs you can probably get to bindings to other languages like D, Haskell, Rust, Go†."
With the added complexity of the binding layer, and sub-par collection of existing examples and resources. With C++ both OpenGL and Vulkan have excellent didactic material, including:
https://vulkan-tutorial.com/ https://learnopengl.com/
[0] http://eigen.tuxfamily.org/index.php?title=Main_Page [1] https://glm.g-truc.net/0.9.9/index.html
I don't know about Vulkano, but Glium is much more pleasant to use than the raw OpenGL API.