> It tells me, this is a technology-first, users-second enthusiast project.

> And thus, I'll be surprised if it tackles the deepest issues users need solved.

Some of the deepest issues that users need solved are ones that Rust was designed to solve at the language and compiler level.

1. System stability and memory efficiency, zero or fewer crashes due to memory-safety or thread-safety problems.

2. Security and assurance via the elimination of entire classes of attack vectors like buffer overflows.

3. Highly performant, responsive applications that are a joy to use.

Solving problems at the compiler level eliminates the reliance on fallible programmers to do so. People also tend to discount maintaining those solutions over years of dev team turnover, startup failures, etc. Building those solutions, capabilities, and constraints into the language itself makes maintenance over the entire product lifecycle more consistent.

It's like buying a Toyota, you know from the brand alone that you're getting a certain baseline level of reliability, maintainability, durability, and longevity. Rust is like the Toyota of programming languages - it can produce many different types of cars/programs, but they're all guaranteed to come with a baseline level of assurance, and to eliminate common classes of problems that degrade the end-user experience.

It may not make sense for other languages to be prominently featured as a selling point, but Rust is an exception.

It's possible to make buggy, slow, crappy software in any language. Rust is no exception. Nobody should derive any confidence from the language a product is written in.

True.

> Rust is no exception.

Also true.

> Nobody should derive any confidence from the language a product is written in.

This, on the other hand, is a non-sequitur, or at least it's too strong, because Rust can do things that C can't do: safe deterministic memory management and safe concurrency without data races. These things are not just available, they are the defaults in Rust. You have to go out of your way to get these things wrong. So, I wouldn't derive absolute confidence from an application being written in Rust. But I'd be willing to bet a whole lot that it has fewer memory bugs than an equivalent application written in C.

Exactly, this is what I should have explicitly said. Language defaults have a powerful effect on a project's norms and culture.

> You have to go out of your way to get these things wrong.

Yes, you actually have to try to write shitty Rust code, at least where there are defaults that prevent it. Thus the average Rust program will have that baseline level of quality. Like TQM/TPM/Six-Sigma for manufacturing software.

It is no accident that Ada and Java also have security guidelines similar to MISRA, because even with memory corruption bugs out of the picture, as log4j newly remided us, security only happens when it is part of the daily process, regardless of the language.

As for the memory fuckups you are right, pity that they are using a C GUI library.

Even if the binding has been deemed safe upon validation, if only remains a valid certification until the next Gtk version update, even minor ones might break the assumptions validated on the unsafe code block.

You are correct. No programming language will protect you from writing flawed application logic.

> pity that they are using a C GUI library. (...) Gtk version update, even minor ones might break the assumptions

I don't know about that. GTK is more "battletested" than most frameworks, and has a lot of contributors to fix bugs. Also, and that's a very important point, GTK cares for accessibility! Using any other framework would have meant excluding a lot of people from the GUI.

As for assumptions, i certainly hope GTK devs don't push breaking changes to the ABI on minor updates. But i guess that's yet another assumption that can be broken.

Also that is besides the point, unsafe only deals with a very specific cause of errors that plague C code bases (and those of languages copy-paste compatible with it).

Rust's unsafe wouldn't have done anything to protect against an hypotetical log4r.

a conclusion or statement that does not logically follow from the previous argument or statement. "his weird mixed metaphors and non sequiturs"

You shouldn't dervive all confidence in a product from it's implementation language, but when you are looking at all available products and need to filter down to ones you might be interested in. Implementation language can be a useful litmus test for understanding how it might behave without doing a complete in depth evaluation.

For example if I learn that a desktop application is written in javascript, it is likely to be using electron or an OS webview. Or if an application is written in C++ it is unlikely to have GC pauses cause stuttery UI. Both of those assumptions may not be true (Sciter for JS and Boehm GC for C++ respectively). However those assumptions are a useful starting point unless proven otherwise.

Technically it's possible, but you have to try a lot harder to do it in Rust than most other systems languages.

Remember vala anyone?

Although I want this to succeed if it is infact more performant and smoother than GNOME.

That's not given.

> Remember vala anyone?

Vala is nothing like Rust, doesn't solve the same problems, and is much more narrow in scope (Gnome development).

https://webcache.googleusercontent.com/search?q=cache:AcldYn...

That Rust is much more capable doesn't matter.

It's more likely that by the time Rust makes an impact in Linux stability and performance - because you're using an OS, not just desktop environment - nobody will even remember what System76 was.

  > Some of the deepest issues that users need solved are ones that Rust was designed to solve at the language and compiler level.

A Ctrl-F rust showed no results.

This post's author just likes Rust.

As a System76 fan, I too am curious to see what the point is. I have no idea what Rust is nor do I care.

Now, 90-95% of users use GNOME or KDE, having some competition from a `new` GTK4 DE can't be bad, so I would like to see Cosmos gain attention, and maybe be ported to other distros.

Jokes aside: during early development it makes perfect sense to advertise tech being used, because the audience is so different at that time. So even if system76 would "shill" it as a Rust DE, at this phase, that would be fine, because of the highly technical audience.

Oops! That should read

> the existing engineering talent there

apologies. Missed the edit window on the comment, and only saw the error now.

I'm not at System76 and never have been

However, for System 76 Rust is a very good choice.

But calling it "Rust based" when it's GTK is clearly a bit bold ...

What?! The year of the Linux desktop hasn't been eluding us because of buffer overflows and memory safety. The Rust hype train is incredible. The Linux desktop problems have nothing to do with the goal Rust sets out to solve.

It's definitely a good choice of language for the problem, don't get me wrong, but choosing that language doesn't improve the chances of COSMIC revolutionising the Linux desktop situation one iota.

That said, this is not the sole benefit of Rust. It is more of a side effect of aliasing XOR mutability than the primary benefit of Rust as a whole. Let's take a look at the C and Vala landscape as a comparison. Neither support message passing with channels, and async support is virtually an unmaintainable hack. Vala has generics thankfully, but C doesn't have generics and it's really bad. It also doesn't help that your only options for building software is pretty much almost entirely GLib and whatever sparse set libraries might be available for the package manager. Whereas with Rust there's a vast immutable repository of libraries you can leverage, and publishing open source libraries on the platform is easy.

I also know that Linux desktops are often victims of memory bugs, and that a higher-level language for extensions is something people appreciate, that's why there's JS in GNOME.

> It tells me, this is a technology-first, users-second enthusiast project.

I disagree. There are thousands of pieces of software out there using convenient technologies at the expense of performance. I think a real, legitimate advantage of unreal over unity is that it uses c++ instead of c# for gameplay code. I’ve never been cpu bound in unreal. Js algorithms often run 100x slower than Java ones, and if gnome were written in rust we wouldn’t have had quite so many memory leaks.

Also, pg credits much of his startups success to his language choice, letting him iterate faster

Language can make a pivotal difference!