Re: [Vala] Vala++



On 04/04/2017 12:25 PM, Daniel Brendle wrote:
On 04/04/2017 11:47 AM, Mohan R wrote:
A request to gnome+rust language developers, Please keep dbus and glade
integration as easy as Vala. I enjoy writing GUI and dbus apps with Vala.
It's just awesome integration which I don't see in other language bindings.

I second this.

As a matter of fact there are many languages you can use gobject in. But
it doesn't necessarily feel right because you're supposed to follow the
patterns of the language (and naturally also want to do so) but you have
to follow GLibs pattern. About ten years earlier i started programming
against Gtk in python which was one of the more convenient ways to do so
at the time (before i tried coding Gtk in perl and C). Oh boy. It was
such a hazzle until I figured out which of the mechanics belonged to
python and wich ones belonged to glib and even that there is a
difference between python threads and glib threads. Each language brings
their own means (stdlib) of interfacing with system functionality and
GLib brings it's own. This will allways be confusing in any language
that does not follow the same principles as Vala and Genie. I've read
that you can use Rust without a standard library. Maybe this will
actually make it suitable for GObject code. I know i repeat myself, but
i am stoked to see the results.

I feel a bit weird discussing this stuff on the Vala-list, but since
that is where the communication is happening…

We did discuss resource embedding and "attributes" which I think is the
major value being referred to. Since the GObject integration (both
consuming and exporting C ABI) uses rust compiler plugins, we can do the
same to enable C♯/Vala style [foo] attributes. These are much easier to
implement in Rust plugins than writing a new language/compiler.

It's likely we'll want to find a way to integrate rust embedded files
with GResources.

I believe some of the wip prototype code does get/set/construct just
like Vala. We can create pretty much any syntax we want (within reason).

Of course, we only had a 3 day hackfest, so there is still plenty of
work to do. I assume we'll have a large group working on things at
GUADEC¹ this year, so if that interests you, consider going.

-- Christian

¹ https://2017.guadec.org/


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]