The Solidity programming language has had a rough start, with its vulnerabilities and bugs making international headlines. Furthermore, dozens of challengers have emerged, with their white papers leaning primarily on promising dramatic improvements over the fatally flawed language. The market and public opinion have run with its token generation function and largely discarded and disregarded the rest of its promise and potential.
The ICO promotions all insist that they're going to come up with a more stable, secure, and scalable solution than Solidity and its VM, but they're all running just a bit behind schedule and only NEO has shown any real signs of being viable in the wild. NEO, like most others, pitches that it plugs into DOT.NET and other frameworks to allow one to program smart contracts in a wide variety of programming languages that you already know.
At first glance, this seems appealing, but I believe smart contracts, like database queries, occupy a very specific and distinct niche that requires its own specific and distinct syntax. SQL has had myriad challengers who've insisted on empowering developers to query and modify databases in the developer's native language and context, but they've all failed and flailed because database access innately requires a paradigm shift from the rest of the application being developed.
Contract-oriented programming is an entirely different animal. It has the highest stakes possible, with one mistake potentially costing billions. Just ask the DAO investors or Parity team about that. While every programming language has its own approach to concurrency, state, and memory storage, blockchain smart contracts necessarily impose unique constraints which mean that even if you can theoretically cram it into another language, you're still going to suffer from a pseudomorphic parallax wherein a part of your code obeys entirely different rules and constraints than the rest of the language.
For the benefit of removing the problem of learning Solidity, you introduce dozens of other problems, with discrepancies between every single other adapted language threatening to create new vulnerabilities. And even if the developers of these interfaces are the rocket surgeons they claim to be on their websites, they can't solve the problem that coders must develop smart contracts with all of the blockchain rules and constraints in mind instead of the usual rules and constraints of their chosen environment.
I'm hopeful that Solidity will steadily move closer and closer to the ECMAScript standard, anyway. It will necessarily always be its own distinct flavor independent from Javascript, even if the blockchain and VM are adapted to assist the language and syntax in converging on Javascript (as I hope they do). According to Atwood's Law, "Any application that can be written in JavaScript, will eventually be written in JavaScript." While I don't believe smart contracts can or should actually be written in Javascript, I believe that coming damn close to it is the smart and natural evolution of this emergent technology.
While I'm especially bullish about Ethereum, to the point of arguably being an Ethereum Maximalist, one must bear in mind that Solidity is open source technology and there's nothing stopping other cryptocurrencies from stapling Solidity onto their own technologies. Ethereum Classic already provides another Solidity platform for folks who no longer trust the Ethereum Foundation to refrain from meddling with the integrity of transactions. I expect more to come, and for the Solidity language and new flavors to become for smart contracts what SQL and its flavors have become for database programming.