4 ms·

Zig is currently the most promising answer for many gamedevs looking for a more modern C without all the footguns of C++. Rust is trying to solve problems we d

Zig is currently the most promising answer for many gamedevs looking for a more modern C without all the footguns of C++. Rust is trying to solve problems we don't have. Jai is too closed.

pjmlp 5y ago
Like this remote execution exploit on Source engine? https://twitter.com/the_secret_club/status/1380868759129296900?s=20 https://twitter.com/the_secret_club/status/13808687591292969... Great that your customers are on the safe side.
- throwaway17_17 5y ago
  Is there any explanation of the cause of this exploit? I’m more curious than trying to contradict it as an example.
  - pjmlp 5y ago
    Yes, including some demos, https://www.bleepingcomputer.com/news/security/cs-go-valve-source-games-vulnerable-to-hacking-using-steam-invites/ https://www.bleepingcomputer.com/news/security/cs-go-valve-s...
- kristoff_it 5y ago
  The full write up shows that the exploit is based on a integer underflow that would be easily caught by Zig and any other programming language with sane runtime checks. Ironically enough this is the one class of bugs that Rust would not have prevented out of the box since the language defines integers to be wrapping and you need to manually opt into runtime checks. The exploit: https://secret.club/2021/04/20/source-engine-rce-invite.html https://secret.club/2021/04/20/source-engine-rce-invite.html Wrapping in Rust: https://huonw.github.io/blog/2016/04/myths-and-legends-about-integer-overflow-in-rust/ https://huonw.github.io/blog/2016/04/myths-and-legends-about... https://scattered-thoughts.net/writing/how-safe-is-zig/ https://scattered-thoughts.net/writing/how-safe-is-zig/ I hope that explains how inappropriate is the tone of your comment.
  - pjmlp 5y ago
    If you want we can start counting examples if that is your point, I can pick another one that doesn't use integer overflow. What is the solution for use-after-free on Zig today, that isn't just like using Purify?
    - pron 5y ago
      That depends on what you mean by "just like." Zig does not make sound static guarantees about use-after-free, because those guarantees have other costs that Zig would rather not pay. This means that detecting the problem might requires some dynamic analysis. But that doesn't mean that it's "just like" such analyses in C, because Zig does make guarantees that are fundamentally different from C's. In particular, unless you resort to syntactically delineated constructs -- analogous to unsafe in Rust -- Zig does not have pointer arithmetic or arrays of unknown size. Unlike in C, in (the safe subset of) Zig every pointer is known and every object is known. This means that it's easier to build more precise and more effective mechanisms that detect such errors in Zig than in C. In other words, if you mean that use-after-free is handled in Zig in a manner that's very different from how it's handled in either Java or Rust and more similar to the general approach of how it's handled by various tools for C, then that's correct. If you mean that that general approach is just as (in)effective in Zig as it is in C, then that is incorrect. Because Zig is fundamentally more precise than C, analyses of Zig, even if they are conceptually similar to those done for C, can be more precise and effective.
      - pcwalton 5y ago
        It's hard to figure out exactly what you're saying, but I think you're trying to imply that bounds checks will allow for the development of some kind of novel use-after-free mitigation. Without a specific proposal I don't know why that would be the case. Zig is not meaningfully different from C++ when it comes to UAF.
        pron 5y ago
        > Zig is not meaningfully different from C++ when it comes to UAF. Without pointer arithmetic, unsafe casts (Zig is much easier to write without such casts than C, at least), unsafe unions, and unknown buffer sizes, the set of pointers in a Zig program can be well-defined, as pointers can come into being only in very specific ways (they have a simple provenance). Because the set of pointers is well defined, it can be precisely tracked and analysed. This means that 1. pointers can be traced even with arena allocators or perhaps even other kinds of pools (provided they cooperate with the tool) and 2. dangling pointers can be detected even without being dereferenced. This is simply not something that analysers for C or C++ can do (at least not nearly as easily). The way to think about it is that in Zig, when an object (including an allocator) is deallocated, you can invalidate the full set of pointers pointing to it, and that set it the only way of generating more pointers into it. That's not the case in C or C++. For one, pointers aren't well defined (unions); for another, a valid pointer could be used to create an invalid one.
cosmic_quanta 5y ago
In your opinion, what is Rust solving that you're not interested in?
- throwaway17_17 5y ago
  For me personally, if Rust’s features were limited the safety focused features of the language, I could probably be alright. Although I do not think the concept of ownership is the right semantic basis for a programming paradigms. For me the real deal breakers are the following attributes: the package management system, the generics implementation, the focus on ML styled pattern matching syntax and semantics, and the heavy focus on abstraction and building towers thereof. I am aware that maybe the usage of those things are optional, but in my second-hand experience the Rust community is absolutely devoted to the exclusive idiomatic usage of the language, and I wouldn’t want to spend any time arguing about how I just want to program what I want. tl;dr nearly all of Rust is geared towards trying to solve problems I am not interested in, but it isn’t really the ‘borrow checker’ area that I personally find most off putting.
  - dnautics 5y ago
    Out of curiosity: What is it about rust package management that you dislike (zig is due to get its package manager soon)
    - throwaway17_17 5y ago
      I am certain the following is going to be very much a niche opinion, but I’ll give it anyway. There are two primary reasons I dislike the package management (and yes, this applies to Rust, Zig, Python, Go, basically everything JavaScript, etc) system both in theory and practice. First, I am of the opinion that any centralized package management inevitably leads to heavy reliance on those packages. The comments of ‘there is a crate for that’ or ‘just look on NPM’ or ‘it’s on PIP’ are often the first answers anyone gives to people looking to write code to do a certain thing. That leads to towers of imports and dependencies. I am fundamentally opposed to not writing the simplest and most specific code for any given problem. Package management is a type of institutional environment directly opposed to that fundamental opinion. I am not interested in generic, allegedly re-usable, solutions, I want the most simplistic/direct solution/implementation I can code. Now sometimes that solution is a library and sometimes that library is complex, but that is a decision that is made purposefully and with the knowledge that the dependency MUST be managed as though the code was written by you. I think the package management paradigm being used/targeted by most modern languages assume that by using a dependency means I am outsourcing a potion of my code to others and that I am willing and able to change my code according to what changes with the dependency. I tend to only use direct source dependencies that I can make completely local and that code just becomes part of my program, and yes that means there are no updates to that code I do not make myself. An update of the dependency itself will only be included after reviewing the update as though it were a new dependency, i.e. purposefully and by me, not whenever the vendor wants and not whatever the vendor chooses. I am aware that there is no requirement to use package management to incur what I find are negatives, but I truly believe that the environment and common usage patterns push development practice towards the type of coding practices I dislike. Second, for work purposes, I can not use any code I can not warranty as fit for purpose and conforming to terms of a given contract. This means that any code which has a ‘no warranty’ statement in the license (which is almost all library code in every language regardless of distribution mechanism) I can only use once I have reviewed enough of it and am confident enough in it that I can put specific functional guarantees in place regarding specific performance of contract terms. Package management systems, and their accompanying practices, are not particularly appealing when the package management strategy seeks to continually push updates and continually seeks to stack reliance on large dependency trees. I am often better off designing and programming something myself that attempting to review to an acceptable degree a tangled mess of dependency. I find that, while often an explicit non-goal for most programming languages, I would best be served by explicitly bare source code libraries, which are stored and compiled locally, and are incorporated into a project purposefully and in the same manner as files authored by me. Again, I am aware my requirements are not industry standard and my opinions are not mainstream, but there ya go.
kobebrookskC3 5y ago
> Rust is trying to solve problems we don't have. I'm sure you mean negative externalities that your customers aren't equipped to appropriately price.

Zig is currently the most promising answer for many gamedevs looking for a more modern C without all the footguns of C++. Rust is trying to solve problems we don't have. Jai is too closed.

pjmlp 5y ago

Like this remote execution exploit on Source engine? https://twitter.com/the_secret_club/status/1380868759129296900?s=20 https://twitter.com/the_secret_club/status/13808687591292969... Great that your customers are on the safe side.

throwaway17_17 5y ago
Is there any explanation of the cause of this exploit? I’m more curious than trying to contradict it as an example.
- pjmlp 5y ago
  Yes, including some demos, https://www.bleepingcomputer.com/news/security/cs-go-valve-source-games-vulnerable-to-hacking-using-steam-invites/ https://www.bleepingcomputer.com/news/security/cs-go-valve-s...
kristoff_it 5y ago
The full write up shows that the exploit is based on a integer underflow that would be easily caught by Zig and any other programming language with sane runtime checks. Ironically enough this is the one class of bugs that Rust would not have prevented out of the box since the language defines integers to be wrapping and you need to manually opt into runtime checks. The exploit: https://secret.club/2021/04/20/source-engine-rce-invite.html https://secret.club/2021/04/20/source-engine-rce-invite.html Wrapping in Rust: https://huonw.github.io/blog/2016/04/myths-and-legends-about-integer-overflow-in-rust/ https://huonw.github.io/blog/2016/04/myths-and-legends-about... https://scattered-thoughts.net/writing/how-safe-is-zig/ https://scattered-thoughts.net/writing/how-safe-is-zig/ I hope that explains how inappropriate is the tone of your comment.
- pjmlp 5y ago
  If you want we can start counting examples if that is your point, I can pick another one that doesn't use integer overflow. What is the solution for use-after-free on Zig today, that isn't just like using Purify?
  - pron 5y ago
    That depends on what you mean by "just like." Zig does not make sound static guarantees about use-after-free, because those guarantees have other costs that Zig would rather not pay. This means that detecting the problem might requires some dynamic analysis. But that doesn't mean that it's "just like" such analyses in C, because Zig does make guarantees that are fundamentally different from C's. In particular, unless you resort to syntactically delineated constructs -- analogous to unsafe in Rust -- Zig does not have pointer arithmetic or arrays of unknown size. Unlike in C, in (the safe subset of) Zig every pointer is known and every object is known. This means that it's easier to build more precise and more effective mechanisms that detect such errors in Zig than in C. In other words, if you mean that use-after-free is handled in Zig in a manner that's very different from how it's handled in either Java or Rust and more similar to the general approach of how it's handled by various tools for C, then that's correct. If you mean that that general approach is just as (in)effective in Zig as it is in C, then that is incorrect. Because Zig is fundamentally more precise than C, analyses of Zig, even if they are conceptually similar to those done for C, can be more precise and effective.
    - pcwalton 5y ago
      It's hard to figure out exactly what you're saying, but I think you're trying to imply that bounds checks will allow for the development of some kind of novel use-after-free mitigation. Without a specific proposal I don't know why that would be the case. Zig is not meaningfully different from C++ when it comes to UAF.
      - pron 5y ago
        > Zig is not meaningfully different from C++ when it comes to UAF. Without pointer arithmetic, unsafe casts (Zig is much easier to write without such casts than C, at least), unsafe unions, and unknown buffer sizes, the set of pointers in a Zig program can be well-defined, as pointers can come into being only in very specific ways (they have a simple provenance). Because the set of pointers is well defined, it can be precisely tracked and analysed. This means that 1. pointers can be traced even with arena allocators or perhaps even other kinds of pools (provided they cooperate with the tool) and 2. dangling pointers can be detected even without being dereferenced. This is simply not something that analysers for C or C++ can do (at least not nearly as easily). The way to think about it is that in Zig, when an object (including an allocator) is deallocated, you can invalidate the full set of pointers pointing to it, and that set it the only way of generating more pointers into it. That's not the case in C or C++. For one, pointers aren't well defined (unions); for another, a valid pointer could be used to create an invalid one.

cosmic_quanta 5y ago

In your opinion, what is Rust solving that you're not interested in?

throwaway17_17 5y ago
For me personally, if Rust’s features were limited the safety focused features of the language, I could probably be alright. Although I do not think the concept of ownership is the right semantic basis for a programming paradigms. For me the real deal breakers are the following attributes: the package management system, the generics implementation, the focus on ML styled pattern matching syntax and semantics, and the heavy focus on abstraction and building towers thereof. I am aware that maybe the usage of those things are optional, but in my second-hand experience the Rust community is absolutely devoted to the exclusive idiomatic usage of the language, and I wouldn’t want to spend any time arguing about how I just want to program what I want. tl;dr nearly all of Rust is geared towards trying to solve problems I am not interested in, but it isn’t really the ‘borrow checker’ area that I personally find most off putting.
- dnautics 5y ago
  Out of curiosity: What is it about rust package management that you dislike (zig is due to get its package manager soon)
  - throwaway17_17 5y ago
    I am certain the following is going to be very much a niche opinion, but I’ll give it anyway. There are two primary reasons I dislike the package management (and yes, this applies to Rust, Zig, Python, Go, basically everything JavaScript, etc) system both in theory and practice. First, I am of the opinion that any centralized package management inevitably leads to heavy reliance on those packages. The comments of ‘there is a crate for that’ or ‘just look on NPM’ or ‘it’s on PIP’ are often the first answers anyone gives to people looking to write code to do a certain thing. That leads to towers of imports and dependencies. I am fundamentally opposed to not writing the simplest and most specific code for any given problem. Package management is a type of institutional environment directly opposed to that fundamental opinion. I am not interested in generic, allegedly re-usable, solutions, I want the most simplistic/direct solution/implementation I can code. Now sometimes that solution is a library and sometimes that library is complex, but that is a decision that is made purposefully and with the knowledge that the dependency MUST be managed as though the code was written by you. I think the package management paradigm being used/targeted by most modern languages assume that by using a dependency means I am outsourcing a potion of my code to others and that I am willing and able to change my code according to what changes with the dependency. I tend to only use direct source dependencies that I can make completely local and that code just becomes part of my program, and yes that means there are no updates to that code I do not make myself. An update of the dependency itself will only be included after reviewing the update as though it were a new dependency, i.e. purposefully and by me, not whenever the vendor wants and not whatever the vendor chooses. I am aware that there is no requirement to use package management to incur what I find are negatives, but I truly believe that the environment and common usage patterns push development practice towards the type of coding practices I dislike. Second, for work purposes, I can not use any code I can not warranty as fit for purpose and conforming to terms of a given contract. This means that any code which has a ‘no warranty’ statement in the license (which is almost all library code in every language regardless of distribution mechanism) I can only use once I have reviewed enough of it and am confident enough in it that I can put specific functional guarantees in place regarding specific performance of contract terms. Package management systems, and their accompanying practices, are not particularly appealing when the package management strategy seeks to continually push updates and continually seeks to stack reliance on large dependency trees. I am often better off designing and programming something myself that attempting to review to an acceptable degree a tangled mess of dependency. I find that, while often an explicit non-goal for most programming languages, I would best be served by explicitly bare source code libraries, which are stored and compiled locally, and are incorporated into a project purposefully and in the same manner as files authored by me. Again, I am aware my requirements are not industry standard and my opinions are not mainstream, but there ya go.

kobebrookskC3 5y ago

> Rust is trying to solve problems we don't have. I'm sure you mean negative externalities that your customers aren't equipped to appropriately price.