Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust's language ergonomics initiative

blog.rust-lang.org

Post reply on HN
Print view View original

161–170 of 295 posts

Re: Rust's language ergonomics initiative

#161

Post by kbenson »

ww520 wrote: post #156
CalChris wrote: post #17

As I've said/posted this elsewhere, the Rust macro package is close to unusable. It makes easy stuff difficult and it doesn't exactly help with difficult stuff. It would be interesting to compare the number of macros defined in the crates corpus divided by total line count and compare that with other languages. I do not think that I am alone in not using it. Yes, I use macros; I just don't program macros. Obviously,…

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

No offence, but I hope you never can, because if you can, others can, and since Rust already uses '?' for something else, it's likely to just get confusing. Is the if syntax for ternary really that bad?

Re: Rust's language ergonomics initiative

#162

Post by f2f »

pklausler wrote: post #59
CalChris wrote: post #24

Earlier quoted context omitted.

#define M_PI 3.14159265358979323846264338327950288

3.141592653589793115997963468544185161590576171875 is the exact decimal representation for the 64-bit IEEE-754 number that's closest to pi (viz. 0x400921FB54442D18). 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. EDIT: As long as this grizzled old Fortran programmer is giving out free advice, I'll add two more items every programmer…

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

Re: Rust's language ergonomics initiative

#163

Post by ww520 »

kbenson wrote: post #161
ww520 wrote: post #156

Earlier quoted context omitted.

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

No offence, but I hope you never can, because if you can, others can, and since Rust already uses '?' for something else, it's likely to just get confusing. Is the if syntax for ternary really that bad?

It's in different context. Reusing a keyword or an operator in different context happens all the time in languages.

Re: Rust's language ergonomics initiative

#164

Post by deathanatos »

f2f wrote: post #162
pklausler wrote: post #59

Earlier quoted context omitted.

3.141592653589793115997963468544185161590576171875 is the exact decimal representation for the 64-bit IEEE-754 number that's closest to pi (viz. 0x400921FB54442D18). 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. EDIT: As long as this grizzled old Fortran programmer is giving out free advice, I'll add two more items every programmer…

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 represented in decimal. Anything else is going to be rounded to the nearest representable number (that ends in 5).

So, go might have that value in its source, but it's getting rounded to something that would, if represented in decimal, end in 5.

Re: Rust's language ergonomics initiative

#165

Post by kbenson »

ww520 wrote: post #163
kbenson wrote: post #161

Earlier quoted context omitted.

No offence, but I hope you never can, because if you can, others can, and since Rust already uses '?' for something else, it's likely to just get confusing. Is the if syntax for ternary really that bad?

It's in different context. Reusing a keyword or an operator in different context happens all the time in languages.

Is it that different? Assuming you would use '?' and ':', presumable we might see both the following then:

    let foo = foo()?;
    let bar = bar() ? this() : that();

Re: Rust's language ergonomics initiative

#166

Post by tibbe »

spraak wrote: post #126

> Right now, such a signature would be accepted, but if you tried to use any of map’s methods, you’d get an error that K needs to be Hash and Eq, and have to go back and add those bounds. That’s an example of the compiler being pedantic in a way that can interrupt your flow, and doesn’t really add anything; the fact that we’re using K as a hashmap key essentially forces some additional assumptions about the type. But…

Type inference should solve that if Go ever gets that.

Re: Rust's language ergonomics initiative

#167

Post by shmolyneaux »

MrF3ynmann wrote: post #3

I still can't get my head around rust. While all those features definitely make sense, I find it very confusing sometimes. Is there something like rust for c++ programmers?

There is a porting guide for C/C++ [0] that may help clarify the differences between the two. I have not read it though.

[0] https://locka99.gitbooks.io/a-guide-to-porting-c-to-rust/con...

Re: Rust's language ergonomics initiative

#168

Post by ww520 »

JoshTriplett wrote: post #155
ww520 wrote: post #151

Earlier quoted context omitted.

1. Some of the 3rd party error chain libraries help somehow but they don't help to remove the boiler plate when dealing with different types of error. I just want to be able to do: fn func1() -> Result { let foo = foo()?; // which can return Error1 let bar = bar()?; // which can return Error2 ... } 2. Error chain only shows the stack where I explicitly add it to the chain. Anything underneath is not shown. All these…

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 think I'd still prefer to have a named type, but the standard library should provide a standard way to construct that type.

Having ad-hoc error union Result per function make it lightweight, and less friction in writing code. I would go one step further, let the compiler build the error union automatically.

    fn func1() -> Result {
        let foo = foo()?;   // might return Error1
        let bar = bar()?;   // might return Error2
        ...
    }
The compiler infers the list of possible error types returning from the functions. Func1() would automatically have the return signature of Result.

Make the type inference to good use.

Re: Rust's language ergonomics initiative

#169

Post by ww520 »

kbenson wrote: post #165
ww520 wrote: post #163

Earlier quoted context omitted.

It's in different context. Reusing a keyword or an operator in different context happens all the time in languages.

Is it that different? Assuming you would use '?' and ':', presumable we might see both the following then: let foo = foo()?; let bar = bar() ? this() : that();

? already has different forms as of now. You can do foo()?; or foo()?.bar(). People don't seem to be confused.

expr ? expr : expr is just another form. The ternary form is so well known that I doubt people have problem recognizing it.

Re: Rust's language ergonomics initiative

#170

Post by kazinator »

kibwen wrote: post #60
CalChris wrote: post #48

Earlier quoted context omitted.

That was just a trivial example. Yes, you could use a const which would be difficult to share across files. Moreover, if you wanted to do something equally textual #define PASS_VERBOSE if (flag_verbose && first_pass) printf you just might be able to but only with a completely different tool. A macro processor is not of the language; it is above the language.

> A macro processor is not of the language; it is above the language. Then feel free to use the C preprocessor with Rust, it works just as well. :P Just like it does with Python, and Java, and...

The C preprocessor can only be used with Python as long as you don't do anything multi-line:

   #define whatever(param) \
   foo: \
      bar \
      baz
I made a preprocessor some 18 years ago that could be used with Python.

Wayback Machine:

https://web.archive.org/web/20000815202258/http://users.foot...

Post reply on HN