4 ms·

There seems to be some rather irrational obsession about this.

by uecker 1y ago

antonvs 1y ago
Things can seem irrational when you don't understand them. Another comment in this thread hoped for "a brand new bulletproof tmux-resurrect". The reason there's a desire for such things is closely related to the limitations of non-trivial programs written in C. They're harder to extend without bugs, harder for new team members to understand, and so on. The "irrational obsession" has to do with advancing the state of the art beyond a primitive high-level assembler that was developed in the 1970s.
- uecker 1y ago
  I understand them very well, I just do not think it trumps all other considerations. Also I do not believe that Rust is easier than C. It is also less fun, less portable, and has another annoying ecosytem costs.
  - antonvs 1y ago
    There's a lot of subjectivity here. The last serious C code I wrote was in the early 1990s, and I don't miss it at all, because I don't like spending time on low-level details unrelated to the problem domain I'm working on. I find Rust fun and easy for writing system-level code, and I have enormous appreciation for the degree of correctness-by-construction that it can provide. Generally, if it builds, it works, as long as you're making proper use of the type system - make illegal states unrepresentable, as the saying goes. That's very difficult to do with C. Rust isn't perfect. For most things, I'd rather be using Haskell, ML, or something on that level. But it's still on a completely different level from C, and rewriting the software ecosystem in it can only be an improvement.
    - davemp 1y ago
      C23 is very different than C89. C89 variable declarations are decidedly not fun. Embed, designated initialization, and constexpr are really nice adds.
  - nicce 1y ago
    > It is also less fun Statistically it is the most fun language there is, based on Stackoverflow. Portability is just a matter of time like with any language.
    - uecker 1y ago
      Lol, if you believe such surveys.
    - krater23 1y ago
      It's fun when you don't use it for work. And the most people don't use it for work but just rewrite any tool they can find.
    - IcePic 1y ago
      No, that is likely not true. There are platforms today for which C-based tmux runs but Rust never will. It's not that we are simply waiting for the backport of Rust to magically appear for them, it's quite a certainty that it will basically never appear.
      - nicce 1y ago
        > It's not that we are simply waiting for the backport of Rust to magically appear for them, it's quite a certainty that it will basically never appear. Abstraction happens on the level where tmux requirement is irrelevant. When the usage of Rust gets wider, people start adding support on compiler level for other needs. It is inevitable.
  - sunshowers 1y ago
    Rust is far more portable in practice than C. Your average C program is written either for Unix or for Windows, while Rust has sufficient abstraction power to be able to write most business logic once. I maintain cargo-nextest, a widely-used test runner for Rust. It is possible to write nextest's runner loop in C, but it would be extraordinarily difficult — each test's state machine has dozens of states, there are several dynamic event sources as inputs, and the event loop relies heavily on epoll/kqueue/the equivalent Windows thing, as abstracted out by Tokio. So most test runners written in C don't even try to approach the quality, reliability, or portability of nextest. https://nexte.st/docs/design/architecture/runner-loop/ https://nexte.st/docs/design/architecture/runner-loop/
    - uecker 1y ago
      I think you have no idea how big the C ecosystem is. I am not sure what cargo-nextest is, but I have seen people solve the most challenging programs in C.
      - sunshowers 1y ago
        As I mentioned, cargo-nextest is a widely used test runner for Rust -- you're welcome to check out its website for its feature set. It is possible to do this in C, because it compiles to machine code in the end. But would be out of reach for all but the most talented of C teams working over many years, and the portability costs would be massive. As a result, I don't know of a test runner that comes anywhere close to the feature set and portability of nextest that's written in C. > I think you have no idea how big the C ecosystem is. I'm definitely aware that the C ecosystem is much larger than the Rust ecosystem.
        uecker 1y ago
        I also doesn't seem like anything most people would spend a lot of time on. I run my tests using "make" which somewhat poor but does the job. So from a programming side, what exactly do you think would be difficult to implement in C?
- chillingeffect 1y ago
  > developed in the 1970s. It was born in the 1970s and was standardized in the 80s and 90s. It continues to develop. Numerous data types have been added, along with unicode and threads. The C23 standard was released last year.
  - antonvs 1y ago
    You can say something similar about COBOL and FORTRAN. C's fundamental flaws aren't being fixed, because that would require a new language. There comes a point at which it becomes necessary to move on.
    - Spivak 1y ago
      What in your mind are the fundamental issues of C? Because memory safety clearly isn't one of them as brand new systems languages are being written without it (Zig).
      - steveklabnik 1y ago
        Absolutely zero shade to Zig, because it is still pre-1.0, but if you look at which new systems languages have gained wide adoption recently, instead of languages that are just created, you end up with Rust. And the stated reason industry is adopting it is memory safety.
        rc00 1y ago
        What adoption? Blog posts? Echo chambers? Rust peaked. The hype pushers don't want to believe it but that is the reality. Absolutely zero shade to Rust.
        deleted 1y ago
        [deleted]
      - deleted 1y ago
        [deleted]
- yjftsjthsd-h 1y ago
  > Another comment in this thread hoped for "a brand new bulletproof tmux-resurrect". The reason there's a desire for such things is closely related to the limitations of non-trivial programs written in C. I don't follow; tmux-resurrect isn't written in C and is mostly useful to keep sessions across reboots.
- spauldo 1y ago
  Wow, that's the most condescending opening to a comment I've seen in a while.
wat10000 1y ago
It comes from the fact that nearly every useful program written in C has multiple security vulnerabilities just waiting to be found. In the unlikely event that you have a codebase that's free of them, you risk introducing one with any significant change.
- JdeBP 1y ago
  Instead of just dogmatically asserting that any C program has security vulnerabilities, and changing C programs is also a security problem, you should look at what tmux's record actually is. tmux has existed for approaching 18 years, and M. Marriott is still actively improving it as of last week. One can actually look at its record over that time, and, if that record is poor, replace proof by unsupported generalized assertion with proof based upon actual evidence. * https://cvedetails.com/product/20683/Nicholas-Marriott-Tmux.html?vendor_id=11380 https://cvedetails.com/product/20683/Nicholas-Marriott-Tmux....
  - wat10000 1y ago
    That search misses this: https://www.cvedetails.com/cve/CVE-2020-27347/ https://www.cvedetails.com/cve/CVE-2020-27347/ That is still quite a good record, but my statement stands. It is supported by decades of my experience working in C-derived languages. You don't have to accept my experience or believe my statement, of course, it's all the same to me.
    - hnlmorg 1y ago
      That's a little like closing the barn door after the horse has already bolted because if you're concerned about security, then running any untrusted software in your terminal multiplexer is already a bad idea, regardless of whether your multiplexer is written in a memory-safe language or not. ...and before someone moans that I'm a C-fanboy, I'm really not. I've been writing software exclusively in memory-safe languages for 10+ years now. But I'm also pragmatic about when arguments about a RiR (rewrite-in-rust) are sensible and when they're not. In tmux's specific case, arguing about security misses the point.

There seems to be some rather irrational obsession about this.

by uecker 1y ago

There seems to be some rather irrational obsession about this.

Things can seem irrational when you don't understand them. Another comment in this thread hoped for "a brand new bulletproof tmux-resurrect". The reason there's a desire for such things is closely related to the limitations of non-trivial programs written in C. They're harder to extend without bugs, harder for new team members to understand, and so on. The "irrational obsession" has to do with advancing the state of the art beyond a primitive high-level assembler that was developed in the 1970s.

uecker 1y ago
I understand them very well, I just do not think it trumps all other considerations. Also I do not believe that Rust is easier than C. It is also less fun, less portable, and has another annoying ecosytem costs.
- antonvs 1y ago
  There's a lot of subjectivity here. The last serious C code I wrote was in the early 1990s, and I don't miss it at all, because I don't like spending time on low-level details unrelated to the problem domain I'm working on. I find Rust fun and easy for writing system-level code, and I have enormous appreciation for the degree of correctness-by-construction that it can provide. Generally, if it builds, it works, as long as you're making proper use of the type system - make illegal states unrepresentable, as the saying goes. That's very difficult to do with C. Rust isn't perfect. For most things, I'd rather be using Haskell, ML, or something on that level. But it's still on a completely different level from C, and rewriting the software ecosystem in it can only be an improvement.
  - davemp 1y ago
    C23 is very different than C89. C89 variable declarations are decidedly not fun. Embed, designated initialization, and constexpr are really nice adds.
- nicce 1y ago
  > It is also less fun Statistically it is the most fun language there is, based on Stackoverflow. Portability is just a matter of time like with any language.
  - uecker 1y ago
    Lol, if you believe such surveys.
  - krater23 1y ago
    It's fun when you don't use it for work. And the most people don't use it for work but just rewrite any tool they can find.
  - IcePic 1y ago
    No, that is likely not true. There are platforms today for which C-based tmux runs but Rust never will. It's not that we are simply waiting for the backport of Rust to magically appear for them, it's quite a certainty that it will basically never appear.
    - nicce 1y ago
      > It's not that we are simply waiting for the backport of Rust to magically appear for them, it's quite a certainty that it will basically never appear. Abstraction happens on the level where tmux requirement is irrelevant. When the usage of Rust gets wider, people start adding support on compiler level for other needs. It is inevitable.
- sunshowers 1y ago
  Rust is far more portable in practice than C. Your average C program is written either for Unix or for Windows, while Rust has sufficient abstraction power to be able to write most business logic once. I maintain cargo-nextest, a widely-used test runner for Rust. It is possible to write nextest's runner loop in C, but it would be extraordinarily difficult — each test's state machine has dozens of states, there are several dynamic event sources as inputs, and the event loop relies heavily on epoll/kqueue/the equivalent Windows thing, as abstracted out by Tokio. So most test runners written in C don't even try to approach the quality, reliability, or portability of nextest. https://nexte.st/docs/design/architecture/runner-loop/ https://nexte.st/docs/design/architecture/runner-loop/
  - uecker 1y ago
    I think you have no idea how big the C ecosystem is. I am not sure what cargo-nextest is, but I have seen people solve the most challenging programs in C.
    - sunshowers 1y ago
      As I mentioned, cargo-nextest is a widely used test runner for Rust -- you're welcome to check out its website for its feature set. It is possible to do this in C, because it compiles to machine code in the end. But would be out of reach for all but the most talented of C teams working over many years, and the portability costs would be massive. As a result, I don't know of a test runner that comes anywhere close to the feature set and portability of nextest that's written in C. > I think you have no idea how big the C ecosystem is. I'm definitely aware that the C ecosystem is much larger than the Rust ecosystem.
      - uecker 1y ago
        I also doesn't seem like anything most people would spend a lot of time on. I run my tests using "make" which somewhat poor but does the job. So from a programming side, what exactly do you think would be difficult to implement in C?
chillingeffect 1y ago
> developed in the 1970s. It was born in the 1970s and was standardized in the 80s and 90s. It continues to develop. Numerous data types have been added, along with unicode and threads. The C23 standard was released last year.
- antonvs 1y ago
  You can say something similar about COBOL and FORTRAN. C's fundamental flaws aren't being fixed, because that would require a new language. There comes a point at which it becomes necessary to move on.
  - Spivak 1y ago
    What in your mind are the fundamental issues of C? Because memory safety clearly isn't one of them as brand new systems languages are being written without it (Zig).
    - steveklabnik 1y ago
      Absolutely zero shade to Zig, because it is still pre-1.0, but if you look at which new systems languages have gained wide adoption recently, instead of languages that are just created, you end up with Rust. And the stated reason industry is adopting it is memory safety.
      - rc00 1y ago
        What adoption? Blog posts? Echo chambers? Rust peaked. The hype pushers don't want to believe it but that is the reality. Absolutely zero shade to Rust.
        deleted 1y ago
        [deleted]
    - deleted 1y ago
      [deleted]
yjftsjthsd-h 1y ago
> Another comment in this thread hoped for "a brand new bulletproof tmux-resurrect". The reason there's a desire for such things is closely related to the limitations of non-trivial programs written in C. I don't follow; tmux-resurrect isn't written in C and is mostly useful to keep sessions across reboots.
spauldo 1y ago
Wow, that's the most condescending opening to a comment I've seen in a while.

wat10000 1y ago

It comes from the fact that nearly every useful program written in C has multiple security vulnerabilities just waiting to be found. In the unlikely event that you have a codebase that's free of them, you risk introducing one with any significant change.

JdeBP 1y ago
Instead of just dogmatically asserting that any C program has security vulnerabilities, and changing C programs is also a security problem, you should look at what tmux's record actually is. tmux has existed for approaching 18 years, and M. Marriott is still actively improving it as of last week. One can actually look at its record over that time, and, if that record is poor, replace proof by unsupported generalized assertion with proof based upon actual evidence. * https://cvedetails.com/product/20683/Nicholas-Marriott-Tmux.html?vendor_id=11380 https://cvedetails.com/product/20683/Nicholas-Marriott-Tmux....
- wat10000 1y ago
  That search misses this: https://www.cvedetails.com/cve/CVE-2020-27347/ https://www.cvedetails.com/cve/CVE-2020-27347/ That is still quite a good record, but my statement stands. It is supported by decades of my experience working in C-derived languages. You don't have to accept my experience or believe my statement, of course, it's all the same to me.
  - hnlmorg 1y ago
    That's a little like closing the barn door after the horse has already bolted because if you're concerned about security, then running any untrusted software in your terminal multiplexer is already a bad idea, regardless of whether your multiplexer is written in a memory-safe language or not. ...and before someone moans that I'm a C-fanboy, I'm really not. I've been writing software exclusively in memory-safe languages for 10+ years now. But I'm also pragmatic about when arguments about a RiR (rewrite-in-rust) are sensible and when they're not. In tmux's specific case, arguing about security misses the point.