The thing is, most languages can be used for writing a Window manager.
But since the alternatives to C and C++ kind of faded away from mainstream and they are anyway the UNIX system languages, most developers seldom look for alternatives.
With Rust, Go, D, Haskell, OCaml, .NET Native/Mono AOT, Java AOT compilers, hopefully developers will eventually realize that not everything needs to be coded in C or C++.
Last I checked the memory consumption of running xmonad (you know, written in Haskell) on my computer was a pittance; doesn't hog memory, and probably doesn't use enough memory to cause user-noticeable GC pauses.
Though if you're talking about applications in general, and not just WMs; yes, sure.
Yes it is more likely to be applicable to other apps other than WMs, but I also have integration in mind. So what if you want to write a WM like a library that can be used by whatever runtime a user may choose. Not sure that is a good idea but it sure would not be very portable if a GC must be carried inside the library. Memory consumption is not the only issue here.
Yeah, I've been using Xmonad for a couple years and it's just faithfully used very little memory and never crashed. Also, this is across 4-5 different laptops.
Most languages can be used for writing most things; however, for X11 window managers in particular, all of the APIs are exposed as C libraries, so the C family has a natural advantage. Other languages need an interface to those C libraries, a more idiomatic wrapper on top, and then a window manager can be written.
I've played with the Xlib libraries in Haskell and it wasn't the prettiest code I've ever written ;)
Not in the Go ecosystem. :-) We have a real, pure (concurrent) X client protocol implementation: https://github.com/BurntSushi/xgb (and of course, a WM: https://github.com/BurntSushi/wingo, which is hybrid tiling and stacking, kind of like Xmonad meets Openbox). /shameless plug
Of course, it's not all moonpies and pennywhistles. XGB only supports basic extensions like RandR, Xinerama, Render and Composite. But it's missing Xinput and XKB (which are monstrous).
I am a recent convert to C++ for the same reason (though not from Pascal but other high level languages like Prolog). I wrote my own Prolog interpreter with minimal footprint so I can still get an interactive prompt with a high level interface if I want to, but it is designed to be easy to expose C++ instead of the other way around.
I'd love a Java AOT compiler that produces native binaries with no additional dependencies. (I'd even be okay if, as a side effect, some Java features were not supported, making it technically not-Java.)
For small tools and utilities, the JVM requirement is quite onerous, especially when one does not know if the end user has Java installed, or if they do, what version.
Alas, the company I work for will not budget for a Java AOT compiler, and for my hobby programming, the commercial Java AOT compilers are far too expensive to justify.
I'll just keep hoping a good and free (or inexpensive) Java AOT compiler becomes available some day. I would even donate money and/or code if a serious project started.
> For small tools and utilities, the JVM requirement is quite onerous, especially when one does not know if the end user has Java installed, or if they do, what version.
There some efforts in this direction with the OpenJDK.
As of Java 8 there is an application packager that brings everything together.
> I'll just keep hoping a good and free (or inexpensive) Java AOT compiler becomes available some day. I would even donate money and/or code if a serious project started.
But since the alternatives to C and C++ kind of faded away from mainstream and they are anyway the UNIX system languages, most developers seldom look for alternatives.
With Rust, Go, D, Haskell, OCaml, .NET Native/Mono AOT, Java AOT compilers, hopefully developers will eventually realize that not everything needs to be coded in C or C++.