Hacker News Reader

Comment by pjmlp | Hacker News Reader

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++.

View on HN

Most non-C languages also come with GC/managed runtime whether you want it or not. So for someone who don't want that Rust could be a fitting choice.

Today yes. Not so 20 years ago.

Modula-2, Ada, Object Pascal were some of the alternatives without GC.

These are the ones I meant by "faded away".

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.

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.

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.

If you were making a general point and not about WMs in particular, why didn't you say that to begin with?

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 ;)

This is what caused me eventually to move from Turbo Pascal to C++ during the Windows 3.1 time frame.

I started to get fed up with writing bindings to libraries not directly supported by Turbo Pascal and pure C was a no go for me.

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.

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).

When I saw this article, I thought "I bet burntsushi wrote it". I've been learning a lot from reading your Go code lately.

Heh, thanks. I spent years of my life with X getting my perfect WM. I'm happy to say I got there. But I can't stomach much more of X. :-)

I was actually looking for your code when I posted, but somehow forgot to refer to it in the end.

Good work!

Java AOT compilers

Java AOT compilers? What Java AOT compilers?

I know about Excelsior JET ($$$$) and gcj (abandoned). Do you know of any free and good Java AOT compilers?

I don't care if they are free or not. The point is that is technical feasible and they do exist.

Most commercial JVMs like IBM Websphere for Real Time, Aonix and JamaicaVM, just to cite three examples, do offer AOT compilation.

Java on IBM i mainframes is translated to the same bytecode used by C and C++ (yes I really mean bytecode not Assembly, IBM i has a kernel JIT).

Then you have RoboVM, CodenameOne, JikesRVM, SubstrateVM.

SubstrateVM is done by the same Oracle Labs working on Graal.

RoboVM is how LibGDX guys are targeting iOS.

And Oracle is changing the OpenJDK to eventually support AOT compilation.

http://openjdk.java.net/jeps/197

Currently the only free on that might suit you, in case you only care about UNIX environments is RoboVM.

Thanks for taking the time to respond!

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.

https://docs.oracle.com/javase/8/docs/technotes/guides/deplo...

And the size of the native runtime has been reduced.

http://openjdk.java.net/jeps/148

> 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.

If you are on GNU/Linux, Mac OS/X check RoboVM.

http://www.robovm.com/

I sincerely apologize, I just now noticed you've answered my same query on other threads.

Reply on news.ycombinator.com