It's already very usable in its current state, and most of the tooling is complete for libcosmic. Application development will be even faster than what was needed for libcosmic.
The cosmic-greeter package is already installable today. It will work on any system that has greetd available. The Appearance panel in COSMIC Settings is not yet merged, but it is in the appearance staging branch.
The desktop environment doesn't control how applications look or function. Regarding theming, GTK3 applications need a GTK3 theme, GTK4 applications need a GTK4 theme, libadwaita applications need a libadwaita theme, and KDE applications need a KDE theme. Our tooling for generating themes will attempt to generate themes for other toolkits, but COSMIC applications have a different design language than GNOME or KDE applications.
Synthetic benchmarks written in Rust are as fast as those in C. In practice, Rust applications are more efficient than their C counterparts. The performance and efficiency is nice, but the main benefit will be stable software that is free of vulnerabilities caused by common mistakes in C and C++. Virtually every Curl vulnerability would not happen in Rust.
There's half of a century of programming language theory research between C++ and Rust. Which solves many of the issues in programming that are common in C and C++. Such as the memory and thread safety violations that can be difficult to diagnose, application crashes, and critical software vulnerabilities.
The language concepts and compiler features also prevent a lot of common logical mistakes a programmer may make. Such that the best practices in C++ are the baseline for any Rust project that successfully compiles. It is easy to develop highly parallel and asynchronous software that just works and is easy to maintain and debug. As a result, you may notice Rust projects developing to maturity much quicker than you'd expect.
We have been developing our own toolkit, libcosmic, which is being used for everything. From the lock screen, compositor, applets for the desktop, and the applications themselves. There is an examples directory for third party developers to learn hope to build their own applets and applications with.
The compiler enforces "aliasing XOR mutability"; utilizes "move semantics"; has a "borrowing and ownership" model; and requires the programmer to tag their references with "lifetimes". Array accesses are checked at runtime if they cannot be guaranteed safe at compile-time. Variables passed by value (moved) cannot be reused. Variables cannot be moved or mutated if any borrow to them exists. You may either have only one mutable borrow, or many immutable borrows, but never both. Therefore you cannot mutate an array while iterating on it, and you cannot have two separate unchecked references to the same array. Every function or type that accepts a borrow must be able to annotate the lifetimes of references to ensure that references are always dropped in the correct order to prevent dangling references. Rust requires developing software with discipline using patterns that satisfy all of these constraints.
It's up to the the CIO / IT department to decide what they want to maintain. Businesses can ask sales questions at https://system76.com/contact. We sell systems to a number of organizations that use Linux, and Pop!_OS is optimized for the use cases of our customers. Ubuntu's the second most popular option behind Pop!_OS.
It will launch when it's ready, using 24.04 as the base.