You seem to be using a definition of "declarative" that I'm unfamiliar with. The functional languages you target in the second to last paragraph are very different from the more imperative languages in the final paragraph, and I wouldn't consider either group to be "declarative". I'm left wondering what concepts you're attempting to criticize.
Having said all that, yes, I believe major commercial projects are started in those languages, though I have no idea if anybody plans them into the 2030s.
Functional languages are declarative. The point is that there are two kinds of languages; languages which people bitch about and languages which nobody uses.
Sure, I can mention tons of commercial projects which are started in those languages, and which use them at least partly(for example Python for scripting interface). However, I really doubt none of the languages provide a solid ground to build upon(even if we weren't talking about systems programming and it's future). Consider C and C++ for example; in what language is the OS you are using written in? The compiler it's compiled with? The libraries you use? The web browser? The JavaScript interpreter? You get the point. The fundamental systems we use are built upon these two languages, and I think it's a big problem people would want to address(myself included), because these languages are nowhere near perfect. There just aren't better alternatives for that domain, considering:
1) existing codebase
2) libraries
3) tools
4) efficiency
5) portability
6) programmer availability, resources and education
7) language reliability and future proofness(e.g. backwards compatibility, vendor and thus platform independence).
These are real problems when it comes to building reliable abstractions(that's the whole essence of systems programming, isn't it?), and thus far C and C++ have been the only languages which have been able to provide all of those the best.
When it comes to the future of computing from a hardware level, things may(or may not) seem a bit better; for example utilizing GPUs for general computing, using low-power ARM/x86 cores for parallelism. There are foundations for these things in C(and now C++ too) and libraries to help programming these things. How many years will it take to get a reliable Go or Rust support for programming a vendor-independent GPU? What's the overhead compared to say C or C++? The alleviating thing here is that GPUs and ARM cores aren't CISC machines so compilers and thus software is highly responsible for the performance, so with a good compiler you can get away with using less efficient implementation language, and get gradual improvements too.
"How many years will it take to get a reliable Go or Rust support for programming a vendor-independent GPU? What's the overhead compared to say C or C++?"
We're already using Rust for OpenGL ES 2.0-based graphics programming.
I didn't expect that, I am almost surprised! Though, I was more after using Rust or Go for general purpose GPU computing via OpenCL for example. There seems to be some form of project for binding, but I certainly would not put my money on some random person doing the bindings. Very experimental and unreliable stuff.
This is a hard problem, because it involves mindshare and resources; even a perfect language would take years to gain a serious foothold. But it'll never be solved if nobody tries.
This is definitely true, and the exact point I'm building my arguments upon. Are Rust and Go better languages than C and C++ for solving lots of problems, in many, many cases yes! But we can't use them. How frustrating is that!?
Of course there's a difference between being able to use a language and when mainstream starts picking it up. Considering for example C++, it wasn't only until mid 90's when it really took off, a bit more than 20 years after it was named C++ from C with Classes. Perhaps Go and Rust have their place in the stack sometime in 2030.
Having said all that, yes, I believe major commercial projects are started in those languages, though I have no idea if anybody plans them into the 2030s.