Introducing Rust Language Server
internals.rust-lang.org
internals.rust-lang.org
That isn't a glamorous task to work on, especially if you're already comfortable with the level of editor support you have, but it helps bring more people into the community, which has a multiplicative effect.
Refactoring tools would help address compiler concerns quicker, however.
error[E0281]: type mismatch: the type `fn(_) -> _ {tool::second::<_>}` implements the trait `std::ops::FnMut<(_,)>`, but the trait `for<'r> std::ops::FnMut<(&'r _,)>` 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<'r> <fn(_) -> _ {tool::second::<_>} as std::ops::FnOnce<(&'r _,)>>::Output == _`
--> src\lib.rs:53:11
|
53 | .filter(apply(second, i))
| ^^^^^ expected bound lifetime parameter , found concrete lifetime
|
= note: concrete lifetime that was found is lifetime '_#11r
= note: required by `apply`
error: aborting due to 2 previous errors
filter is from the standard lib
apply is defined as
fn apply<A, B, C, F, G>(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())
}
https://github.com/Stebalien/tool-rs/blob/master/src/sequenc... which means you have to track down its implementation somewhere in macros
https://bitbucket.org/iopq/fizzbuzz-in-rust/src/920bd2bd1267...
this doesn't work, so I want you to tell me why
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
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...
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.
Rust is a punishing language in the same way a notifying spell checker is a punishing tool. For someone used to writing without stopping and reviewing at the end, spell checking as you go might at first be annoying. After a while, you integrate it into your style, and choose the best time to deal with the errors when they come up yourself, whether that be immediately, after the paragraph/idea is expressed, or at the very end. In any case, having those handy notifications of what you need to fix is useful for a good 90% or more of the problems you might encounter.
(I don't remember similar experiences learning other languages even with strong static checks (e.g. haskell). Either my errors were 1 level deep there, or the propagation of errors (like changing a type somewhere) was easier to follow/predict to me)
I use Emacs as much as possible, but for Java dev use IntelliJ because the Java plugins I've tried were always relatively clunky. Having great language support regardless of editor sounds wonderful!
One really interesting thing about this effort is that the IntelliJ folks have their own stuff for autocomplete; they're not using racer.
Does Roslyn have the same support?
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.
P.S. Regarding Java dev on Emacs, ENSIME (http://ensime.github.io) now works with java-mode rather than only Scala. I use it for Android development, and it's not perfect but works well enough.
So, yeah - the community inspired me, and I hope the RLS inspires other people to contribute to Rust and the tooling around it as well!
Within Mozilla, they can use servo as a selling point or turn to creators for help, but from the outside world, we've got so many languages available, while some might not be good when the software grow big, they are more beginner-friendly than Rust. Hence Rust needs all those tooling from the very start.
A foreknowledge of pointers helps, but for anyone for whom Rust is their first systems language, it's going to be Rust's task to teach them e.g. the stack/heap distinction, or what "aliasing" means, or why there are two string types (let's hope they're already versed in Unicode...), or how to design a system in the absence of pure OO.
C style pointer tricks are better left for level two, so to speak.
Probably a good approach teach Rust's OO way is to introduce traits as kind of extensible modules that can be composed and go from there.
It is not 100% correct, but I guess it is easier to teach than going full theory with traits being a kind of type classes and do on.
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<'a, T: Monoid>(tuples: &[(&'a str, &Fn(i32) -> bool)], i: i32) -> Option<T>
where T: From<&'a str>
I would think it's the latter, but I don't know, to be honest.
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<str> because I want to bench the performance of both. (Cow<str> is always faster)
(I don't disagree that Rust is more complicated than Python, just addressing GP's comment whether or not this is "good" rust.)
You will find examples of this mostly in libraries, but rarely its something a beginner would write. You can actually do a lot without ever using lifetimes. Eventually you'll need to learn to read this though, and its just a matter of getting used to it. I'd say none of those is any harder to understand then let say nested list comprehension in python.
I would argue that Rust has a higher learning curve overall than any dynamic language because of its type system.
That said, there are more tools to be built to make it even better. https://internals.rust-lang.org/t/borrow-visualizer-for-the-... is one extension I'm very interested in seeing.
Again, just want to mention that my point is simply that Rust needs more tooling to overcome its learning hurdles, and to me this is not a bad thing. Because once we have tools solving the learning curve problem, we can enjoy all the benefits Rust provides :)
It would help a lot in regards to language productivity.
edit: It looks like the error message changes may have been reverted (https://phabricator.haskell.org/rGHC92c924e07dfef327509555c2...) :( Sad that they reverted it instead of fixed it.
Compared to what ? Community designed languages like D, Nim, w/e - no dispute here. But corporately backed languages such as C#, F#, Swift, TypeScript, Kotlin - not really. I guess it's fair since Rust is middle ground - sponsored by Mozilla but not getting the level of investment as the others mentioned.
Rust is a community language (admittedly with the organisational backing of Mozilla), but is driving the whole ecosystem.
Swift also has a library[3] called SourceKit which does the same thing for Swift – it can run as an out-of-process daemon, and people have written integrations for Atom, Emacs, etc. to get autocomplete, syntax highlighting, def links, etc.
[1]https://github.com/Microsoft/language-server-protocol [2]https://github.com/Microsoft/vscode-languageserver-node [3]https://github.com/apple/swift/tree/master/tools/SourceKit
The Rust development experience in VS: Code is the only reason why I use it.
Kudos to everyone.
It's being built my MS and they are quick to respond to feedback and pull requests.
It's great that Rust will decode and encode the JSON quickly (I've been keeping an eye on Rust's MSVC progress before I consider using it for a real-world project), but the project I work on cares about optimizations on the level of in-memory data layout and memory allocations. Moving syntax highlighting into a pluggable system would be a huge performance regression.
> I've been keeping an eye on Rust's MSVC progress before I consider using it for a real-world project
The latest builds of MSVC claim to have native Rust syntax highlighting and autocomplete, I have not yet tried it myself: https://www.visualstudio.com/news/releasenotes/vs15-relnotes
If you have the time, you should really consider helping to improve the Rust experience on Windows. There's a huge shortage of Windows developers in the Rust community.
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.
(Also, you wouldn't necessarily need to transmit the whole editor state--just changes).
"My project depends on my editor being super fast."
"What are you writing that has that requirement?"
"I'm writing my editor."
The latency of both Unix IPC calls and serialization/deserialization of small amounts of JSON should be measured in single- to double-digit microseconds. A frame at 60fps is 16,000 microseconds, so if this is causing even a single dropped frame, something is seriously wrong.
The lexing itself might or might not be a performance worry, depending on the architecture of the whole system, but that's no different from the lexing built into the editor (except perhaps in that people writing editors tend to care more about latency)...
(Well, this seems academic, since according to other comments RLS doesn't aim to put syntax highlighting out of process.)
Side note: really looking forward to rolling this into Rust support for Sourcegraph (Sourcegraph team member here) to make any Rust library as easy to explore as https://sourcegraph.com/github.com/gorilla/websocket/-/blob/... and https://sourcegraph.com/github.com/staltz/xstream@master/-/b... are for Go and TypeScript. Thanks for making and open-sourcing this!
I look forward to seeing support for this integrated with vim.
1. run any build steps that directly depend on file X
2. run any build steps that directly or indirectly depend on file X
3. get whether the build of X succeeded or failed, and console output