I haven't watched his video, but whenever someone proposes a new language I always want to see new details. I'm not opposed to the idea that new languages can be better than existing ones -- I sure hope that things continue to progress.
But there's a balance between clarity and quickness to type, and a lot of the newer experimental ones sacrifice one or the other. Or make the typical case really easy, while making anything a little less common way harder. Looking at you, Ruby!
There are other ones that try to intuit your meaning in various ways. While to some extent that is... kind of helpful... it's much better to build that sort of thing into an IDE and leave the language as being really clear and deterministic. That's pretty key for a lot of things. When the language starts making assumptions about what you want, that's often a bad thing. Of course, some people believe that about Garbage Collection, and I don't, so it's obviously subjective.
And I got pretty used to the TSQL abstraction with quary optimization, etc. It frustrates a lot of programmers, but I wound up really liking it. But that was having it optimize itself based off of analysis of usage, not based off of trying to intuit your meaning. That's really only applicable to data-oriented code, that I can think of.
You do run into things like LINQ which can make data manipulation a lot more efficient to code inside existing languages, but then you inevitably take a big performance hit with that while it is trying to figure out what you were trying to say. The way it then evaluates its data is typically not optimized the way you would if you did it by hand.
On the other side of the coin, I absolutely hate C++ because it makes you say everything multiple times. Header files to go with regular files, declaring method signatures and methods in different places. Callbacks and whatnot are super complicated to define, in terms of how much code you have to type for simple things, etc.
JavaScript is pretty okay, except its object model is really bonkers because they added it belatedly. Being dynamically-typed is pretty cool in some respects, but for serious purposes it makes a lot of compile-time checking impossible, which is harmful to productivity. And in general it lets people shoot themselves in the foot more than they should be able to.
I really believe that empirically right now C# is the top language for the mixture of productivity, power, and clarity that you get. It's not perfect, but I just have yet to see something better. C# is not great in terms of how it handles multithreading, although it certainly works. But there aren't really any languages that make multithreading invisible the way that Java and C# make garbage collection invisible, and I think that's the next big jump in languages that we need to see.
Beyond that, when it comes to languages that try to simplify things in the style that Ruby does -- typing less code to do the same thing -- I feel like that is what libraries are for. C# in general does a really good job of that, but the libraries for game programming are either overly-generalized (most game engines) and thus slow, or are completely bare-metal (and thus do-it-yourself-every-time), or really unoptimized in general. And shaders are a mess. The new ShaderLab visual designer stuff is really good for the unity environment, if you're going to do 3D games.
So I do agree that new tools and libraries and language features are always a good thing, and I'm glad that there are serious computer researchers exploring new languages. But I don't think anything substantial is coming soon, at least not that I've heard.