3 ms·

Hey rust - check it out. Compile time evaluation without macros, isn’t that neat?

• masklinn 3y ago
  You mean, like https://doc.rust-lang.org/reference/const_eval.html https://doc.rust-lang.org/reference/const_eval.html?
  • alphanullmeric 3y ago
    That’s nothing compared to what Constexpr and other c++ features let you do. The conditional compilation example for instance.
    • sitkack 3y ago
      Zig has shown the true power of constexpr in being able to provide a powerful construct that generalizes well. After sum types (and pattern matching), constexpr is the next great language feature that will be everywhere soon. I would love for Rust to fully adopt constexpr.
      • alphanullmeric 3y ago
        [flagged]
        • tcfhgj 3y ago
          Yeah, every time... and right here you see the meaning of 'every time'
        • qwertywert_ 3y ago
          Basic features? This took c++ a long time to get this done. I like c++ but not sure what is the point being negative about other languages would you prefer no one to try new things? They would accept new proposals for these if you want to contribute, or just continue complaining.
        • ojosilva 3y ago
          Named arguments in statically-typed languages is a naturally a hard thing to implement. When used in code, it also results in many folding API branches such as Foo::new(port=8088, host="localhost") or Foo::new(pipe="./myfile") – Rust preferred idiom here would be Foo::new_listen("localhost", "8088) or Foo::new_pipe("./pipefile"). So at this point idiomatic Rust is preferred. Also named parameters amplify your API naming fail surface (think misspellings!) beyond structs and impl functions... Like in "max_connexions" (sic), which is actually an unintended typo in one of the RFC proposals for naming parameters in Rust! It's hilarious. Default parameters: my_port.unwrap_or(8080) Variadics: useful, but needs to be carefully considered. There are workarounds now in nightly for C compatibility. There also concerns about how "..." and ".." syntax play out and incompatibilities on different implementation targets. And, yes, safety issues. It's not that Rust people will mumble about safety. It's that it would be stupid to design a language all around safety and then implement every cool language feature in the world today without scrutinizing them for safety issues.
          • alphanullmeric 3y ago
            1. You don’t have to use those features if you don’t want to. 2. Every other modern language makes this work, only rust makes excuses. 3. Rust already has default generic type arguments and “named parameters” for struct constructors (which in fact are mandatory), for which the same criticisms also apply to. Rust is already tedious enough to work with as is, and the last thing it needs is more builder pattern or manual name mangling. You already need mut/non mut for getters, sync/async, etc. just look at [serde](https://docs.rs/serde/latest/serde/trait.Deserializer.html https://docs.rs/serde/latest/serde/trait.Deserializer.html) or polars or ndarray. Ugliest language ever.
            • lumb63 3y ago
              You don’t have to use the language if you don’t like it or if you don’t agree with its design decisions. It sounds like you don’t like anything about the language, so adding named parameters won’t win you over.
            • ojosilva 3y ago
  • fooker 3y ago
    Not even close
    • masklinn 3y ago
      TIL compile time evaluation without macros is not compile time evaluation without macros. Thank you for the insight.
• paulddraper 3y ago
  Ssssh...the HN Rust Brigade will hear you