Qt is massive, I doubt small communities would rush to integrate it and make it their job to maintain it all...

I doubt anyone in OSS communities is seriously deterred from using Qt because of the LGPL. It’s just a very big and very complex project that requires a lot of manpower to “tame”.

I guess it depends on how much of Qt you need. If you just need the basics you can import mainly what you need[0]. In the case of D though one of it's focuses is to work well with C++ directly. I'm not talking about maintaining it all, I'm talking about embedding it directly into the standard library of a programming language.

I guess you do make a fair point in regards to the LGPL though.

[0]: Here's an example of someone building only a minimal amount of Qt: https://github.com/dirtycold/qt-minimal-build

Already happened: https://www.copperspice.com

Thanks for the hint. Didn't know it. As it seems it is no longer Qt. They once started with Qt (don't know which version) but they have "completely diverged" as they say. The goal is not to have a free Qt but to have "Extensive use of modern C++ functionality" (with all these buzzwords). Not even shure if their containers are still implicitly shared. Will even though continue to have a look at it.

> don't know which version

apparently, they forked from Qt 4.8 and QML is disabled in Copperspice. Ref:

https://www.copperspice.com/docs/cs_overview/timeline.html#t...

https://news.ycombinator.com/item?id=9685022

https://forum.copperspice.com/viewtopic.php?f=11&t=1152

But that is not BSD

It's not as big as Linux, Chromium, Dart and others. All of my projects are still compatible with C++ Qt 4. I'm able to and I will maintain it as soon as someone is estabilshing a free fork; up to now I'm being held back by this outrageous Contributor Agreement. A lot of unnecessary complexity started with all the JavaScript stuff. This can be replaced by the other existing (and free) scripting language bindings. So yes, I don't see any problem to continue maintenance of the Qt framework without the Qt company at all.

I didn't think D had SQLite in stdlib. When I googled for it recently I just found some single contributor package and assumed it wasn't super well maintained.

That might be why honestly.

https://dlang.org/phobos/etc_c_sqlite3.html

For anybody's reference, it also has zlib, and an ODBC library.

Is there a page on how to use it? Thanks for the link!

Unfortunately I do not have any handy resources. I would look at some of the SQLite implementations you saw to confirm if they are just using the builtin SQLite. This seems to be mapping to SQLite code itsef instead of a more higher level driver.

Edit:

Did find this topic on the D forums:

https://forum.dlang.org/thread/[email protected]...

I found that too awhile back. Compare that with even other obscure languages like Nim and you'll see why it makes me hesitate. I really want to like D, but it is missing support for a few things I reach for often. Chicken and the egg problem.

Yeah I heard you, this is also why sometimes I just go and use Go. I think D is perfectly nice in regards to the language itself, but it could use some polish and a few minor additions.

I love that with Go I can do systems application development (think web, mail, etc). I wish D would just have a built-in web module / package. Vibe.d is nice and all, but built-in is better.