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

81–90 of 108 posts

Re: Introducing Rust Language Server

#81

Post by vertex-four »

iopq wrote: post #76
fabrice_d wrote: post #10

Earlier quoted context omitted.

I don't think "fighting the compiler" is an accurate description of the Rust coding experience. There is a learning curve during which you feel like you fight the borrow checker a lot, but once you get it you will find that the compiler is actually helpful.

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…

Closure-related error messages are not one of the strong points of Rust so far, unfortunately.

Re: Introducing Rust Language Server

#82

Post by royjacobs »

drchickensalad wrote: post #80
royjacobs wrote: post #75

Earlier quoted context omitted.

Resharper has been in development far longer than Roslyn and seems to be much more suited to working with partially incorrect code (the kind you have while typing away) and incremental changes. Does Roslyn have the same support?

Roslyn is built for incomplete/flawed code

Ah, excellent!

I guess JetBrains is heavily invested in ReSharper (and the underlying AST code) which would explain why they won't want to switch right away, if at all.

Re: Introducing Rust Language Server

#83

Post by annnnd »

fabrice_d wrote: post #10
theossuary wrote: post #8

Earlier quoted context omitted.

I think it's a side effect of having a punishing language. Coding Rust is always described as fighting with the compiler, I don't think Rust would have ever taken off if there weren't great tools to fight the compiler with. I think that's a part of it, anyway.

I don't think "fighting the compiler" is an accurate description of the Rust coding experience. There is a learning curve during which you feel like you fight the borrow checker a lot, but once you get it you will find that the compiler is actually helpful.

Either that, or the Stockholm sindrom kicks in after a while. :)

Re: Introducing Rust Language Server

#84

Post by fredsir »

iopq wrote: post #79
kibwen wrote: post #54

Earlier quoted context omitted.

I agree that it depends on where you approach it from (my very first question for tutoring any new Rust user is "what languages have you used previously?"), but I'm afraid that saying "it's really not that hard" glosses over the experience of a large number of potential users. I don't consider Rust to be a particularly complex language--I put it on par with Python--but unlike Python the learning curve for Rust is rem…

> 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 only have very little Rust experience, and would like to hear from a Rust veteran - as much as one can be - if that is considered good Rust, or if it's just an example of how bad Rust can be if you don't know what you're doing, or are trying to showcase bad Rust.

I would think it's the latter, but I don't know, to be honest.

Re: Introducing Rust Language Server

#86

Post by retep998 »

Rusky wrote: post #66
retep998 wrote: post #62

Earlier quoted context omitted.

Actually, the PDB debug info has variable and type information and a lot of it actually works. There's just a few minor issues here and there with stuff like fat pointers.

Oh, that's fantastic- how recent is this? Last time I tried debugging an -msvc binary was only a couple months ago.

It might have been due to either https://github.com/rust-lang/rust/pull/31319 or an LLVM upgrade. But stuff like looking at the values of basic integer types, the fields of structs, tuple fields, thin pointers, and even many enums works fine. You just have to make sure you have debug info enabled.

Keep in mind std in the Rust distribution was built without debuginfo, so if you step into functions from that, things don't work too well.

Re: Introducing Rust Language Server

#87

Post by iopq »

fredsir wrote: post #84
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 only have very little Rust experience, and would like to hear from a Rust veteran - as much as one can be - if that is considered good Rust, or if it's just an example of how bad Rust can be if you don't know what you're doing, or are trying to showcase bad Rust. I would think it's the latter, but I don't know, to be honest.

You could write > and omit the where clause, but that seems even less readable to me. The rest basically has to be there for the function to do what it does.

Re: Introducing Rust Language Server

#88

Post by StavrosK »

wbond wrote: post #27
mattkrause wrote: post #24

Earlier quoted context omitted.

Perhaps I'm not understanding you, but how does the speed of syntax highlighting (or, more generally, the editor) affect your project's performance? I'm trying and failing to imagine some sort of realtime system controlled by someone coding away. (Also, you wouldn't necessarily need to transmit the whole editor state--just changes).

I work on Sublime Text.

Haha, I found this exchange pretty funny.

"My project depends on my editor being super fast."

"What are you writing that has that requirement?"

"I'm writing my editor."

Re: Introducing Rust Language Server

#89

Post by Manishearth »

fredsir wrote: post #84
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 only have very little Rust experience, and would like to hear from a Rust veteran - as much as one can be - if that is considered good Rust, or if it's just an example of how bad Rust can be if you don't know what you're doing, or are trying to showcase bad Rust. I would think it's the latter, but I don't know, to be honest.

It's basically an example of what happens when you try to use Haskell concepts in Rust; the type parameters explode quickly. Most rust functions are not like that. Some are. It's not exactly bad rust to have functions like that, but such functions should probably be uncommon in your codebase.

Re: Introducing Rust Language Server

#90

Post by iopq »

Manishearth wrote: post #89
fredsir wrote: post #84

Earlier quoted context omitted.

I only have very little Rust experience, and would like to hear from a Rust veteran - as much as one can be - if that is considered good Rust, or if it's just an example of how bad Rust can be if you don't know what you're doing, or are trying to showcase bad Rust. I would think it's the latter, but I don't know, to be honest.

It's basically an example of what happens when you try to use Haskell concepts in Rust; the type parameters explode quickly. Most rust functions are not like that. Some are. It's not exactly bad rust to have functions like that, but such functions should probably be uncommon in your codebase.

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 Cows 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 only have one type parameter, that's very common. I'm abstracting over String and Cow because I want to bench the performance of both. (Cow is always faster)

Post reply on HN