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

Introducing Rust Language Server

internals.rust-lang.org

Post reply on HN
Print view View original

101–108 of 108 posts

Re: Introducing Rust Language Server

#101

Post by iopq »

Manishearth wrote: post #92
iopq wrote: post #90

Earlier quoted context omitted.

Note that Monoid here is ONLY for the reason that Cow doesn't satisfy Add. In fact, String doesn't satisfy it either. So I need to have a trait that allows me to call a function that concatenates my types. I already wrote how to concatenate Strings and Cow s in my Monoid crate so I'm just re-using that. It could be T: Concatenable for all I care, but the rest of the function needs to look this way, more or less. I on…

I'm not just talking about Monoid, I'm talking about the overall signature -- with the Fn and the abstractions it's very Haskelly. Such functions are not common in Rust. You find them (all the iterator adaptors, for one), and they can be "good Rust", but they're not common. Which is okay. (I don't disagree that Rust is more complicated than Python, just addressing GP's comment whether or not this is "good" rust.)

It's actually very common to pass around hashmaps of functions in dynamic languages. If anything, since you don't even have to know how they're implemented it's easier. I realize that my function incurs a run time cost because I'm making an array of trait objects. When I'm writing JavaScript I don't know and I don't care.

Re: Introducing Rust Language Server

#102

Post by iopq »

lmm wrote: post #91
iopq wrote: post #76

Earlier quoted context omitted.

There's plenty of fighting the compiler. error[E0281]: type mismatch: the type `fn(_) -> _ {tool::second:: }` implements the trait `std::ops::FnMut `, but the trait `for std::ops::FnMut ` is required (expected concrete lifetime, found bound lifetime parameter ) --> src\lib.rs:53:11 | 53 | .filter(apply(second, i)) | ^^^^^ | = note: required by `apply` error[E0271]: type mismatch resolving `for _ {tool::second:: } as…

I suspect I would - I'll happily guess if I can take a look at the code (or at least the signatures of "filter", "apply", "second" and "i").

`i` is just getting closed over, it's an integer

filter is from the standard lib

apply is defined as

    fn apply(mut f: F, a: A) -> impl FnMut(&B) -> C
         where F: FnMut(&B) -> G,
               G: FnMut(A) -> C,
               A: Clone
    {
        move |b| f(b)(a.clone())
    }
second comes from

https://github.com/Stebalien/tool-rs/blob/master/src/sequenc... which means you have to track down its implementation somewhere in macros

Re: Introducing Rust Language Server

#103

Post by iopq »

lmm wrote: post #91
iopq wrote: post #76

Earlier quoted context omitted.

There's plenty of fighting the compiler. error[E0281]: type mismatch: the type `fn(_) -> _ {tool::second:: }` implements the trait `std::ops::FnMut `, but the trait `for std::ops::FnMut ` is required (expected concrete lifetime, found bound lifetime parameter ) --> src\lib.rs:53:11 | 53 | .filter(apply(second, i)) | ^^^^^ | = note: required by `apply` error[E0271]: type mismatch resolving `for _ {tool::second:: } as…

I suspect I would - I'll happily guess if I can take a look at the code (or at least the signatures of "filter", "apply", "second" and "i").

I put the whole code in a separate branch for you:

https://bitbucket.org/iopq/fizzbuzz-in-rust/src/920bd2bd1267...

this doesn't work, so I want you to tell me why

Re: Introducing Rust Language Server

#104

Post by iopq »

kibwen wrote: post #99
iopq wrote: post #79

Earlier quoted context omitted.

> I don't consider Rust to be a particularly complex language > I put it on par with Python Python doesn't have complicated lifetime errors, confusing trait not being satisfied errors. Python function declarations don't need three lines of code. I mean wtf is this? fn accumulate (tuples: &[(&'a str, &Fn(i32) -> bool)], i: i32) -> Option where T: From there's about ten language features in these lines of code that Pyt…

I consider "complexity" to refer to both the quantity of language features and the number of significant or surprising interactions that exist between every language feature. Rust and Python are both medium-complexity languages, but the difference is that in Python you can totally ignore e.g. generators or decorators or (oh god) metaclasses and still get work done. In Rust you really can't get work done until you und…

I ran into higher rank lifetimes while trying to use a library in my program. You can totally pass closures around in a dynamic language like JavaScript without any issues (you just pay for it in performance). In Rust `-> impl Trait` is a new feature so it's still not at all polished.

I would argue that Rust has a higher learning curve overall than any dynamic language because of its type system.

Re: Introducing Rust Language Server

#105

Post by iopq »

pcwalton wrote: post #94
iopq wrote: post #76

Earlier quoted context omitted.

There's plenty of fighting the compiler. error[E0281]: type mismatch: the type `fn(_) -> _ {tool::second:: }` implements the trait `std::ops::FnMut `, but the trait `for std::ops::FnMut ` is required (expected concrete lifetime, found bound lifetime parameter ) --> src\lib.rs:53:11 | 53 | .filter(apply(second, i)) | ^^^^^ | = note: required by `apply` error[E0271]: type mismatch resolving `for _ {tool::second:: } as…

That's a bad error message. Please file a bug :) It sounds like you're returning closures, which is a very recent feature—it only became possible last month with the implementation of "impl Trait" IIRC. It takes time for features to mature.

https://github.com/rust-lang/rust/issues/37300

Re: Introducing Rust Language Server

#106

Post by lmm »

iopq wrote: post #103
lmm wrote: post #91

Earlier quoted context omitted.

I suspect I would - I'll happily guess if I can take a look at the code (or at least the signatures of "filter", "apply", "second" and "i").

I put the whole code in a separate branch for you: https://bitbucket.org/iopq/fizzbuzz-in-rust/src/920bd2bd1267... this doesn't work, so I want you to tell me why

Hmm fair enough, harder than I thought (I don't know Rust, the error just sounded sensible). It reads like the function you're passing into filter is supposed to be "lifetime-generic" taking a parameter whose lifetime comes from the for, but the function returned by apply has a fixed lifetime. But I can't see where it's getting the lifetime for that from, or what to do about it. I guess at that point I'd try adding an explicit lifetime to the return type of apply (or maybe an IDE could show it without having to write it)?

Re: Introducing Rust Language Server

#107

Post by iopq »

lmm wrote: post #106
iopq wrote: post #103

Earlier quoted context omitted.

I put the whole code in a separate branch for you: https://bitbucket.org/iopq/fizzbuzz-in-rust/src/920bd2bd1267... this doesn't work, so I want you to tell me why

Hmm fair enough, harder than I thought (I don't know Rust, the error just sounded sensible). It reads like the function you're passing into filter is supposed to be "lifetime-generic" taking a parameter whose lifetime comes from the for, but the function returned by apply has a fixed lifetime. But I can't see where it's getting the lifetime for that from, or what to do about it. I guess at that point I'd try adding a…

The problem is with the function `second` that I get from the other crate. If I replace the `second` function with my own implementation it works. But for the `second` implementation from tool.rs to work, Rust needs better higher ranked lifetime support.

It would also work with a closure, but I wrote my code this way to avoid closures in the first place (I was going for point-free style).

I basically just have to write my own function:

https://bitbucket.org/iopq/fizzbuzz-in-rust/src/58bfa4c58c80...

this compiles, but it seems kind of pointless since I can only use this particular function in my case (because of the extra levels of references)

if I could use the tool.rs version, it would automatically generate all the implementations I need using macros

Re: Introducing Rust Language Server

#108

Post by iopq »

lmm wrote: post #106
iopq wrote: post #103

Earlier quoted context omitted.

I put the whole code in a separate branch for you: https://bitbucket.org/iopq/fizzbuzz-in-rust/src/920bd2bd1267... this doesn't work, so I want you to tell me why

Hmm fair enough, harder than I thought (I don't know Rust, the error just sounded sensible). It reads like the function you're passing into filter is supposed to be "lifetime-generic" taking a parameter whose lifetime comes from the for, but the function returned by apply has a fixed lifetime. But I can't see where it's getting the lifetime for that from, or what to do about it. I guess at that point I'd try adding a…

Someone helped me with it:

I had to change the `apply` function to dereference as well, that way it doesn't run into the lifetime issue. It has something to do with higher ranked lifetimes (the inability to express the higher ranked lifetime)

This is the working version:

https://bitbucket.org/iopq/fizzbuzz-in-rust/src/95451868e27f...

Post reply on HN