Announcing RLS 1.0 release candidate

announcements
1

Please help us test!

7 Likes
2

Hi @nrc, first of all I wanted to say that I am a big fan of all the progress being made on RLS, rustfmt, and all the other tooling surrounding Rust. It really makes working with the language much better.

However, for RLS specifically, I have some reservations about the viability of moving the tool to a 1.0 release.

I already posted those concerns In the " Announcing Rust 2018 Preview 2!" post, here, but I'll copy paste them here, as this is a better fit.

I wasn't sure if I was alone in this sentiment, but from looking at the Reddit thread, it looks like there are quite a few people experiencing the same.

Again, this is not a knock on all the work already done, just a question if it's really 1.0-ready yet.

As a (very) new Rustacean, it's awesome to see the speed at which the Rust community moves forward, while also still keeping backward compatibility in mind.

I had one question about this quote:

Both rustfmt and the RLS have reached 1.0 “release candidate” status. Look for more information about that soon.

I'm eagerly awaiting the "more information" part, but until then, I wonder what "1.0" means for these tools, specifically for RLS.

As a developer, I enjoy learning new programming languages (and especially the standard library) by exploring. Building small utilities in my editor, creating a variable of one type, and allowing code completion to guide me towards the capabilities of each type and how they function.

In Rust, this hasn't been such a great experience so far, unfortunately.

Specifically, RLS (and Racer) hasn't been able to complete quite some code that I've been playing with. Maybe it's just my set up, but from what I've read, I'm not the only one experiencing this, and this is because the compiler - for now - can't give RLS (all) the information it needs, having it fall back to the less accurate Racer, resulting in no code completion to show up at all, or a "goto" action going to a similarly named, but differently namespaced type.

Specifically, here are two GH issues I replied to:

The biggest problem with this is that it interrupts the workflow. When no auto-completion shows up, you start to wonder "did I do something wrong? Or is this an RLS issue? Should I report it, or is this known because of the lack of compiler support?" The next step then is to go open the (awesome!) Rust docs to find more information about that type and the methods it supports.

So my question/remark would be: if my findings are accurate, and RLS isn't that reliable yet, what's the main reason to already move it to 1.0, instead of letting it bake a bit more until its reliability is high enough?

5 Likes
3

If I may share my interpretation:

1.0 for these tools is an assertion that they are correct enough to be useful. There’s no expectation that these tools won’t release a 2.0 (in fact I think it’s already expected that rustfmt will eventually).

What a 1.0 release means for RLS specifically is that the team is confident enough in it to move it from the rls-preview component to the rls component in rustup. RLS may still be a young tool that will keep improving, but it’s good enough to recommend it for use, not in a preview state.

1 Like
4

Thanks for the feedback! I laid out some more thoughts in another blog post

I wonder what “1.0” means for these tools, specifically for RLS.

I covered this a little in the blog post announcements: for Rustfmt, 1.0 is about back compat - formatting will not change before 2.0. For the RLS it's a bit harder to pin down, but basically that we think it is ready to be widely used because for most users it should provide more help than harm.

2 Likes
5

Rust attracts people with correctness in mind, so there’s no wonder that they also apply this to a RLS 1.0 version.

There’s this running joke that a Haskell library never reaches a 1.0 version.

Thanks for all the great work Nick!

6 Likes
6

That blog post clears things up, which is great. I also want to reiterate that my post wasn’t meant to be a negative response to your proposal, more of a “take a step back and let’s see if we really want to release 1.0 now” kind of response.

As a current user of RLS, it having a 1.0 label or not doesn’t really influence my usage, and in fact, having a 1.0 release might significantly increase usage within the community, and potential contribution, thus increasing the rate of improvements over time.

What I mostly worry about is the expectations of others (as you also mentioned in the blog post), and also the “support burden” that might arise from people being unaware that there’s currently no way to support full code-completion, and thus continuously opening tickets to ask why x or y isn’t working as expected.

I guess, if the documentation/README/… makes this as clear as possible, then that burden could be reduced.

All in all, given the options at hand, and given that a public release might increase the rate of improvements in the next couple of months, I’d personally vote for a 1.0 release, while setting proper expectations.

as an aside; I’m a bit torn on the Racer proposals/improvements. I wonder how much of that work is still relevant once (in the long run) the compiler support is up to par, or if we’re making an investment here for some short-term gains that hurt the long-term planning.

Either way, thanks again for the explanation, and I love this openness and back-and-forth communication going on in this community. It has only been a couple of weeks for me since I started with Rust, but I’m having a blast and enjoy taking part in discussions on Reddit, here, and on Discord. Keep it up

2 Likes
7

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.