Bernie
macOS is more popular among Go developers than Windows, but somehow Windows is a more common target platform.
Unsurprisingly, Linux has become the dominant platform for Go deployment (for *any* deployment?)
From the latest Go Developer Survey:
https://go.dev/blog/survey2022-q2-results
Bernie
@penguin42 yes and yes.
penguin42
@codewiz I hadn't expected that much IoT for Go; interesting.
(It's weird to have a 'select as many as required' for a 'primarily use')
Bernie
@globalc Fast, but error-prone C++... Could be a little less error prone if we moved to C++20 more aggressively. Rust is still used sparingly, mostly due to infra issues that make it hard to build Rust code.
Christian Horn
@codewiz What are you actually most in contact with, working around sensor data on space related requipment? Fast but error prone C, or something higher which is protecting more from overflows but has a tendency to be slower?
Looking at our RHEL distro, I basically still see the 2 movements: C/asm for the kernel, and Python and other higher things for areas where ease of maintennance and being protected from pitfalls like overflows is more important.
Bernie
@globalc The main Linux desktops being written mostly in C is perhaps the biggest architectural mistakes we made. Microsoft moved aggressively to C++ since the 80's (ok, perhaps a bit too early), and macOS was Objective C long ago, now Objective C++ and Swift.
Bernie
@globalc C is too low-level for large GUI apps, which is why Firefox, Chrome and OpenOffice are all written in C++.
Gnome's reluctance to fully embrace C++ resulted in a messy stack of glib / gtk / gobject. There are wrappers (gtkmm, PyGTK, Vala and even JavaScript), but there's a scaey amount of plain C at the foundation level.
Bernie
@globalc Perhaps the Gnome devs will jump directly from C to Rust... Hopefully abandoning Vala and JavaScript, which I see as half-baked attempts to complement C with something more agile, but even less type-safe.
Bernie
@globalc To be fair, KDE has its own array of problems, with Qt being an ancient C++ codebase filled with anti-patterns: deep hierarchies, virtual hooks, custom containers, string-based signals, awkward ownership model...
Modern #KDE moved to QML heavily for applets and settings panels, which is essentially JavaScript, CSS and a text-based templating language which isn't HTML for some reason.
I'm sure QML is nicer than old-school Qt C++, but less robust than modern C++ and Rust.
penguin42
@codewiz @globalc Yeh, it's not pleasent; they end up with building their own idea of Objects; and a lot of other open source projects then have to build their own object systems as well (I work on QEMU and it has a lot of it). gtk-rs4 isn't too bad - but it's still very much of a feal of a wrapper; it's not clear how to fit GUI lifetimes in with Rust's idea.
Bernie
@penguin42 @globalc I read that all GUI bindings for Rust suffer from object lifetime mismatch.
Qt seems particularly difficult to adapt because of its QObject ownership model. Essentially, it's a tree in which parents free their children, but it doesn't always correspond to the hierarchy for layout, and things get tricky when you create and detach objects more dynamically.
Last time I looked, there weren't any production-quality crates for Qt...
Bernie
@collappsar macOS Server has been around for over 20 years, but it failed to gain any significant market share from Linux and Windows. Earlier this year, Apple finally admitted that they're discontinuing it:
https://en.wikipedia.org/wiki/MacOS_Server
#macOS #apple
collappsar
Tenno Seremel, La ĉiela ombro
@codewiz String-based signals are not required now, from what I remember, no? :blobcatthinking:
Bernie
@tennoseremel Ah! Did they switch to std::function?
Bernie
@tennoseremel I also saw that now they're discouraging the Java-style iterators in favor of regular STL iterators. If only they replaced QString in favor of std::string or std::u8string...
Tenno Seremel, La ĉiela ombro
@codewiz https://doc.qt.io/qt-6/signalsandslots.html#a-small-example
> QObject::connect(&a, &Counter::valueChanged, &b, &Counter::setValue);
Tenno Seremel, La ĉiela ombro
@codewiz From what I remember std::string's Unicode support is rather bare-bones. Too early for that yet (probably).
Bernie
@tennoseremel It's (implicitly) utf-8, the only encoding that mat you need today unless you're making an email client. Go and Rist also have utf-8 strings, although with some level of validation.
Bernie
@tennoseremel Ah, but I guess the QML stuff uses the string-based bindings because sometimes I see errors of non-existent signals in plasma logs, which can only happen dynamic binding.
Tenno Seremel, La ĉiela ombro
@codewiz Try doing string manipulation and you'll see that API coverage is abysmal.
Tenno Seremel, La ĉiela ombro
@codewiz Maybe it's Qt5?
Bobinas P4G is a social network. It runs on GNU social, version 2.0.1-beta0, available under the GNU Affero General Public License.
All Bobinas P4G content and data are available under the Creative Commons Attribution 3.0 license.