Why are we using C anyhow? I suggest it's mainly because of established codebases although the fact that it has very few dependencies makes it attractive for systems programming perhaps and low-level.

In the case of established codebases the issue is that we don't want to rewrite them because they're huge and not very well designed usually. There are no unit tests or not many and we cannot break ABI compatibility and so on. So change has a risk. Also you're trying to get other developers to agree to the change and they are often in a post-nuclear-war state about other technical decisions and certainly don't want to start another one about some language they don't understand.

What we really need is some way to progressively improve big codebases without having to swallow a huge pill. In other words I need to be able to work a file at a time with something that fits exactly into the build system that is building the C code.

At the moment I'm using ESQL to embed Informix queries - this is a subtly quite good language extension that certainly makes life better except of course that it ties us to a specific expensive database etc etc. As an improvement on C it works in it's limited sphere.

In this huge project there's so much code that it's hard to know what's the right way to do anything and the same solutions have been written again and again in slightly different ways.

Half the libraries have circular dependencies such that they only build with an odd little trick and it's extremely difficult to know the precise reasons why this design evolved or how to begin unpicking those dependencies. Without tests any change could be a disaster.

One established way of improving on C is to use a DSL or something like embedded TCL such that most of the time you're not actually writing C. The current project went the DSL route and it's very very much better than nothing but without a grammar the parser is hard to maintain. I've been on a project using TCL and that was excellent - loading and parsing a config file, for example, is something one almost never really needs to do in C and there are many bits of a program that TCL can do much more reliably and perfectly fast enough.

This ramble is trying to convey that a new language presents a problem to people who have 100 problems already. If you can make it help with those 100 problems then it will win.

Successful example: Converting to Git from SCCS is a huge pain but I've just done it (had to infer changesets from individual file version usernames and dates and times :/ ) but Git is well worth the trouble because it's so much less stressful to make mistakes with and vastly easier to do reviews and so on.