5 ms·

> But I'm always skeptical when underlying language choice is featured prominently as a selling point for any new project. > It tells me, this is a technology-

> But I'm always skeptical when underlying language choice is featured prominently as a selling point for any new project. > 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.

twblalock 5y ago
> 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'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.
- uoaei 5y ago
  This is true and also mostly unhelpful. It's possible to build a car without a muffler. Does that mean it happens often enough that we need to dedicate a whole pooh-pooh session to the possibility? Is a manufacturing process not more likely to be useful if it prevents this error from ever occurring?
- jolux 5y ago
  > It's possible to make buggy, slow, crappy software in any language. 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.
  - SkyMarshal 5y ago
    > they are the defaults in Rust. 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.
    - pjmlp 5y ago
      Like ActixWeb?
      - jolux 5y ago
        Do you think Actix Web would be safer if it were written in C++?
        pjmlp 5y ago
        Probably not, the point was that being in Rust wasn't either.
        mmstick76 5y ago
- posnet 5y ago
  There has to be a middle ground between "Nobody should derive any confidence from the language a product is written in" and "I only use products written in language X". 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.
- SkyMarshal 5y ago
  > It's possible to make buggy, slow, crappy software in any language. Technically it's possible, but you have to try a lot harder to do it in Rust than most other systems languages.
a9h74j 5y ago
Ironically, perhaps Rust in this sense should be compared to Basalt -- as in the projected longevity difference between Basalt-rebar and iron-rebar.
stonogo 5y ago
Ok, but GTK uses Javascript, which is where most of that toolkit's defects (both security flaws and slowdowns) come from, not C. Calling javascript from Rust isn't going to be a materially different experience than calling javascript from C.
- jmhain 5y ago
  GTK is written in C, not JS.
- southerntofu 5y ago
  GTK uses CSS but no JS. GNOME uses JavaScript intensively though, which is part of the reasons for the many slowness and bugs.
mohanmcgeek 5y ago
Because this is written in Rust and given how hard it is to hire Rust engineers, this will be abandonware in no time. Remember vala anyone? Although I want this to succeed if it is infact more performant and smoother than GNOME.
- SkyMarshal 5y ago
  > given how hard it is to hire Rust engineers, 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:AcldYnj7ElwJ:https://blogs.gnome.org/despinosa/2017/02/14/vala-is-not-a-programming-language/ https://webcache.googleusercontent.com/search?q=cache:AcldYn...
  - mohanmcgeek 5y ago
    For the reasons I mentioned above, adoption of vala by projects in 2010 is exactly like adoption of Rust. That Rust is much more capable doesn't matter.
    - SkyMarshal 5y ago
      You didn’t give any reasons about adoption of Vala. You said it’s hard to hire Rust programmers, and then just “Remember Vala anyone?” without actually saying anything more about Vala.
- gurkendoktor 5y ago
  Well, what about Vala? Obviously C, Python, and especially JavaScript are infinitely more popular programming languages. Yet the number of developers building GTK apps with any of them seems to be in the same ballpark.
xvilka 5y ago
I would add from experience, that using Rust would increase the speed of development like with any higher-level language than C and without the need to track memory problems. It shifts focus more on the actual development. Cargo helps to this cause as well, not always though.
blub 5y ago
Maybe you're right in some fundamental way, but as an example iOS, macOS, Android or Windows are all considered stable and efficient, secure and highly performant by most end-users. As a specialist one can quibble and point to counter-examples, but all of these are fine choices. The only big differences are in privacy and level of control offered. 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.
andrekandre 5y ago
> Some of the deepest issues that users need solved are ones that Rust was designed to solve at the language and compiler level. true, but if they are just calling into gtk in the end, will it actually be any faster/more-stable?

twblalock 5y ago

> 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'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.

uoaei 5y ago
This is true and also mostly unhelpful. It's possible to build a car without a muffler. Does that mean it happens often enough that we need to dedicate a whole pooh-pooh session to the possibility? Is a manufacturing process not more likely to be useful if it prevents this error from ever occurring?
jolux 5y ago
> It's possible to make buggy, slow, crappy software in any language. 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.
- SkyMarshal 5y ago
  > they are the defaults in Rust. 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.
  - pjmlp 5y ago
    Like ActixWeb?
    - jolux 5y ago
      Do you think Actix Web would be safer if it were written in C++?
      - pjmlp 5y ago
        Probably not, the point was that being in Rust wasn't either.
        mmstick76 5y ago
posnet 5y ago
There has to be a middle ground between "Nobody should derive any confidence from the language a product is written in" and "I only use products written in language X". 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.
SkyMarshal 5y ago
> It's possible to make buggy, slow, crappy software in any language. Technically it's possible, but you have to try a lot harder to do it in Rust than most other systems languages.

a9h74j 5y ago

Ironically, perhaps Rust in this sense should be compared to Basalt -- as in the projected longevity difference between Basalt-rebar and iron-rebar.

stonogo 5y ago

Ok, but GTK uses Javascript, which is where most of that toolkit's defects (both security flaws and slowdowns) come from, not C. Calling javascript from Rust isn't going to be a materially different experience than calling javascript from C.

jmhain 5y ago
GTK is written in C, not JS.
southerntofu 5y ago
GTK uses CSS but no JS. GNOME uses JavaScript intensively though, which is part of the reasons for the many slowness and bugs.

mohanmcgeek 5y ago

Because this is written in Rust and given how hard it is to hire Rust engineers, this will be abandonware in no time. Remember vala anyone? Although I want this to succeed if it is infact more performant and smoother than GNOME.

SkyMarshal 5y ago
> given how hard it is to hire Rust engineers, 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:AcldYnj7ElwJ:https://blogs.gnome.org/despinosa/2017/02/14/vala-is-not-a-programming-language/ https://webcache.googleusercontent.com/search?q=cache:AcldYn...
- mohanmcgeek 5y ago
  For the reasons I mentioned above, adoption of vala by projects in 2010 is exactly like adoption of Rust. That Rust is much more capable doesn't matter.
  - SkyMarshal 5y ago
    You didn’t give any reasons about adoption of Vala. You said it’s hard to hire Rust programmers, and then just “Remember Vala anyone?” without actually saying anything more about Vala.
gurkendoktor 5y ago
Well, what about Vala? Obviously C, Python, and especially JavaScript are infinitely more popular programming languages. Yet the number of developers building GTK apps with any of them seems to be in the same ballpark.

xvilka 5y ago

I would add from experience, that using Rust would increase the speed of development like with any higher-level language than C and without the need to track memory problems. It shifts focus more on the actual development. Cargo helps to this cause as well, not always though.

blub 5y ago

Maybe you're right in some fundamental way, but as an example iOS, macOS, Android or Windows are all considered stable and efficient, secure and highly performant by most end-users. As a specialist one can quibble and point to counter-examples, but all of these are fine choices. The only big differences are in privacy and level of control offered. 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.

andrekandre 5y ago

> Some of the deepest issues that users need solved are ones that Rust was designed to solve at the language and compiler level. true, but if they are just calling into gtk in the end, will it actually be any faster/more-stable?