6 ms·

I like this post, one can learn a lot. It seems automatically translating Rust to C is not a very good idea: "I threw away all of the C2Rust output and decided

by uecker 1y ago

I like this post, one can learn a lot. It seems automatically translating Rust to C is not a very good idea: "I threw away all of the C2Rust output and decided I would translate all of the files into Rust manually from C.". Neither seems doing it manually: "I introduced many bugs while translating the code. I’d like to share the process of discovering and fixing a couple." Or using AI: "That’s because when using cursor to translate the code it would still occasionally insert bugs, just like me. So, I spent as much time reviewing the generated code as it would have taken me to write it myself." As a hobby project, all power to you. But otherwise, maybe better not rewrite working code....

perching_aix 1y ago
This reminded me of no-code: https://github.com/kelseyhightower/nocode https://github.com/kelseyhightower/nocode
antonvs 1y ago
> But otherwise, maybe better not rewrite working code.... Except that the eventual result allows for extension and improvements in a memory-safe language.
- uecker 1y ago
  There seems to be some rather irrational obsession about this.
  - 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.
  - 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.
- hnlmorg 1y ago
  tmux doesn’t really gain anything from memory safety because: 1. anything running in tmux already has execution rights and typically for the same user as tmux anyway. 2. Anyone who wanted to exploit tmux could just run ‘tmux -C’ and automatically get access to literally every interaction within tmux. 3. The software itself is already damn stable. I've never had it crash. If you’re worried about someone exploiting your terminal then tmux is a terrible option, irrespective of whether it’s with written in C or Rust. And I say this as someone who absolutely loves tmux and uses it every day. [edit] And if you're worried about non-security related bugs affecting UX, then a rewrite in any language, regardless of the language, is a worse solution if your application has already been battle-tested for close to two decades. You're much better off creating something entirely new instead of porting code from one language to another because at least then you have new ideas instead of the same application but with new bugs in different places. I don't say this because of some bias that Rust fanboys will assume I have. I love memory safe languages and think Rust is a great option for new projects. The point I'm making here is that a rewrite doesn't gain much for tmux SPECIFICALLY because tmux is already extremely stable.
  - legobmw99 1y ago
    There are reasons to be worried about additional safety beyond just security. My first thought when reading the article was it would be a huge bummer if a bug in tmux brought down a long-running or particularly stateful session. Of course, I’ve never encountered such a thing in my own usage, but if you could make it less likely that alone seems like a value add
    - hnlmorg 1y ago
      If tmux was a new project then I'd agree with you. But, like yourself, I've using tmux for probably close to 15 years now and never had it crash once. In fact the author of this project has admitted that they've introduced bugs with their rewrite. I know it's a hobby project so I'm not being critical of their work. But if we're only interested in reducing bugs then rewriting an existing project isn't the right way to go. Something like Zellij makes more sense because it's offering something new in addition to being written in Rust.
greenavocado 1y ago
This is funny, but unfortunately .NET went all in on the AI coding assistant kool-aid. https://github.com/dotnet/runtime/pull/115762 https://github.com/dotnet/runtime/pull/115762 https://github.com/dotnet/runtime/pull/115743 https://github.com/dotnet/runtime/pull/115743 https://github.com/dotnet/runtime/pull/115733 https://github.com/dotnet/runtime/pull/115733 https://github.com/dotnet/runtime/pull/115732 https://github.com/dotnet/runtime/pull/115732
- tacker2000 1y ago
  Wow, so this MS dev is trying out Copilot on the dotnet repo and doesnt even configure it correctly beforehand? Or was that comment just a cop-out because Copilot’s results were complete nonsense?
  - greenavocado 1y ago
    "Configuration" problems are a complete fabrication. Copilot is just that bad.
deleted 1y ago
[deleted]

by uecker 1y ago

perching_aix 1y ago

This reminded me of no-code: https://github.com/kelseyhightower/nocode https://github.com/kelseyhightower/nocode

antonvs 1y ago

> But otherwise, maybe better not rewrite working code.... Except that the eventual result allows for extension and improvements in a memory-safe language.

uecker 1y ago
There seems to be some rather irrational obsession about this.
- 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.
- 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.
hnlmorg 1y ago
tmux doesn’t really gain anything from memory safety because: 1. anything running in tmux already has execution rights and typically for the same user as tmux anyway. 2. Anyone who wanted to exploit tmux could just run ‘tmux -C’ and automatically get access to literally every interaction within tmux. 3. The software itself is already damn stable. I've never had it crash. If you’re worried about someone exploiting your terminal then tmux is a terrible option, irrespective of whether it’s with written in C or Rust. And I say this as someone who absolutely loves tmux and uses it every day. [edit] And if you're worried about non-security related bugs affecting UX, then a rewrite in any language, regardless of the language, is a worse solution if your application has already been battle-tested for close to two decades. You're much better off creating something entirely new instead of porting code from one language to another because at least then you have new ideas instead of the same application but with new bugs in different places. I don't say this because of some bias that Rust fanboys will assume I have. I love memory safe languages and think Rust is a great option for new projects. The point I'm making here is that a rewrite doesn't gain much for tmux SPECIFICALLY because tmux is already extremely stable.
- legobmw99 1y ago
  There are reasons to be worried about additional safety beyond just security. My first thought when reading the article was it would be a huge bummer if a bug in tmux brought down a long-running or particularly stateful session. Of course, I’ve never encountered such a thing in my own usage, but if you could make it less likely that alone seems like a value add
  - hnlmorg 1y ago
    If tmux was a new project then I'd agree with you. But, like yourself, I've using tmux for probably close to 15 years now and never had it crash once. In fact the author of this project has admitted that they've introduced bugs with their rewrite. I know it's a hobby project so I'm not being critical of their work. But if we're only interested in reducing bugs then rewriting an existing project isn't the right way to go. Something like Zellij makes more sense because it's offering something new in addition to being written in Rust.

greenavocado 1y ago

This is funny, but unfortunately .NET went all in on the AI coding assistant kool-aid. https://github.com/dotnet/runtime/pull/115762 https://github.com/dotnet/runtime/pull/115762 https://github.com/dotnet/runtime/pull/115743 https://github.com/dotnet/runtime/pull/115743 https://github.com/dotnet/runtime/pull/115733 https://github.com/dotnet/runtime/pull/115733 https://github.com/dotnet/runtime/pull/115732 https://github.com/dotnet/runtime/pull/115732

tacker2000 1y ago
Wow, so this MS dev is trying out Copilot on the dotnet repo and doesnt even configure it correctly beforehand? Or was that comment just a cop-out because Copilot’s results were complete nonsense?
- greenavocado 1y ago
  "Configuration" problems are a complete fabrication. Copilot is just that bad.

deleted 1y ago

[deleted]