Rust's language ergonomics initiative • Hacker News Board

Re: Rust's language ergonomics initiative

#261

Post by steveklabnik » Sat, Mar 04, 2017, 5:04 PM UTC

rspeer wrote: post #258

JoshTriplett wrote: post #147

Earlier quoted context omitted.

> 1. Error handling. The lack of built-in support for multi-error or error union in Result is painful in dealing with different types of error in a function. Support for Result would be helpful. Or may be support for easily converting one type of error to another. Now there's lots of boiler plate code to deal with error conversion. Error chaining would be nice, too. There are a couple of crates that support this; per…

> String has a Deref instance for &str, so taking a reference to a String automatically works as a &str. You can also call .as_str(). > > Going in the other direction, you can call .to_string() to make a copy of a &str as a new String. As a beginner in Rust myself, I would like to observe that &str vs. String problems come up all the time for me. Every one of them is quickly resolved by knowing where to add an & or a…

This is one reason why the new book focuses on teaching ownership and borrowing with String and &str. You're 10)% right.

Re: Rust's language ergonomics initiative

#262

Post by steveklabnik » Sat, Mar 04, 2017, 5:05 PM UTC

rspeer wrote: post #259

JoshTriplett wrote: post #155

Earlier quoted context omitted.

I completely agree that Rust ought to build in support for the error-chaining pattern. I think I'd still prefer to have a named type, but the standard library should provide a standard way to construct that type. > 3. It's the other way around &str to String, having to call .to_string() everywhere. Make it implicit if the type expects a String while a &str is passed in. You can't turn a reference like &str into an ow…

I seem to run into functions that require String instead of &str all the time, most recently the "assert_eq!" macro which -- maybe I'm not understanding it correctly -- refuses to compare a &str to a String. Can you tell me how I would remove the excessive uses of ".to_string()" from the tests in this module? https://github.com/rspeer/rust-nlp-tools/blob/master/languag...

  fn main() {
      let s1 = "Hello, world"; // &str
      let s2 = String::from("Hello, world"); // String
      
      assert_eq!(s1, s2);
      assert_eq!(s2, s1);
  }

compiles just fine for me?

Re: Rust's language ergonomics initiative

#263

Post by f2f » Sat, Mar 04, 2017, 5:08 PM UTC

deathanatos wrote: post #164

f2f wrote: post #162

Earlier quoted context omitted.

Any time you see a decimal floating-point constant with a nonzero fractional part that doesn't end in '5', you're looking at a bug. depends on the language. for example here it is in go: Pi = 3.14159265358979323846264338327950288419716939937510582097494459 // http://oeis.org/A000796

What the person above you is saying, I think, is to remember that computers usually work in base 2. This applies to IEEE floating points, where the mantissa is in base 2; when you represent fractions in base two, they're powers of two: 1/2 (.5), 1/4 (.25), 1/8 (.125), etc. What he's asserting, I think, is that any power-of-two fraction, or any combination of those (in binary), result in a number ending in 5 when repr…

In Go, floating-point constants may have very high precision, so that arithmetic involving them is more accurate. The constants defined in the math package are given with many more digits than are available in a float64.

Having so many digits available means that calculations like Pi/2 or other more intricate evaluations can carry more precision until the result is assigned, making calculations involving constants easier to write without losing precision. It also means that there is no occasion in which the floating-point corner cases like infinities, soft underflows, and NaNs arise in constant expressions.

Re: Rust's language ergonomics initiative

#264

Post by FreeFull » Sat, Mar 04, 2017, 5:17 PM UTC

kazagistar wrote: post #193

ww520 wrote: post #156

Earlier quoted context omitted.

I really hope one day I can build a macro for ternary operator with ? and :.

Is using the if statement as a ternary that much worse? let x = if a { b } else { c }; Sure, it costs a few characters, but I appreciate the consistency and clarity.

I would strictly call that an "if expression" rather than an "if statement". It is equivalent to ?:, even though it is also a bit more verbose.

Re: Rust's language ergonomics initiative

#265

Post by pjmlp » Sat, Mar 04, 2017, 5:19 PM UTC

CalChris wrote: post #260

pjmlp wrote: post #246

Earlier quoted context omitted.

Another thing that has helped Java was the decision to use a JIT. Most Java JITs are able to remove code if it is proven unreachable, which allows to use pure Java code for what would be #ifdef in C, with the caveat that all branches must compile.

You would think that AOT would be the right time to remove dead code.

Only if it can be fully determined at compile time.

For example a debug flag can depend on a command line parameter, but it will be used to initialize a constant variable.

So the code can be shipped with both versions, and the JIT will just remove the unused branches.

Re: Rust's language ergonomics initiative

#266

Post by naasking » Sat, Mar 04, 2017, 5:36 PM UTC

CalChris wrote: post #82

steveklabnik wrote: post #68

Earlier quoted context omitted.

> which would be difficult to share across files. It's path::to::wherever::PI. That's it. Just like any other item. If you want to use only PI in your code, you'd use 'use', like any other name. Your second example is something better suited to a macro, it's true. I _think_ what you're getting at here is that you only want text substitution? I think we will have to agree to disagree if that's true :)

Well, given that you have only written two macros in your years of Rust, I would strongly encourage you or the language ergonomics initiative to openly question why this is so. Clearly, Rust has a clever approach but I'm questioning whether it is in fact a usable approach. Too much solution for not enough problem. Yes, I do like textual substitution. Guilty. This is a common old school low level paradigm. Still, the…

> Clearly, Rust has a clever approach but I'm questioning whether it is in fact a usable approach. [...] Yes, I do like textual substitution.

These two statements are not consistent. Textual substitution is not usable. The pitfalls with it have been well documented for decades, and yet the same problems persist. Why on earth would you want to perpetuate the list of problems caused by such a facility?

Syntactic macros are absolutely superior to textual substitution. You can take issue with Rust's currently limited support for macros, but to propose textual substitution as a viable and more usable alternative is simply absurd.

Re: Rust's language ergonomics initiative

#267

Post by rspeer » Sat, Mar 04, 2017, 5:39 PM UTC

steveklabnik wrote: post #262

rspeer wrote: post #259

Earlier quoted context omitted.

I seem to run into functions that require String instead of &str all the time, most recently the "assert_eq!" macro which -- maybe I'm not understanding it correctly -- refuses to compare a &str to a String. Can you tell me how I would remove the excessive uses of ".to_string()" from the tests in this module? https://github.com/rspeer/rust-nlp-tools/blob/master/languag...

fn main() { let s1 = "Hello, world"; // &str let s2 = String::from("Hello, world"); // String assert_eq!(s1, s2); assert_eq!(s2, s1); } compiles just fine for me?

Okay, once again I try to find an example from my code, and once again it turns out that Rust makes it simple in the simple case, but the more complex cases are still confusing.

If I change the test value Some("zh".to_string()) into Some("zh"), it points to that line and tells me:

    expected struct `std::string::String`, found &str

Sure, it's a different situation because the value is wrapped in an Option. But if String and &str are truly compatible, I would never expect to see that error message.

Re: Rust's language ergonomics initiative

#268

Post by erickt » Sat, Mar 04, 2017, 5:43 PM UTC

yarper wrote: post #125

After writing Rust in production for a while, the biggest bugbear I have is the naming/file structure. I end up a lot with this; src/main.rs src/combobulator/mod.rs src/combobulator/tests.rs src/tests.rs src/somethingelse/tests.rs src/somethingelse/mod.rs Because I find tests in the same file a bit confusing. It's really easy with maven-style layouts to know that "only things in main/java or main/scala get compiled a…

One approach for this that I haven't really seen get used much that you can use a macro to get around this. In your comboluator.rs, just add this at the bottom of the file:

    #[cfg(test)]
    Mod tests {
        include!("comboluator_tests.rs");
    }

Then write your tests there. It allows you to write unit tests against private things, but also allows you to decouple the files to keep things cleaner.

Re: Rust's language ergonomics initiative

#269

Post by tedmielczarek » Sat, Mar 04, 2017, 5:54 PM UTC

CalChris wrote: post #82

steveklabnik wrote: post #68

Earlier quoted context omitted.

> which would be difficult to share across files. It's path::to::wherever::PI. That's it. Just like any other item. If you want to use only PI in your code, you'd use 'use', like any other name. Your second example is something better suited to a macro, it's true. I _think_ what you're getting at here is that you only want text substitution? I think we will have to agree to disagree if that's true :)

Well, given that you have only written two macros in your years of Rust, I would strongly encourage you or the language ergonomics initiative to openly question why this is so. Clearly, Rust has a clever approach but I'm questioning whether it is in fact a usable approach. Too much solution for not enough problem. Yes, I do like textual substitution. Guilty. This is a common old school low level paradigm. Still, the…

I very rarely write macros despite having written thousands of lines of Rust, but they are super useful on occasion. Often in Rust something that you might have used preprocessor macro tricks to do in C can be done without macros at all. At other times, Rust macros will let you do things that would be impossible to express in C.

Re: Rust's language ergonomics initiative

#270

Post by erickt » Sat, Mar 04, 2017, 6:08 PM UTC

jnordwick wrote: post #244

JoshTriplett wrote: post #146

Earlier quoted context omitted.

I prefer to keep tests in a `mod tests { ... }` block at the end of the source file, which provides comparable benefits and separation. I also prefer to use `combobulator.rs` rather than `combobulator/mod.rs`, for multiple reasons including filename ambiguity. In this case, you'd have: src/main.rs src/combobulator.rs src/somethingelse.rs

Too much code in one place. Makes it hard to read the file and difficult to see what is code and what are tests. `wc` can no longer give you a quick approximation of code size either.

In case you didn't see, I mentioned there is a way to do this right now:

https://news.ycombinator.com/item?id=13791945