What Comes After 'C'?

In Time to Move On?, Jack Ganssle asks:

Are developers starting to think about moving beyond C and C++?

I enjoy C. It's fun. So is assembly language, and C removes assembly's drudgery. But C is fairly dangerous as it's ill-defined (the standard lists around 200 items that are in conflict or that may be implementation-dependent). It provides no protection for common pitfalls like overflows, it allows (some say it even encourages) poor memory management and pointer mayhem.

Blasphemy!

Or is it?

I feel C/C++ scales poorly as systems grow, and am encouraged to find that other alternatives can yield higher productivity with fewer bugs (indeed, projects get finished precisely because there are fewer bugs and therefore less debugging).

Well, yeah.

I think perhaps the answer to this question (as it is for most questions) is: "It depends."

Yes, C/C++ has it's share of problems that are not easily cured. And, perhaps, for larger projects (however that is defined), there are other languages that would make sense to at least consider.

But for small projects, the kind I'm most familiar with, where the MCU's capabilities are exceedingly modest (very little RAM and program memory), C is going to be very hard to replace.

And really, why would you?

Just as there are still some applications for which assembly language is the right choice, there are always going to be applications where C is the optimal choice.

For bigger projects -- again, it's hard to say with any degree of precision exactly where that cutoff is, but it's there, to be sure -- something "beyond" C/C++ is probably the right choice.

But what's the next step up from C/C++?