I've been thinking about what language I should choose if and when I
start writing a significant program using G* libraries. I don't want to
write GObjects in C any more. All that boilerplate, casting macros,
manual set up of vtables and explicit reference counting. I will make
mistakes with it.
C++ is an improvement, but tends to add more complexity and is still
prone to runtime bugs such as buffer overruns, and there are some quirks
in its G* bindings.
Vala is very attractive, but I'm afraid I have to side with the
doomsayers. The compiler doesn't have enough developers with the time
and expertise to maintain it adequately. That's frustrating enough when
you're relying on any project, but when it's a compiler it's even more
serious. Maybe its poor health has been exaggerated, and its benefits
outweigh the risks (after all, it seems to have an entire desktop
environment banking on it), but I'm not filled with confident.
So there's Python. It's rather nice, especially if you use type
annotations to get at least half-decent auto-completion in your
IDE/editor and the ability to catch some bugs before runtime. It's well
supported. But... its runtime has a poor reputation for efficiency, and
it can't truly multithread on multiple cores. Its GI bindings are
somewhat opaque ie it's difficult to find out what members a class has,
or a function's signature, if separate documentation hasn't been provided.
I see Rust is getting popular, but it appears to be difficult to learn,
and it doesn't have an object model that would make GObject fit in
naturally.
I've been writing an Android app in Kotlin for a few weeks. It takes a
bit more getting used to than Java or Vala for a C programmer, but I'm
enjoying it, and nobody seems to have a bad thing to say about it. I
thought it might even be worth using the JVM on Linux desktops/servers
for, but now I've discovered there's an LLVM target too, Kotlin-Native.
Look at this:
<https://victor.kropp.name/blog/kotlin-native-0.2-and-gtk/>. That DSL
implementation is so cool. Kotlin's object model in general fits quite
well with GObject I think, eg its interfaces support concrete methods
and abstract properties. It shouldn't be hugely difficult to develop an
automatic gir-to-Kotlin bindings generator.
One fly in the ointment is that Kotlin-Native doesn't have IDE support
yet, but that will come. It looks like using the JVM for development in
the meantime isn't really viable, unless whoever writes the bindings
generator is prepared to support two different modes, because it looks
like Kotlin-Native has its own way of interfacing with C that's
different from the JNI used by the JVM version.
--
TH
_______________________________________________
gnome-list mailing list
gnome-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gnome-list
