Scientific computing. For my work (in particle physics) I need something that is fast, has interoperability with decades worth of C, C++ and Fortran code, runs preferable close-to-metal, and has minimal overhead. Also, it has to be something physicists (not computer scientists) can/want to work with.
There are a lot of great libraries for Python, and it's much nicer and more productive. I use it whenever possible, esp. for making graphics, or when I can use optimized stuff like in numpy. However, most of the programs I write are of the type "loop over 10 million entries, perform a simple calculation, return a number". These are mostly IO bound, and one would think that this is a case where you could use a dynamic or interpreted language. But whenever I tried, the overhead for the large loop and the variable access in tight loops was too high, and the problem became CPU bound. So, in my experience, it has to be a compiled language (or at least something more performant then Python).
I'd love to be able to use something like Haskell, as a lot of my problems are functional in nature, and it'd be able to catch a lot of stupid bugs. But it is too esoteric to be realistically adopted by the community.
The ideal language for me would be "C+". A C++ lite, where you would ban most of the complications. You would still be able to write C++ libraries, but then use them from simple C+. A C+ user, as opposed to a library writer, would not have to know about the "safe bool idiom", traits, private destructors, default methods (which are utter maddness in C++11) and template metaprogramming.
I'd then augment this simplified C+ with a powerful static invariant checker. You could say something like "guarantee x < 10; x = f()" and it could complain "you demanded x be < 10, but f() only guarantees x < 100".
"I'd love to be able to use something like Haskell, as a lot of my problems are functional in nature, and it'd be able to catch a lot of stupid bugs. But it is too esoteric to be realistically adopted by the community."
The esoteric, and what you need to do what you said, are nearly entirely partitioned from each other. Reading in a list of things, running some code over it, and spewing the results out is not that hard and will not involve anything you can't understand.
That said, even after some relatively extensive use of Haskell I still have poor intuition about how well it performs on such tasks... no, not because of "laziness", but because "naively" written Haskell still involves things getting boxed and other such performance killers that can take you halfway back to Python. I can say writing Haskell to do your described tasks isn't hard... I have a harder time promising you can write performant Haskell just by doing the obvious things. There's some promising work on doing fast numerical calculations, but it still seems like it's very easy to be doing something very fast, then change a bit of code, which silently breaks optimizations and suddenly it's slow for no obvious reason. (Note this is NOT unique to Haskell... all compiler optimizations can have this problem. It's just particularly acute in Haskell, but I've encountered it elsewhere. I've often wished for more transparent optimization feedback in many languages, or the ability to assert that I'm triggering certain optimizations so that if I do break them in the future, I find out at compile time. Alas, I've never seen such a thing.)
With C++11 you don't need the safe bool idiom anymore, you can simply define a "explicit operator bool() const". Since the conversion needs to be explicit, you won't have nasty surprises but it can still be used in an if (or while) normally as in this case the explicit conversion will be used implicitly. In other words, it works exactly like the safe bool idiom but is much easier to write.
> I need something that […] has interoperability with decades worth of C, C++ and Fortran code.
Assuming you meant more than having a good FFI…
When I judge the suitability of a language for a task in the abstract, I systematically ignore 2 very important factors: legacy code, and skill availability. I do as if everyone know every language, and we start from a mostly blank slate.
If I didn't ignore those factors, I wouldn't be judging the languages, I would be judging whole ecosystems, introducing a huge status-quo bias in the process.
---
The C+ you look for is probably possible. I bet it could be implemented a la CFront.
There are a lot of great libraries for Python, and it's much nicer and more productive. I use it whenever possible, esp. for making graphics, or when I can use optimized stuff like in numpy. However, most of the programs I write are of the type "loop over 10 million entries, perform a simple calculation, return a number". These are mostly IO bound, and one would think that this is a case where you could use a dynamic or interpreted language. But whenever I tried, the overhead for the large loop and the variable access in tight loops was too high, and the problem became CPU bound. So, in my experience, it has to be a compiled language (or at least something more performant then Python).
I'd love to be able to use something like Haskell, as a lot of my problems are functional in nature, and it'd be able to catch a lot of stupid bugs. But it is too esoteric to be realistically adopted by the community.
The ideal language for me would be "C+". A C++ lite, where you would ban most of the complications. You would still be able to write C++ libraries, but then use them from simple C+. A C+ user, as opposed to a library writer, would not have to know about the "safe bool idiom", traits, private destructors, default methods (which are utter maddness in C++11) and template metaprogramming.
I'd then augment this simplified C+ with a powerful static invariant checker. You could say something like "guarantee x < 10; x = f()" and it could complain "you demanded x be < 10, but f() only guarantees x < 100".