4 ms·

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
        What every other modern language makes this work? Dynamic languages? C++? Nope. Golang? Nope. Java? Nope. JS/Typescript? Nope. Like I said, if the feature is not compatible with the core principles of the language maybe they shouldn't be in it. Look for the issues in Github you'll see how and why the feature is not in the language. No excuses. All debatable, but arguments do make sense. And go make your case there! You absolutely don't need to do manual name mangling. It sure does have things in common with how struct literals work, and in fact you can use them right now with some of the common patterns for named parameters in Rust: foo( FooConfig::new().host("localhost").port(8080) ); enum Param { Listen { host: String, port: u16 }, Pipe { file: String }, }; foo( Param::Listen { host: "locahost", port: 8080 } ); foo( Param::Pipe { file: "./pipe".to_string() } ); Not that bad really, makes it clear what combination of params you can send. And nicely compatible with `match` patterns later in foo()! I absolutely despise this about named parameters: plot( y=100, z=300, x=200 ); --> the order of x,y,z makes it hard to read! plot( 200, 100, 300); --> much better! > You don’t have to use those features if you don’t want to. Yeah, then we can have Rust bloated like C++, a untractable codebase and many ways to do it.

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
      What every other modern language makes this work? Dynamic languages? C++? Nope. Golang? Nope. Java? Nope. JS/Typescript? Nope. Like I said, if the feature is not compatible with the core principles of the language maybe they shouldn't be in it. Look for the issues in Github you'll see how and why the feature is not in the language. No excuses. All debatable, but arguments do make sense. And go make your case there! You absolutely don't need to do manual name mangling. It sure does have things in common with how struct literals work, and in fact you can use them right now with some of the common patterns for named parameters in Rust: foo( FooConfig::new().host("localhost").port(8080) ); enum Param { Listen { host: String, port: u16 }, Pipe { file: String }, }; foo( Param::Listen { host: "locahost", port: 8080 } ); foo( Param::Pipe { file: "./pipe".to_string() } ); Not that bad really, makes it clear what combination of params you can send. And nicely compatible with `match` patterns later in foo()! I absolutely despise this about named parameters: plot( y=100, z=300, x=200 ); --> the order of x,y,z makes it hard to read! plot( 200, 100, 300); --> much better! > You don’t have to use those features if you don’t want to. Yeah, then we can have Rust bloated like C++, a untractable codebase and many ways to do it.