GXUI: A New Cross-Platform UI Library By Google

[Luke_Wolf]

The programming language does not determine the performance of a software.
Good performance is acheived through minimizing unnecessary computations, utilizing the right hardware (sometimes GPU, DSP, FPGA), keeping algorithmic complexity low, making good use of concurrency (both fine-grained like SIMD, coarse like multi-threading and distributing among cores/machines), minimizing and batching up I/O (disk and net), making efficient use of memory (including L1/L2 cache) and chosing the correct latency versus throughput characteristics.
Perceived performance can be enhanced through immediate and clear feedback to the user, including smart use of animations.

Different programming languages make various aspects of these tasks easier and harder, but the language alone solves *nothing*. That something is written in C++, C or ASM does not automatically mean it will perform well.

Well... Actually that's wrong. Programming languages DO in fact carry with them factors that influence the performance of a program. Functional languages can for example be aggressively concurrent by the compiler, and the more dynamic a language the more has to be shoved off to being determined at run time causing additional slowdowns vs a more static language where more things can be determined ahead of time. Garbage Collection implies that every so often the program will effectively pause to mark and collect the garbage, move the current in memory items into their appropriate generations, and so on. Not to mention that certain languages make going about things certain ways more or less difficult which effects how one goes about developing the software. Beyond that still questions like "How toolable is language X?" have significant effects on both the number of bugs in a program and the speed at which a piece a software is developed.

It's nice to believe that everything is up to the craftsman and that the tools he uses don't matter, but the simple reality is that this is not true. A good craftsman values a good set of tools and both despises and avoids those that harm his productivity.

[bnolsen]

Well... Qt is far more than just a GUI toolkit, it's effectively equivalent to the .NET Framework or the Java Platform libraries. It's a framework which you can build applications in, so comparing the two is pointless.

c++11 covers a lot of that functionality, c++14 even more.
I've been burned too much by 2 different code bases in the past that heavily used qt throughout.
None of them were pretty and its easier to harm maintainability with too much coupling.

[jonnor]

I don't know much about Gtk, but as far as Qt goes your the first person I ever heard refer to it as slow. Please elaborate. For the most part it gets compiled from C++ so don't know what you are comparing it to. As for learning I think you need to give it a few months of working with it (the same goes for any ToolKit). For starters the documentation and community for Qt are second to none.

The programming language does not determine the performance of a software.
Good performance is acheived through minimizing unnecessary computations, utilizing the right hardware (sometimes GPU, DSP, FPGA), keeping algorithmic complexity low, making good use of concurrency (both fine-grained like SIMD, coarse like multi-threading and distributing among cores/machines), minimizing and batching up I/O (disk and net), making efficient use of memory (including L1/L2 cache) and chosing the correct latency versus throughput characteristics.
Perceived performance can be enhanced through immediate and clear feedback to the user, including smart use of animations.

Different programming languages make various aspects of these tasks easier and harder, but the language alone solves *nothing*. That something is written in C++, C or ASM does not automatically mean it will perform well.

[Drago]

Why not just write Go language bindings for GTK or Qt instead?

Why write something that already exists:

http://mattn.github.io/go-gtk/

https://github.com/go-qml/qml

[uid313]

Language bindings

Why not just write Go language bindings for GTK or Qt instead?

[Luke_Wolf]

Probably Google is trying to leave Java on Android? Would make sense, also Java is slow as a turtle and C# is not much better.

Java actually isn't that slow at this point, but it is very memory hungry. However Dalvik is very slow to the point where Mono is significantly faster due to sgen and such. RyuJIT is faster than mono but I'm not sure how it compares with HotSpot at this point. That said I also don't see why you think that Go would be faster than Java, the Debian language shootout certainly doesn't support this.

[Kemosabe]

Please tell me this is gonna compete with Qt and GTK (and WPF)... I hate Qt and GTK, I hate them so fucking much! (GTK is ugly and outdated, Qt is pretty, but slow and a hardcore pain in the ass to learn and code in)

It can't get any easier than coding with Qt which is much more than only GUI by the way ...

[geearf]

For example?

An internal cousin of Azure for example.

[aksdb]

I am looking for a starter language for kids to learn some programming like the old 'logo' language.

If this is easy to learn, and contains enough gadgets to develop GUI apps quickly on Linux, Android, and Windows, it could fly and eat into Microsoft Visual Studio world.

Watch out, Redmond.

Then simply look at http://www.lazarus-ide.org . (There are also two other distributions that contain some cross compile utilities to directly get you running when developing for a bunch of platforms. Namely http://www.getlazarus.org and Codetyphon.)

[mike4]

Actually, some of the Microsoft distributed systems are also, at least part of, in C#.

For example?

Probably Google is trying to leave Java on Android? Would make sense, also Java is slow as a turtle and C# is not much better.