• 1 Post
  • 351 Comments
Joined 2 年前
cake
Cake day: 2023年9月2日

help-circle









  • If a crate only takes 35 lines to reproduce. Why is the author worried that it is unmaintained?

    That crate is probably done, it does what it needs to do. And at 35 lines there’s not a lot of room for bugs.

    Just use the crate instead of rewriting the same 35 lines for each project that needs them.

    Or publish your own 35 line crate as an alternative. Then you can use your 35 lines instead of that guy’s 35 lines.

    I don’t understand the LoC bit. First he says the project+dependencies is 3.6MLoC. then says that the Linux kernel is 27.8MLoC, then says his project is 7. 7 what? 7%? That’s not right. 7MLoC? I thought it was 3.6MLoC.


  • Technically, this may sound pedantic. You are not passing neither arrays nor tuples as generic parameter types.

    What you are doing is passing an array to a function.

    The type of the array is [i32;5]. Every value has a type.

    By passing the array to a function, you are allowing the compiler to infer what function you are calling, since that function is generic. Using the type of the parameter you passed to it.

    You can only pass values to function parameters. And you can only pass types as generic type parameters.

    Well in this case it’s a little different, since it looks like you are passing a value (5) to a generic type parameter (LENGTH), but the const part of const LENGTH means that it’s a value generic for a type, not a type generic for a type, which is the usual thing.

    EDIT: additionally, the : usize part tells you what type exactly the const parameter for the type has to be.

    Note that you can’t have non-const values as type parameters. Since types are defined at compile time.

    EDIT 2: since type inference just fills some boilerplate for you. If we do that boilerplate manually it’s easier to see what parameters go where.

    When you do Buffer::from([0,1,2,3,4,5]) what you are really doing is: Buffer<i32, 5>::from([0,1,2,3,4,5)]. In fact, if you put that, the code will compile exactly the same. Now if you put a 6 instead, it won’t compile since the type of the buffer and the type of the array you are passing are not the same.


  • You don’t need to know at all what optimizations will happen. I said that as an example of a thing that you know in compile time but not in run time.

    To tell or not whether a type will be inferred is determined by you. If you tell the compiler the type, it will never be inferred. If you don’t tell the compiler the type, it will try to infer it. If it tries to infer the type but it fails, it will throw a compiler error and it won’t finish building the binary.

    The compiler will only successfully infer a type if it has enough information at compile time to know with certainty what type it is. Of course, the compiler is not perfect, so it is possible in complex situations for it to fail even though it theoretically could.

    Examples where inferring will succeed:

    
    fn copy<T>(in: T) -> T {
        return in;
    }
    
    fn main() {
        let a = 47; //here a is of type i32, this was not inferred, it's just the default type of integer literals
        let b = copy(a); // here the compiler knows that a is i32, therefore it should call copy<i32>. Due to the type signature of copy<i32>, the type of b is inferred to be i32
    
        let c: u16 = 25; // here instead of the default, we manually specify that the type of c is u16
        let d = copy(c); // this is the same as b, but instead of calling copy<i32>, copy<u16> is called. Therefore d is inferred to be u16
    
        let e = 60; // at first, this looks like a, and it should be  the default of i32
        let f: i64 = copy(e); // here, since f is specified to be i64, copy<i64> is called. Therefore e instead of being the default of i32, it is overridden since inference has preference over the default. e is inferred to be i64.
    }
    

    Examples where inference will fail

    
    trait Default {
       fn default() -> Self
    }
    
    impl Default for i32 {
        fn default() -> i32 { return 0 }
    }
    
    impl Default for i8 {
        fn default() -> i8 { return 0}
    }
    
    fn main() {
        let a: i32 = 8;
        let b = copy(a);
        let c: u8 = copy(b);
        // What type should be inferred to? If it calls copy<i32> because a is i32, then it can't call copy<u8> later to initialize c. And if it calls copy<u8> instead, it can't receive a as an argument since a is i32. Results in compiler error
    
        let d = Default::default();
        // What type is d? both i32 and i8 implement the Default trait, each with its own return type.
        // let d: i32 = Default::default(); would compile correctly.
    }
    

    These situations might be obvious, but inference works as a chain, sometimes hundreds of types are inferred in a single function call. So you should know the basics to diagnose these kinds of problems.



  • Nah, that would be programming with AI.

    In vibe “coding”, you ask the AI for the code and just run it. If it doesn’t do what you want it to do, you just ask the AI again, or another AI. Ad infinitum.

    Check the code yourself? That’s like 5th century pleb work, vibe “coders” would be wasting their precious time when they can just ask another AI to do it.


  • Since deadcream already told you the reason. I’m gonna explain a more generic way.

    There are 2 important times: compilation time and run time.

    At compilation time, everything that is constant, is known to the compiler, or can be calculated by it.

    At run time, everything* is known.

    Types have to be generated at compilation time**. This means that generics have to be also known at compilation time.

    In this case. Both the “T” type of the buffer and its size “LENGTH” are generic, so they must be known at compile time. Compile time usually doesn’t know about vales of variables, except if those variables are “const”. Then it is known. A value literal is the same as a const variable.

    So here, you provide a value literal ([0,1,2,3,4]) which is a fixed array, that is, both its “T” type (i32 by default) and length (5) are known at compile time. Buffer has all the information it needs to become a real type instead of a generic one. In this case, the type will be Buffer<i32, 5>

    * Things that are optimized out at compile time are not known at runtime, but yes at compile time. For example:

    const A: i32 = 5;
    const B: i32 = 5+1;
    
    fn main() {
        dbg!(B)
    }
    

    Since A is never used (except to calculate B, which is const), A is probably optimized out. However, since B is used, there probably is a 6 somewhere in memory. Notice how I say probably since optimizations are optional. Or more optimizations may even remove the 6, and convert it to an ASCII “6” to be printed out.

    **While this is always true trait objects (like Box<dyn ToString>) can act like some kind of runtime type, if you need that functionality.





  • There are many reasons you would be against china.

    1. Not a democracy
    2. Helping Russia in the invasion of Ukraine
    3. Aims to invade Taiwan
    4. You always want some amount of local manufacturing. Relying on a single supplier is never a good idea in any context if you can avoid it.
    5. Helps north Korea
    6. Claims international and other countries waters for itself
    7. Uyghurs
    8. Tibet
    9. Many active border disputes due to territorial expansion aims.
    10. Secret police stations to enforce it’s laws outside china
    11. Hong Kong

    Low prices doesn’t justify any of that.

    And that (non-exclusive) list (except the 1st point) is only what affects people outside of china. There’s many other reasons to dislike the CCP that only affects the Chinese. Like mass surveillance and censorship.


  • You got lucky. Last time for me I waited 1hour+. Why? Because I ordered inside the restaurant instead of the drive-through. Apparently they have incentives to keep the drive-through queue small and fast.

    And I’m not even in car land (America). It was in Spain. I cannot even imagine what ordering in car land from inside the restaurant will take.

    EDIT:

    Fast food still exists though, it just doesn’t come in the form of the usual American corporations. My local kebab fulfills the order in 5-10 minutes.