Eclipse & DTrace: Mono Tools?

As I mentioned earlier, Erik and Miguel were kind enough to give me a significant chunk of their time yesterday to get me caught up on Mono (not to mention other non-Mono or Linux subjects like Google Maps hacks – check out this recommendation of Erik’s). I’ll save my commentary on some of the specifics of our discussion for later, as some of the things we discussed are released, but in the meantime I wanted to comment briefly on a subject that their coworker, Joe Shaw, has been discussing recently – tools. Here’s the most important part:

The only downside to this story is that the bottleneck probably would have been more obvious to us if the profiler were more useful. That’s the main weakness in the Mono development platform right now: the tools. C# is a wonderful language, the compiler is fast, the toolchain isn’t totally retarded like C, the hackers fix our bugs, the community is vibrant and active, but man… the tools. So all of you out there, if you’re looking for something interesting and very helpful to hack on, take a look at tackling some development tools for mono: the debugger, the built-in profiler, deadlock detection, thread profiling, heap profiling, etc. I will buy you several drinks of a refreshing nature.

This constructive criticism certainly doesn’t come as a surprise, and to their credit Miguel and Erik took my suggestions/criticisms in stride, acknowledging opportunities for improvement without in the least getting defensive.

For my part, I still believe that an Eclipse / Mono pairing would be compelling and certainly would give Mono not only a strong foundation to build from, but one that’s won enterprise acceptance and recognition worldwide. Throw in the fact that being able to plug in to Eclipse would permit the Mono gang to play alongside the hordes of third party Eclipse extensions open up some potentially interesting ISV relationships, and to me the arguments for such a project outweigh the arguments against.

It’s easy for me to say that, however, given that I’m just an analyst. While I have some appreciation for the magnitude of shoehorning Mono into Eclipse, I’m not the one that has to resource and staff such a project (and no, open source is not a panacea that can magically solve these sorts of problems). Little things that I hadn’t even considered, such as code completion, loom as not insignificant projects. Sooner or later I do believe that someone’s going to claim those drinks of a refreshing nature from Joe, however, because the tools story – acceptable now – will need to be solidified as Mono gains in mainstream acceptance.

That was my reasonable (IMO, of course) suggestion to the Mono folks – not that they probably haven’t heard similar suggestions from other quarters. A more off the wall idea occured to me while reading Joe’s post from this morning, when I considered whether there might be an opportunity for DTrace to be applied to C# via Mono? Now hear me out, before you decide I’ve just gone DTrace crazy, seeking applications for it everywhere. The obvious objection to the notion is that, like Java – which is also mostly opaque to DTrace (or was, prior to some of the demos at JavaOne), Mono runs on a VM which makes the application of DTrace problematic. The next response might be that Dtrace is limited to Solaris, which is not exactly Mono’s native OS. But let’s take those in turn:

1. DTrace and the VM: While its true that Dtrace provides a fraction of the illumination to Java applications than it does to those written in, say, C, it’s also true that DTrace does provide some illumination into Java processes, as demoed by Loiacono and co at JavaOne. It’s also true that DTrace has been applied to non-C languages such as Python (as I was reminded by Bryan Cantrill).
2. DTrace Isn’t Available on Linux: No problem – Mono builds fine on Solaris, though as the guys told me yesterday its not packaged for that OS. Debugging on an environment other than what you intend to run on is not an ideal situation, but hardly uncommon (I’ve done it). And who knows, Solaris could be the build environment.

So assuming that such a bastardized union of technologies is even possible – a big if, I understand – what’s in it for both parties? Mono gets access to one the more sophisticated at runtime debugging tools on the planet, while DTrace becomes more functional and potential getting some of the Mono crowd looking at Solaris.

Off the wall, like I said, but Bryan and Miguel will both be at OSCON next week – might it be worth at least a quick chat? I think so.