Glimpse: Programming language for rewrite?

[TrechNex]

This is a community decision that is discussed periodically on Matrix channels. This issue is intended to tracks pros/cons and the criteria we intend to follow when making this decision.

(Edit by Clipsey)
It would be preferred if other language suggestions follow the formular of the D suggestion. Making the formatting the same is p good for readability.

[LunaTheFoxgirl]

D

<Website | Language Tour>

Pros

• Easy C-like syntax that will be easy to learn for people comming from C# or Java (large portion of developers)
• Extremely fast compilation times w/ DMD
• LLVM based compiler (LDC2) for optimal code and ARM/Cross compilation
• Compiled to native code
• Optional garbage collection (for parts we really need to optimize)
• Garbage collector is deterministic & code controllable (There's some basic rules that the GC follows that allows to easily optimize for the GC)
• Constructs for garuanteed memory safety (SafeD)
• Powerful and human-readable metaprogramming
• ABI compatibility with C, making for optimal binding speed.
• Nice automatically generated bindings
• Nice tools to generate bindings to non-bound GLib libs
• Has a language server protocol implementation
  Officially supports:
  
  
  
  • VSCode
  
  
  • Atom
  
  
  • Sublime Text
  
  
  • Vim/Neovim
  
  
  • Emacs via Native & Protocol Impl.
  
  
  • GNOME Builder
  
  
• D has a standardized package manager and build system
• D has OOP which aligns more with GTK's OOP layout

Cons

• Multiple compilers with some lacking behind (GDC, SDC)
• Less hype than other languages.
• Smaller (but active via their Discord) community.
• DLS can be harder to set up on FreeBSD.
• D is harder to package with Meson (but possible)
• DUB only supports linking statically with referenced libraries.
  
  
  
  • (GtkD avoids this by binding to GTK at runtime via module constructors)
  
  
• It's harder to make entirely new GTK widgets based off the GtkWidget class (but doable via a mixin)

Projects that use D

• Tilix
• Various professional audio VST plugins
• Quantum Break
• Vibe.D
• Vectorflow by Netflix

Points raised and answers

• Support in IDEs tends to be through community plug-ins rather than provided out-of-the-box.
  
  
  
  • If built-in support is preferred there exists open source D specific IDEs like DLangIDE. Though I personally prefer a plugin inside an editor
  
  
• .The technology is not proven with a free software project as complex as ours (it may be good to see some real world examples of D being used that people would be familiar with)
  
  
  
  • Check list of projects, there's some AAA games, professional audio plugins, etc. inbetween.
  
  
• The language only recently went fully-free. GDC was only formally adopted as a GNU project in 2017
  
  
  
  • DMD went open source (on github) in 2017 as well, LDC2 has been open source since around 2008.
  
  
• Some would say that the language has been around for a while and if it still hasn't gained traction by now it may never happen
  
  
  
  • The main reason for D's lack of traction is because no large company backing it, it has very little in terms of advertising like other languages do. It makes up for that by being a genuinely good experience to code in.
  
  
• There is no saying what the support level from the community is likely to be in five years' time
  
  
  
  • The community has been active since 2006 and is starting to kick in to a higher gear as of late, even though the latest compiler revisions has mainly been deprecation of old D1 syntax and bug fixes.
  
  
• Newer alternatives such as Rust and Go seem to have better community support and long term backing by well-known organisations (Mozilla and Google respectively)
  
  
  
  • Corporate backing != the usefulness of a tool. The only real benefit that having a corporation behind it is that it creates hype within companies which then spread to developers.
  
  

(TODO: More Pros/Cons will be added)

[TrechNex]

Additional cons to D:

• Support in IDEs tends to be through variably-maintained community plug-ins rather than supported directly by IDE projects. (The counter-example that springs to mind is Visual Studio Code)
• The technology is not proven with a free software project as complex as ours (it may be good to see some real world examples of D being used that people would be familiar with)
• The language only recently went fully-free. GDC was only formally adopted as a GNU project in 2017
• Some would say that the language has been around for a while and if it still hasn't gained traction by now it may never happen
• There is no saying what the support level from the community is likely to be in five years' time
• Newer alternatives such as Rust and Go seem to have better community support and long term backing by well-known organisations (Mozilla and Google respectively)

Having started experimenting with it I do like it in principle as a language. Technically it's a great technology, but it seems like it is the non-technical human aspects that potentially hinder it as a choice.

[TrechNex]

Additional comments made in chat since edits made to Clipsey's post:

• The technical superiority of a language may not in and of itself make D the best choice. For example, the reason C, Java & Perl are so widely used is because it's the "lingua franca" that most people already know and a lot of existing codebases use them.
• Almost everyone who wants to maintain the codebase would have to learn D from scratch. It may be your opinion it's a shallow barrier to entry, but it is still a barrier to entry.

Edit: Link to programming language popularity on Github https://githut.info/
D is currently ranked 39th

[TrechNex]

Other options that were considered in chat. These will need to be expanded in this issue.

C++: Probably not fit for purpose. GTK bindings are autogenerated and may not be well-tested
Rust: GTK support is improving. Concerns about learning curve.
Go: Mentioned as an option. Needs further discussion
C: Mentioned as an option. Needs further discussion
Vala: Potentially an option worth considering. Concerns about how well maintained it is.
C#: Main argument is may deter anti-Microsoft types. GTK bindings may be limited
Python: Popular, but could cause performance problems

[BrainBlasted]

Some disadvantages for each:

C++

• Small development community, most apps written for GTK2/GNOME2
• Very few bindings for libraries outside of just GTK
• Bindings created pre-GObject-introspection, so there's more manual work to wrap libaries

Rust

• Currently bindings to subclass objects need to be written manually until the gir tool can generate them
• Learning the borrow checker could turn away potential contributors

Go

• Poor tooling experience (personal opinion)
• Can't link against newer GTK
• Bindings are completely manual

C

• Less safety guarantees than other languages

Vala

• Small developer group
• Slow to fix issues with existing tooling

C

• Small development community
• Few fully-fledged applications written with it
• Not supported for most GNOME tooling
• Likely will need to maintain infrastructure to support flatpaks

Python

• Errors show up at run-time instead of compile-time

D

• Not supported for most GNOME tooling
• Likely will need to maintain infrastructure to support flatpaks

[meltheadorable]

I'd just like to specify the criteria for an ideal language here, since it tends to be implied by the arguments either for or against each individual choice, but it'd be good to make them explicit:

Properties of an ideal language

Critical

• Complete and High-Quality GTK 3 and/or 4 Bindings
• Good C Interoperability, to allow use of existing libraries
• Good cross-platform building and packaging (especially windows, macOS, and flatpak for linux)

Important, but not (necessarily) dealbreakers

• Large existing developer community
• Performant
• Great learning resources
• Low barrier to entry
• Well-Maintained
• Support for Meson

Nice to Have

• Great IDE tooling
• Easy to write memory-safe software
• Other Complex GTK Software has been written in it
• Growing language community
• Integrates with GNOME tooling
• Fast Compilation

Open to additions & changes to this list, but this was my attempt to synthesize & rank what's been put forward so far between here & the chat room.

[Moth-Tolias]

golang is controlled by google, you should add that to the cons.

as a d learner I'd love to see a project like this use d

[BrainBlasted]

Thanks @meltheadorable. Based on that list, I would like to recommend Rust.

Rust

Critical

• Complete GTK3 bindings and WIP GTK4 bindings
• Can generate bindings to C libraries with specialized tooling for GObject-based libraries (with bindings for common libraries already generated)
• Cross-platform - supports Windows, macOS, and Linux (with a flatpak SDK maintained by the freedesktop-sdk team)

Important

• Growing development community, with companies like Mozilla and Microsoft moving to adopt it.
• Due to difficulty of writing the same program in different languages it's hard to guage performance, but Rust performs close to C or even better in some benchmarks.
• Great free learning resources, with the Rust Programming Language being a complete book available for free. There's also the reference which, while being less complete, helps fill in gaps from the first book.
• The greatest barrier to entry is the borrow checker, as few languages have something like it. Due to it's strictness for safety reasons, fighting it has potential to turn away new contributors. Past that, Rust's safety guarantees and memory management system make it far easier to make safe code when starting out than C.
• Well-maintained. Details on their governance model are here.
• Meson supports Rust, but not the primary buildsystem Cargo. You can get them working together with a custom target and a few scripts. See here for the sort of changes needed for proper integration.

Nice to Have

• Supported by common IDEs via plugin, language server, or natively. Note: This is a bit dated as GNOME Builder supports everything but debugging for Rust programs.
• Memory safe by default
• Fractal, Podcasts, Shortwave, my own app Social, and most of the GNOME Design tooling have all been written in Rust.
• Growing development community (explained above)
• Supported by GNOME Builder and has a freedesktop-sdk extension maintained by the freedesktop-sdk team.
• Incremental compilation can be fairly quick, though large builds from scratch can be slow

To me it ticks most of the boxes, and definitely hits all the important ones. I've worked with GTK-rs extensively and think it could be a good choice in the near future. The story around GNOME and Rust also seems to only be improving as more developers take interest.

[BrainBlasted]

An addendum: Debugging Rust depends on https://gitlab.gnome.org/GNOME/gnome-builder/issues/877 getting fixed. I'll look into that soon.

[sudo-give-me-coffee]

Why not C++ and Qt?

• Clean code
• Suports C programming style
• Isn't painful migrate from a version to another
• Binding with scripting languages is very easy
• Works great with lua
• Easy distribution with AppImage, Flatpaks and Snaps
• Compiles ui file as native code
• Supports Wayland and X11 very well

[LunaTheFoxgirl]

There’s already Krita filling that spot. As well you’d be sacrificing looking nice on one platform to look bad on all platforms (imo)

[TrechNex]

I'd love it if we went the Qt and C++ route 😄
However there's a not small number of GNOME project contributors in our project, and they will probably object!

[sudo-give-me-coffee]

@Member1221 I don't think that is a "place to fill" is a tool that solve the problem, is the best? Depends of a lot of things.

As well you’d be sacrificing looking nice on one platform to look bad on all platforms (imo)

No, Qt is the exactly oposite of it, qt is a toolkit that abstract c++, the same code teorically will run on all platforms suported without significative changes in code, your scenario applies more to GTK than Qt

Qt is easily to make a visual consistent over all platform too, is possible to set a Qt StyleSheet and/or force a a widget style hardcoded, with GTK is more complicated to do, in a simplified way GTK always follow system style, like this:

This is very problematic on a multimedia creation tool like GIMP/Glimpse.

The biggest problem with Qt apparently is the large GNOME project contributors in the project, like @TrechNex said

[TrechNex]

Ditto what @sudo-give-me-coffee said. The other cool thing is that for people who don't like C++ (boo!) they tend to pick up the signals-and-slots and Model-View-Controller stuff pretty quickly, as it's modeled after what you'd do if you were writing a smartphone app.

I quite like working with Qt, and have used it in a number of projects. I'd highly recommend it as a choice, particularly given how good the cross-platform tooling and docs are for it.

As I mentioned earlier, the sticking point is you're basically turning a GNOME app into a KDE one, and that could be controversial. I probably shouldn't prejudge on this, as it may be I'm making an assumption about how our own community would react.

[LunaTheFoxgirl]

The problem with Qt is that it tries too hard to look native everywhere, to the point where the application just looks boring.
GTK goes in its own direction, does work on other platforms; at once we’re at GTK 3-4 the UI will have a different flavour on Windows and macOS, not trying to be native but just being itself.

And yeah Qt would mean we’d need to migrate to C++ which would be a turnaway for many people, except already somewhat experienced C++ programmers.

[TrechNex]

I disagree with the notion that making your UI look native to the operating system it's running on is "boring", but taste is always a subjective thing. 🤷‍♂

Also given the code we are currently working on is mostly C, I don't think switching it up to C++ would turn away as many people as you'd think. However, as I was the only person on chat arguing in favour of that language when we last discussed language choice on Matrix I accept that arguing the point on this is probably not going to be a fruitful use of time or energy. 😅

[nirim000]

I'm mostly experience with embedded electronic, but rust seems like a easy choice.

[LunaTheFoxgirl]

@Member1221 I don't think that is a "place to fill" is a tool that solve the problem, is the best? Depends of a lot of things.

As well you’d be sacrificing looking nice on one platform to look bad on all platforms (imo)

No, Qt is the exactly oposite of it, qt is a toolkit that abstract c++, the same code teorically will run on all platforms suported without significative changes in code, your scenario applies more to GTK than Qt

Qt is easily to make a visual consistent over all platform too, is possible to set a Qt StyleSheet and/or force a a widget style hardcoded, with GTK is more complicated to do, in a simplified way GTK always follow system style, like this:

This is very problematic on a multimedia creation tool like GIMP/Glimpse.

The biggest problem with Qt apparently is the large GNOME project contributors in the project, like @TrechNex said

That only applies for GTK2, once we port to GTK3 the style will be Adwaita on all platforms.

[dreamer]

And yeah Qt would mean we’d need to migrate to C++ which would be a turnaway for many people, except already somewhat experienced C++ programmers.

It would be also a turnaway for some experienced C++ programmers ;)

As for now - I think any kind of (gradual, careful) rewrite is very long-term goal, and initial releases will stick to C for pragmatic reasons. When the time will be right for introducing the second language in the main codebase, I would vote for Rust - on the first glance (I haven't looked deeply into Glimpse source code yet), it checks many boxes (prevention of multiple classes of bugs, C-interop, great tooling), language edition 2018 is quite nice to pick up ("fighting the compiler" is not so prevalent any more), it has very welcoming, helpful and focused community and attracts a lot of attention due to recent announcements from Microsoft, Intel, Linux (kernel team) and Mozilla; Gtk-Rust interop is also steadily improving. It is also consistently voted the most loved language on StackOverflow (4 years in the row now), so it's likely to attract some much-needed developer attention.

[LunaTheFoxgirl]

And yeah Qt would mean we’d need to migrate to C++ which would be a turnaway for many people, except already somewhat experienced C++ programmers.

It would be also a turnaway for some experienced C++ programmers ;)

As for now - I think any kind of (gradual, careful) rewrite is very long-term goal, and initial releases will stick to C for pragmatic reasons. When the time will be right for introducing the second language in the main codebase, I would vote for Rust - on the first glance (I haven't looked deeply into Glimpse source code yet), it checks many boxes (prevention of multiple classes of bugs, C-interop, great tooling), language edition 2018 is quite nice to pick up ("fighting the compiler" is not so prevalent any more), it has very welcoming, helpful and focused community and attracts a lot of attention due to recent announcements from Microsoft, Intel, Linux (kernel team) and Mozilla; Gtk-Rust interop is also steadily improving. It is also consistently voted the most loved language on StackOverflow (4 years in the row now), so it's likely to attract some much-needed developer attention.

The learning curve of rust is still like a brick wall/vertical line. (But also the fact that I mentally can't handle rust, too stressful.)
I believe we should stick to something that has some form of OOP and is c-like to stay in territory that is easier to adapt to.

[BrainBlasted]

I don't think OOP will be super important to keep working with GTK, especially if we decide to move to GTK4, which prefers composition over subclassing.

[nirim000]

I decided to try for picking up rust, for my foray into pc dev, so i will gladly contribute if it's chosen. I'm just happy a good open source alternative to Photoshop is in development for Windows. Anyway i think picking up a new syntax bug a lot of people and rust is similar enough to c++ syntax wise, to add a pro.

Edit: tired just forgotten some word.

[Laeeth]

"Multiple compilers with some lacking behind (GDC, SDC)"

How is the existence of an experimental compiler a disadvantage? Amaury Sechet created SDC and it is still under development but clearly he has his hands full as the technical lead of Bitcoin Cash ABC.

How is the existence of LDC in addition to DMD a disadvantage? LDC doesn't lag behind much (seems to me more like weeks). DMD is easier to hack on and compiles faster, so developing on DMD (and putting new features in there first) makes sense. LDC generates faster code but more slowly (compared to DMD).

SDC is an experiment that nobody uses because it is not yet ready. LDC, GDC and DMD use the same front-end. Obviously they use different back-ends otherwise they would be the same compilers...

Are you sure dub only supports linking statically? I'm not sure that is right.

Is there something special about complexity in a free software project? I think a file system is quite a complex endeavour - Weka.io went from zero to building the world's fastest file system in five years, without anyone having prior experience of D (other than a couple of people they had as specialist consultants part-time). Sociomantic another example.

DMD has been openly developed for a decade - front and back ends. It was a technical legal question relating to getting an agreement from Walter's old company. Nothing much has changed apart from perceptions. He just had to get people to ask him if they could redistribute and he always said yes.

D has no traction? Well I think a decade ago the only people crazy enough to use it in production for a serious project might have been Sociomantic. (And perhaps even some people now there might have thought it crazy). These days if you look at organisations using D it's quite a different picture. We're using for our analytics across the firm as well as a domain-specific functional language (quite a large domain) at a $5bn asset management company.

I think a key point is that D is a very ambitious language - a general purpose language for getting work done when many other newer languages have been more suited to a particular domain. So since use is spread out across many domains, one is much less likely to encounter people in your domain also using D - contrast with Go, for example. This has costs and benefits - a major benefit for commercial users is that you encounter people in other domains that you can learn from and have knowledge transfer.

Most code is not open-source but developed within enterprises and academe. Sociomantic only recently open-sourced some of their work, and although at Symmetry we have started open-sourcing work it's quite unusual for our industry. Same thing with Weka.io - they only open sourced their Mecca library after 4-5 years of using D to solve their problems.

I personally think it's much more anti-fragile and a positive thing that D is not under the sway of one company. We hosted dconf this year, and Atila Neves - a consultant to us - has taken over day-to-day leadership from Andrei Alexandrescu. I wouldn't want to end up being the only commercial entity involved with D because the strength of D comes from its usefulness across multiple domains and if we were to try and influence it in a direction that optimised to our niche it would be self-defeating.

[bachmeil]

A few relevant points related to D that I didn't see mentioned above:

• You can include C header files directly using dpp. You can reuse all existing C libraries and call all the functions the same way as you do now, or you can write your own wrappers with additional functionality, but the point is if it's available in C you get it for free in D.
• If you want to add D to a C project incrementally, there's -betterC mode. You only get a subset of the language, but you can replace your current project piece-by-piece without going through a full rewrite. No surprises where you find out that some of the rewritten parts aren't working. Then once a big chunk of the code is written, you can make the switch to use the full D language and keep using the parts written in betterC mode. This is essentially refactoring rather than rewriting, so it's not as much fun, but refactoring has its advantages.
• It's not a project run by a behemoth like Google or Microsoft, but it does have some support, like Symmetry Investments. Projects like eBay's TSV tools were written in D.

[LunaTheFoxgirl]

@Laeeth The downside is that some compilers will lack features not present in DMD which might cause compilation issues (have happened to me in the past)
That's the only downside to them, SDC, LDC2 and GDC are awesome projects and I think the choice is great. It's just an important note for people so they don't get confused if something fails to compile with one compiler.

The place where that issue is the biggest is with GDC since it has a somewhat slower release cycle. (Other than SDC, but its still early WIP)

I'm the main advocate for D for this project (and it's my favourite language to use for pretty much all of my personal projects nowdays). So don't see the negatives as something I say because I dislike the language, it's because I like the language and hope those things get solved in the future :)

DUB only supports liking statically to dependencies, you can't have dynamic dependencies with dub at current time (dub will throw a warning then link statically)

[LunaTheFoxgirl]

@bachmeil

• DPP will probably not be used if we chose to use D, as it adds extra tool overhead.
• The UI rewrite will happen from scratch, so we won't need betterC
• And yeah, i see that as a pro too. (Though some see it as a con)

[maxhaton]

I don't know if it's been mentioned or not, but D's builtin C++ interop is probably the best available (e.g. ABI is matched down to vtables and templates)

[nordlow]

DMD's compilation speed is far superior to most other modern languages (except GCC C compiler but C is not modern). Even more superior is DMDs and LDCs speed of performing semantic code analysis. I'm currently experimenting with the speed of semantic analysis for different languages at https://github.com/nordlow/compiler-benchmark.

If anybody is interested I can try adding a version of the benchmark that performs a normal object compilation for the same languages.

I find Rust's compiler unbelievably slow at doing semantic analysis (79 times slower than for D!) for such a simple code example I generate in this benchmark. Especially when taking into account the time and money the Rust compiler team has put into optimizing the compiler with various intermediate layer caching phases. D's compiler has none of that (yet). Also note that D's compiler is completely single-threaded. Also worth considering is the fact that the generated test code doesn't contain any use of reference types at all (neither in D nor Rust) meaning the borrow-checking in Rust shouldn't need to kick in at all.

Running it as

./benchmark --function-count=45000 --run-count=10

on my system outputs

Code-generation:
- Generating generated/c/sample1.c took 0.394 seconds (C)
- Generating generated/c++/sample1.c++ took 0.421 seconds (C++)
- Generating generated/java/sample1.java took 0.400 seconds (Java)
- Generating generated/d/sample1.d took 0.415 seconds (D)
- Generating generated/rust/sample1.rs took 0.401 seconds (Rust)
- Generating generated/zig/sample1.zig took 0.396 seconds (Zig)
- Generating generated/go/sample1.go took 0.401 seconds (Go)
- Generating generated/v/sample1.v took 0.391 seconds (V)
- Generating generated/julia/sample1.jl took 0.404 seconds (Julia)

D:
- Checking of generated/d/sample1.d took 0.353 seconds (using "/home/per/.local/dlang/linux/bin64/dmd")
- Checking of generated/d/sample1.d took 0.388 seconds (using "/home/per/.local/ldc2-1.18.0-linux-x86_64/bin/ldmd2")

Clang:
- Checking of generated/c/sample1.c took 1.105 seconds (using "/usr/bin/clang-8")
- Checking of generated/c++/sample1.c++ took 1.410 seconds (using "/usr/bin/clang++-8")
- Speedup of D over Clang: 3.18
- Speedup of D over Clang++: 4.19
- Checking of generated/c/sample1.c took 1.230 seconds (using "/usr/bin/clang-9")
- Checking of generated/c++/sample1.c++ took 1.550 seconds (using "/usr/bin/clang++-9")
- Speedup of D over Clang: 3.49
- Speedup of D over Clang++: 4.53

GCC:
- Checking of generated/c/sample1.c took 0.380 seconds (using "/usr/bin/gcc-8")
- Checking of generated/c++/sample1.c++ took 0.936 seconds (using "/usr/bin/g++-8")
- Checking of generated/c/sample1.c took 0.404 seconds (using "/usr/bin/gcc-9")
- Checking of generated/c++/sample1.c++ took 1.048 seconds (using "/usr/bin/g++-9")
- Speedup of D over gcc-9: 1.17
- Speedup of D over g++-9: 3.09

Go:
- Checking of generated/go/sample1.go took 1.221 seconds (using "/usr/bin/gccgo")
- Speedup of D over Go: 3.48

V:
- Checking of generated/v/sample1.v took 2.893 seconds (using "/home/per/Work/v/v")
- Speedup of D over V: 8.23

Zig:
- Checking of generated/zig/sample1.zig took 4.306 seconds (using "/snap/bin/zig")
- Speedup of D over Zig: 12.20

Rust:
- Checking of generated/rust/sample1.rs took 27.590 seconds (using "/home/per/.cargo/bin/rustc")
- Speedup of D over Rust: 78.98

Java:
- Checking of generated/java/sample1.java took 4.798 seconds (using "/usr/bin/javac")
- Speedup of D over Java: 17.00

This is with DMD built with LDC for an additional 20 percent drop in compilation time using DMD master and rustc master as of 2019-10-28.

[chaomodus]

In general I don't really care which language this is in, but I find the arguments for D fairly compelling in general. From a personal stylistic standpoint it really suits my thinking. I'm not incapable of Rust or Golang or C++ but they don't work as well for me.

If I had to rank available options, just from my perspective and based on my tastes right now it'd be:

• Some kind of compiled Python - or not compiled but people complain about performance which I don't find in general to be compelling but I wouldn't fight about this)
• D
• C++
• Rust or Go

Not that this has any particular gravity, nor a any real objective reasoning, just based on my personal programming preferences.

[bachmeil]

@Member1221

Just to elaborate on this point:

DPP will probably not be used if we chose to use D, as it adds extra tool overhead.

You should only need to run dpp once to generate all the bindings to the existing C code. You shouldn't need to run it again unless you add more C code to the project later, so dpp won't need to be a build dependency.

[Laeeth]

@Laeeth The downside is that some compilers will lack features not present in DMD which might cause compilation issues (have happened to me in the past)
That's the only downside to them, SDC, LDC2 and GDC are awesome projects
Yes, but you give the impression you're just going by hearsay rather than practical experience when you keep referring to compilers that don't exist!

SDC to my knowledge can't even compile Phobos. It's not meant to yet - it's an experimental compiler at a relatively early stage of development. You won't have trouble with it not keeping pace with dmd because it won't in its current incarnation be able to compile your code anyway. So when you refer to it as being relevant to whether or not you should use D it creates the perception you are just doing a tick box exercise.

Similarly LDC has been pretty current with DMD - weeks behind these days. Five years ago it was much more behind, but that was five years ago.

D has had fully free compilers for a long time, btw. And DMD is now fully free anyway.

The place where that issue is the biggest is with GDC since it has a somewhat slower release cycle. (Other than SDC, but its still early WIP)

You're confusing people by mentioning SDC at all, I think.

DUB only supports liking statically to dependencies, you can't have dynamic dependencies with dub at current time (dub will throw a warning then link statically

You might be right about a dub dependency but of course you can build a dynamic library and of course link to it.

[jacob-carlborg]

You should only need to run dpp once to generate all the bindings to the existing C code. You shouldn't need to run it again unless you add more C code to the project later, so dpp won't need to be a build dependency.

Can DPP output bindings? If not, there's DStep [1] which is intended to do that.

I would like to add to what Laeeth has already said, there are several companies that are using D as their main language and more companies that are using it as one tool among others [2]. One company that has not been named is Funkwerk, which is using D as its main language. They operate in the south of Germany and provide traffic information for transportations (like trains and similar). If you been in south of Germany and there's been some information displayed about a late train, that's most likely Funkwerk and D behind the information.

The technology is not proven with a free software project as complex as ours (it may be good to see some real world examples of D being used that people would be familiar with)

To add to what's already been mentioned:

• Mecca [3] - General purpose library used Weka-IO. A company using D as its main language
• Ocean [4] - General purpose library used Sociomantic. A company using D as its main language
• DWT [5] - A GUI library. A port of the Eclipse Java library SWT to D. Around 400k lines of code and comments/documentation

I'm not sure if there's a need for Glimpse (but most likely since it's going to display windows) but D is, in addition to being ABI compatible with C and C++, ABI compatible with Objective-C as well [6].

[1] https://github.com/jacob-carlborg/dstep
[2] https://dlang.org//orgs-using-d.html
[3] https://github.com/weka-io/mecca
[4] https://github.com/sociomantic-tsunami/ocean
[6] https://dlang.org/spec/objc_interface.html

[Laeeth]

DPP can output bindings but it's intended to be used to be able to #include. Dstep is definitely worth exploring.

Mercedes autonomous car research in US, Audi in Munich are also using D.

I think it's a secret weapon for disruptive innovation that is only available to people who are suited to use it. My competitors shouldn't use D because it's not right for them.

One more mention. A company that designs great big ships is using D to automatically port a few hundred k lines of extended Pascal to D.

[CrazyPython]

D

Incomplete list, but ok.

Critical

Good C Interoperability, to allow use of existing libraries - DPP let's you include any C header in D. D links with C directly.
Good cross-platform building and packaging (especially windows, macOS, and flatpak for linux) - Just use C/C++ tools. For example, the GNU Debugger works out of the box with D.

Important, but not (necessarily) dealbreakers

Large existing developer community - You can use C libraries.
Performant - [on five out of seven TSV utility benchmarks, the D tool is the fastest, beating TSV tools written in Rust)[https://github.com/eBay/tsv-utils/blob/master/docs/Performance.md)
Great learning resources - D is so easy to learn the specification is all you need
Low barrier to entry - The D specification is around 30 pages long and is well-written.
Well-Maintained - D is actively developed.

Nice to Have

Fast Compilation - The DMD Compiler can compile itself from scratch in under 3 minutes, including the backend written in D and the forntend.

---

You can write a compiler that automatically converts C code to D. Many simple macros can be replaced with manifest constants, templates or compile-time reflection, complex ones would be handled with #define.

D with -betterC does not use the DRuntime or the D GC. You could easily convert C code to D.

[BrainBlasted]

Some things to consider regarding C: Since this is a GTK project, we the most important thing is how well it interfaces with Glib/GObject. If you're not familiar with it, GObject is an object orientation system for C. It's different enough from vanilla C that I don't think it would work well using the C headers directly.

Some additional questions we should consider:

• Does it work with GObject Introspection? This would allow us to implement a plugin system, and allow for plugins to be made with any language that supports GObject Introspection like Python, Javascript, and Vala in addition to C. The languages I know that support this are Rust, C, and Vala.

• How much buy-in is there from GNOME developers? The best resource available when working on GNOME apps is being able to talk with other developers about your issues and share code. It's easiest if you can share code that will be easily read by most developers. C is obviously the top contender in this area.

[LunaTheFoxgirl]

@BrainBlasted There's no current GObject Introspection system to my knowledge. But even then I don't think we should tie our plugin system to glib and rather have it be a more state based system, if that makes sense? (With D, we could use D as the plugin language and avoid most of the glib stuff to begin with. Since D allows interop with C and C++ it's possible for folks to then make plugins that utilize C and C++ code)

The "buy-in" from GNOME is small. But there's a major GTK project made in D (Tilix) and the gtkd folks seems pretty helpful so far.

[TrechNex]

Removed my previous comment! The point about GNOME buy-in to D is correct (I misread it as GNOME buy-in to this project. That'll teach me for writing comments in the small hours of the morning! 😅)

[nordlow]

@CrazyPython: "Fast Compilation - The DMD Compiler can compile itself from scratch in under 3 minutes, including the backend written in D and the forntend."

I presume you mean 3 seconds. Or do you mean compiling dmd, druntime and phobos all with unittests? If you mean only dmd without tests can you please rebenchmark and update your comment?

[probonopd]

C++/Qt. Cross-platform, runs even on Haiku.

[probonopd]

However there's a not small number of GNOME project contributors in our project, and they will probably object!

Isn't that long history, back from the time when Qt was not GPL'd yet?

[TrechNex]

FWIW @probonopd that would have been my preferred choice. :)

However, we are forking a GNOME project with some GNOME contributors and anticipate using GNOME libraries (BABL and GEGL) so there are good technical reasons behind it being discounted as an option. C++ also turned out to be wildly unpopular in previous discussions, which made me sad.

One of the cool things about my not being a "BDFL" though is that the collective sometimes take "the path less trodden", and that can lead somewhere much more interesting than the project might have gone otherwise. :)

[Laeeth]

@Member1221 https://github.com/rtbo/glib-d/tree/master/source/gobject looks like gobject bindings in case helpful

[probonopd]

@TrechNex

However, we are forking a GNOME project

So this is the chance to drop the legacy technical debt and start fresh as a cross-platform, cross-desktop project ;-)

@BrainBlasted

Small development community, most apps written for GTK2/GNOME2

Actually, almost all of the cross-platform applications I use are written using Qt. Please don't spread FUD about "small development community". In terms of real-life applications, I'd say the crowd developing cross-platform applications using things like Qt and, yes, Electron (like it or not), is _much_ larger than the few folks who are not on the cross-platform bandwagon yet and still think it's worthwhile to write applications for GNOME only.

BABL and GEGL

Being C libraries, I would assume these can be called from C++.

C++/Qt. Cross-platform, runs even on Haiku.

It it is a factually correct statement. Many of the Qt based apps like Krita are there on the Haiku desktop system, but not the GNU Image Manipulation Project (and likely never will be, because it requires Gtk which is apparently much harder to port).

[TrechNex]

There are also Qt bindings for D: https://github.com/MGWL/QtE5

[BrainBlasted]

Please don't spread FUD about "small development community".

The context of that comment was entirely around how each language would work for a GTK app and the community of GTK developers for that language, not a comment on the language community as a whole.

[CrazyPython]

@TrechNex The Calypso compiler can use Qt-C++ directly. It has Calypso-Qt, which just uses D's metaprogramming features to implement Qt MOC. Calypso may not be up-to-date with the upstream LDC compiler though-- you're welcome to help make it up-to-date though.

[seagetch]

I recommend to port GUI related codes gradually to web-based technology like html5 design and javascript (or typescript.)

Once I tried to port GimpImageWindow to WebKit-1 webview (hiring Embed widget framework that was only available in WebKit-1.) Some quality issues are remaining, but technology is well probed actually.
See https://github.com/seagetch/gimp-painter/tree/webkit for more details.

Unfortunately, Embed widget is not available in WebKit-2 and Chromium-based technology though.

Many power-user can enhance GUI easily with html5 design template and javascript (like firefox.) if we port GUI to web-based technology.

[stavpup]

One of my favorite apps:

https://wiki.lazarus.freepascal.org/Overview_of_Free_Pascal_and_Lazarus

https://wiki.lazarus.freepascal.org/LazPaint

LazPaint was started to demonstrate the capabilities of the graphic library BGRABitmap. It provides advanced drawing functions in Lazarus development environment. Both provided a source of inspiration for the other and finally LazPaint became real image editor. Thanks to the help of Lazarus community, the program has been compiled on Windows, Linux and MacOS X.

[TrechNex]

Notes taken verbatim from Matrix discussion about GTK versus Qt:

• Qt supports OpenGL ES, less so OpenGL (There's some major differences that impact the speed of what we want to do)
• Qt supports Vulkan and MoltenVK (but there's major code amount overhead doing so)

• GTK supports OpenGL, less so OpenGL ES (makes it hard to port to mobile)

• GTK does not support Vulkan out of the box in GTK3, dunno about GTK4. (No Vulkan backend possible at current time?)

• macOS has some issues that makes installation of Glimpse more difficult in the future without doing modifications that system admins might not want to do. (Deprecation of OpenGL and Noterization problems)

• Qt supports macOS

• GTK currently has a lot of problems on macOS

• GTK applications look unique/different on non-GNOME desktops out of the box, and does support CSS as well (a positive to me)

• Qt tries to look native on everything, but can (with work) be skinned with CSS to look unique.

• Qt has native support for dockable windows

• GTK doesn't, there's some projects that adds such to GTK but they tend to look off.

[LunaTheFoxgirl]

@seagetch

I recommend to port GUI related codes gradually to web-based technology like html5 design and javascript (or typescript.)

Once I tried to port GimpImageWindow to WebKit-1 webview (hiring Embed widget framework that was only available in WebKit-1.) Some quality issues are remaining, but technology is well probed actually.
See https://github.com/seagetch/gimp-painter/tree/webkit for more details.

Unfortunately, Embed widget is not available in WebKit-2 and Chromium-based technology though.

Many power-user can enhance GUI easily with html5 design template and javascript (like firefox.) if we port GUI to web-based technology.

That is probably not going to happen; web based technology adds a whole bunch of overhead that would harm the end product. As well maintainability would be a lot worse, together with the ability to make fast (native) plugins easily would also be lost.

[Waqar144]

Notes taken verbatim from Matrix discussion about GTK versus Qt:

* Qt supports OpenGL ES, less so OpenGL (There's some major differences that impact the speed of what we want to do)

* Qt supports Vulkan and MoltenVK (but there's major code amount overhead doing so)

* GTK supports OpenGL, less so OpenGL ES (makes it hard to port to mobile)

* GTK does not support Vulkan out of the box in GTK3, dunno about GTK4. (No Vulkan backend possible at current time?)

* macOS has some issues that makes installation of Glimpse more difficult in the future without doing modifications that system admins might not want to do. (Deprecation of OpenGL and Noterization problems)

* Qt supports macOS

* GTK currently has a lot of problems on macOS

* GTK applications look unique/different on non-GNOME desktops out of the box, and does support CSS as well (a positive to me)

* Qt tries to look native on everything, but can (with work) be skinned with CSS to look unique.

* Qt has native support for dockable windows

* GTK doesn't, there's some projects that adds such to GTK but they tend to look off.

+
Learning resources for Gtk are almost non existent.

Writing code in GTK/C or using Gobject is a huge pain and is quite complicated. Qt is much more simpler and readable and easier to maintain.

For a bigger development community to work on this project, the first thing that needs to happen is saying goodbye to Gtk.

Also, there's V Language @vlang , which looks quite interesting. Perhaps the author @medvednikov can comment.

[nordlow]

I updated the compiler benchmarks above to include Zig, Java and V. Further the benchmarks now show the _minimum_ of 10 runs for more stable metrics. The Rust compilation previously ended prematurely because of an error. This has been corrected and now the Rust semantic checking is even more incredibly slow. Currently 77x slower than the fastest D!.

Note that neither Java nor V currently supports separate semantic checking so these benchmarks produces an object file.

[medvednikov]

@nordlow please make sure you use a production version of V: v -o v -prod v.v

[medvednikov]

Regarding GTK vs Qt, I spent a lot of time on this topic when working on V ui. I ended up writing a new toolkit for Linux from scratch:

Qt is very complex and is hard to call from C. They use their own extended C++, which makes things even more complicated.

GTK is a mess with an unstable API and no clear vision unfortunately.

[nordlow]

@nordlow please make sure you use a production version of V: v -o v -prod v.v

I assume you mean running

./v -o v -prod v.v

at the top-directory of https://github.com/vlang/v.

I reran the benchmark for V. No significant change in run-time, though. Numbers have been updated above.

[medvednikov]

Right, I have the v binary symlinked to /usr/local/bin/v :)

[medvednikov]

The C to V translator which covers 100% of the C standard will be out next month, it'll be interesting to test it on a big project like yours.

So far I've been focusing on SQLite and DOOM.

[seagetch]

@seagetch

I recommend to port GUI related codes gradually to web-based technology like html5 design and javascript (or typescript.)
Once I tried to port GimpImageWindow to WebKit-1 webview (hiring Embed widget framework that was only available in WebKit-1.) Some quality issues are remaining, but technology is well probed actually.
See https://github.com/seagetch/gimp-painter/tree/webkit for more details.


Unfortunately, Embed widget is not available in WebKit-2 and Chromium-based technology though.
Many power-user can enhance GUI easily with html5 design template and javascript (like firefox.) if we port GUI to web-based technology.

That is probably not going to happen; web based technology adds a whole bunch of overhead that would harm the end product. As well maintainability would be a lot worse, together with the ability to make fast (native) plugins easily would also be lost.

Hi,
I've hust started new project to make graphics editor using GEGL, libmypaint,and electron (that means web-based.)
Integration with existing native code is fairly easy.
I measure the performance,and found that bottleneck sits in GEGL and libmypaint side, not in JS side for now.
As per productivity, you can see vs-code that improve productivity much using web-based technology.
Just FYI.
https://github.com/seagetch/parchment

[TrechNex]

@seagetch that looks very cool! If it helps, GTK supports JavaScript so that might help with your work on the front end.

[TrechNex]

For fair disclosure at this point, I think the working group looking into Glimpse Image Editor 2.x seem to be leaning towards the D programming language. Rust is also in the mix as a potential option.

V as a language seems to have popped up from nowhere. While it looks like an intriguing choice, it is still "alpha stage", lacks documentation and does not seem to be supported by the wider free software community yet. While it is not feasible right now, we will be keeping an eye on it.

[TrechNex]

I have also been arguing in favour of Qt, but I think in practise we will be using GTK because the majority of our contributors come from the GNOME project and we want to keep them interested and engaged.

[Waqar144]

Problems with GTK or why it can be a bad choice

@TrechNex
@glimpse-editor community

• Learning resources are almost non-existent. Even StackOverflow has maybe a couple of hundred questions on Gtk. This means no new comers. A lot of people look online for learning new stuff, solving questions. Gimp suffers from the same problem. Almost no new contributors because people don't know Gtk and people are often scared of writing in C and they don't want to learn Gtk. There are no Gtk jobs, there is not much benefit in learning Gtk, it isn't being used in the industry as much as Qt. A lot more people know Qt.
• Bad documentation that doesn't tell you much
• Gtk is difficult and complicated
• Portability is going to be a pain, even for Linux OSes. KDE devs spend a lot of time trying to get gtk apps to run correctly in KDE and they still haven't succeeded completely. The same can't be said about Qt or even apps using KFrameworks.
• Glimpse is an app that doesn't just need good devs. It needs people with good mathematics and image processing knowledge and so on. Glimpse won't get far without such people. Such people will definitely find Gtk very difficult and will usually not be able to find many answers to their questions online.
• Gtk 4 is coming soon, no one knows what's gonna happen or what's happening in there except maybe the Gtk/Gnome folks. Gimp is still in Gtk 2 land. They haven't been able to complete the Gtk-3 port yet.

Is Glimpse going to run in GNOME only? Cause if you go that way, that's what it looks like. Devs should be able to focus on development rather than wasting half the time getting stuff to work on other platforms.

This post isn't in favour of Qt. Don't choose Qt(Although writing software in Qt is a much much better experience than Gtk). Choose anything else, but not Gtk.
If a rewrite is being planned, which in itself is a very ambitious quest, going down the same road as Gimp isn't ideal.

PS: I don't intend to hurt anyone's feelings, these are just my opinions and if you don't agree that's fine.

[TrechNex]

The intention with the rewrite is to create a new UI wrapper & plug-in framework that still uses GEGL, BABL & (possibly) MyPaint. So being able to import those subcomponents and their dependencies is a prerequisite.

I agree on portability as using GTK basically precludes ever producing a macOS version unless we port it for them. However, it is still usable for Windows and Linux and following the GNOME Human Interface Guidelines would still be a significant benefit from a user experience point of view.

The problem with criticizing both GTK and Qt means is that we are left with Electron as a cross-platform solution, which currently seems to be a non-starter with the project as people have concerns about the underlying hardware performance (this is particularly important when doing professional rather than hobbyist tasks).

The other solution is writing a different UI for each operating system (eg WPF for Windows, GTK for Linux and Cocoa for macOS), but we are deeply unlikely to ever have the resources to maintain three separate codebases.

Like most technical decisions (and life in general) we have to make trade-offs. No one technology will suit everyone, so we have to determine which tool can reasonably achieve our objectives and still bring enough people with us when we start using it.

[Waqar144]

The intention with the rewrite is to create a new UI wrapper & plug-in framework that still uses GEGL, BABL & (possibly) MyPaint. So being able to import those subcomponents and their dependencies is a prerequisite.

How about we rewrite GEGL and BABL too? It's not impossible.

I agree on portability as using GTK basically precludes ever producing a macOS version unless we port it for them. However, it is still usable for Windows and Linux and following the GNOME Human Interface Guidelines would still be a significant benefit from a user experience point of view.

Yes, and there are a lot of Mac users, a lot more than Linux. Choosing Gtk while knowing that it's going to give us a lot of problems is not a good decision.

The problem with criticizing both GTK _and_ Qt means is that we are left with Electron as a cross-platform solution, which currently seems to be a non-starter with the project as people have concerns about the underlying hardware performance (this is particularly important when doing professional rather than hobbyist tasks).

Where is some valid Qt criticism? Tries too hard to look native? What else? Qt is a good choice. It is powerful, more powerful than Gtk, well documented, with a lot of learning resources, books, articles, video tutorials and a bigger community than Gtk. Qt also tries to maintain backwards compatibility. Gtk? not so much. It's like playing catch up.

Like most technical decisions (and life in general) we have to make trade-offs. No one technology will suit everyone, so we have to determine which tool can reasonably achieve our objectives and still bring enough people with us when we start using it.

Yes that's true. Trade offs are there, but you have to think what kind of trade-offs?
Sacrificing Mac? ok.
Better Open GL support? ok
Keeping the entry barrier high? ok.
Sacrificing KDE/Qt DEs?

The makes me think.. What do we gain by sticking to Gtk? What are the advantages?

Gtk-3 branch of gimp opened in 2013/14? Not sure. They still haven't been able to make it. 6 years, maybe even more. And those guys know the code base a lot better than anyone here. I wanna ask the community, What makes you guys think you can do it?

[jacob-carlborg]

The problem with criticizing both GTK and Qt means is that we are left with Electron as a cross-platform solution

If D is chosen, there's DWT [1]. But it's currently only for Windows and Linux.

[1] https://github.com/d-widget-toolkit/dwt

[jacob-carlborg]

Where is some valid Qt criticism? Tries too hard to look native?

It does not look native on macOS at least. Virtual Box used to look fine on macOS, but now with version 6, which is using Qt, it looks absolutely horrible.

[Waqar144]

Where is some valid Qt criticism? Tries too hard to look native?

It does not look native on macOS at least. Virtual Box used to look fine on macOS, but now with version 6, which is using Qt, it looks absolutely horrible.

So... is that better than not having a macOS version at all?

[jacob-carlborg]

So... is that better than not having a macOS version at all?

GTK supports macOS. Not that I think that GTK is better than Qt.

[TrechNex]

@waqar144 I'm going to avoid retreading the Qt vs GTK discussion here: https://github.com/glimpse-editor/Glimpse/issues/70#issuecomment-542398587

My opinion is that Qt is probably the better choice, but the community relies heavily on GNOME project contributors. If we want to continue to receive their buy-in then we have to use GNOME-friendly technology. If we lose their buy-in then the rewrite won't happen, because there won't be enough people committed to doing it to make that viable.

And to answer your "question to the community", I should point out that we do not presume to be better equipped to tackle a task than a more established and better resourced project. The difference is that we are focussed purely on the UI/UX and we are going into it understanding this is a "blue sky" project that may not come to fruition. We are designing with that in mind, and our programming language/UI choice is something we can take time to consider before we finally make a decision.

We also already know it is not impossible for us to fork BABL/GEGL, but it is not going to happen imho. Forking those projects would massively increase our overhead for little or no payoff. There are only so many wheels we are willing to consider reinventing.

[Waqar144]

I agree with most what you say, and yeah Qt would have been the better choice. And one big reason for choosing it could be the multi platform support.

Anyways, I fully support whatever decision gets taken and hopefully will be try to be a part of the effort in rewriting even with my little gtk knowledge.

[meltheadorable]

It's been a while since I've looked at this thread -- I think the multiple pages of discussion about D compiler internals should be added to the list of cons for D, and would generally agree that Qt is the better choice, but that essentially collapses our language choice down to C++ because bindings for other languages with Qt, due to Qt's extensive modifications to the language, tend to require relatively fragile hacks to generate bindings that can be used via the language's FFI or are in languages we've more or less ruled out for performance reasons, and if we choose the better tech and lose all the contributors, that's not exactly an ideal outcome.

At the end of the day, short of writing our own new cross-platform language toolkit, sticking with GTK and hoping the macOS issues are possible to resolve might be the only navigable outcome. In that scenario language choice matters less as long as it has complete GTK bindings. I doubt it's possible for us to take on the responsibility of both dramatically improving the GTK bindings for a language that doesn't have them or only has toy bindings and also engaging in a GTK porting effort for macOS, and dropping macOS would be a mistake I think.

[pipboy96]

@TrechNex I have a few questions:

• Are you only discussing rewriting the frontend, or will the backend be rewritten too?
• Is the project hard set to use GTK or are there other options?
• What's the size of a part that's going to be rewritten (roughly) and how complex is it?
• What are the primary motivations for rewrite? Which shortcomings of the original code should the rewrite address?

Also, can the relevant parts of conversation about the rewrite be made available to people who don't have an account on your Matrix server, if possible, to avoid duplicating effort?

[TrechNex]

@pipboy96 I will do my best to answer these questions, but @Member1221 is probably the best person as she is heading up that effort.

Are you only discussing rewriting the frontend, or will the backend be rewritten too?

The front-end. Things like BABL, GEGL, MyPaint and libgimp would still be used.

Is the project hard set to use GTK or are there other options?

Nothing is decided until it's decided. I believe the reason GTK is the way the project is leaning is because we have a number of GNOME contributors, and the people most likely to stick around and write the code want to use it.

What's the size of a part that's going to be rewritten (roughly) and how complex is it?

It would be the user-interface and the plug-in interpreter. The complexity of the task is high, which is why time is being given over to working through the design, analyzing the tools, etc. Our expectation is that with people just working on this in their free time it would take a year or two at least before it is ready to be a "swap in" replacement.

What are the primary motivations for rewrite? Which shortcomings of the original code should the rewrite address?

@Member1221 can better answer this question. Personally for me it's practical reasons. I was willing to sustain hundreds of unpaid hours per month to make a fork of 2.10.x happen, but I am not up for doing that again for 3.0.x. I think it makes sense for us to cultivate our own changes and differentiate what our project is offering than constantly struggling to keep up with what upstream is doing.

Also, can the relevant parts of conversation about the rewrite be made available to people who don't have an account on your Matrix server, if possible, to avoid duplicating effort?

Possibly. I think the most constructive thing that working group can do is make the decisions they have been making available on https://wiki.glimpse-editor.org. To an extent they have already started doing this, but I will encourage them to do that more. :)

[LunaTheFoxgirl]

The main reason to me; is the large codebase cruft in upstream's codebase. Which is understandable, it's an old and large piece of software, written with psuedo classes implemented in a language without classes.

The rewrite facilitates using a language that's more suited to the structure of GTK (OOP), while also avoiding the amount of code-generating scripts that upstream uses at current time. We also will have an easier time to document the codebase, apply new features (with larger scope), etc.

[LunaTheFoxgirl]

Closing this issue as it has grown kinda stale and we're at the point where we soon need to think about what to use.
I don't think there can be added much more useful info to this discussion.

@TrechNex feel free to reopen if you disagree.

[LunaTheFoxgirl]

Update, we've settled on DLang as the language for the rewrite and have begun working on our new UI toolkit using the language.

We'll share more information once we have something nice to show :)
I'll lock this thread.

[TrechNex]

Confirming that the D language choice is being spun out to Yuzu Studio, headed by @Member1221
It is likely that the new Glimpse NX will be based on gtk-rs (i.e. Rust)