Try Out Rust IDE Support in Visual Studio Code

https://users.rust-lang.org/t/try-out-rust-ide-support-in-visual-studio-code/12407

by Rusky • 9 years ago

265 82 9 years ago

Rust is not only a fantastic language, but the level of community involvement from the devs is just completely unlike any other language I've seen in a very long time. That really makes me excited that it will be adopted in the industry over time and ideally replace some of the nightmare-level C++ code out there.

penpapersw• 9 years ago

I'm not that optimistic. In my experience, nightmare-level code will be written by the person who wrote it no matter what language they use. Rust doesn't look all that cleaner than C++, just that it has a few more safety guarantees. I'm sure terrible code will be written in it. And I'm sure clean code will be written in it that people without context will call terrible code.

moosingin3space2• 9 years ago

I've written awful Rust code myself, and I'd still rather be writing Rust than C++, because sticking to Rust idioms makes it harder to do the wrong thing without it being obvious.

SamReidHughes• 9 years ago

The way I'd put it is, I'd be much more confident in the ability of an open source project to survive receiving contributions from the general public if it were written in Rust rather than C++.

wtetzner• 9 years ago

I think the bigger problem is that nightmare code is the stuff nobody understands. So it's the hardest to re-write, because nobody knows what it does.

So nightmare code is the code that lives forever, whereas well-written code is easily replaceable.

staticassertion• 9 years ago

People will write awful rust code. The impact of this will not be an attacker's ability to completely take over a system. That's a level of "awful" I'll take.

vvanders3• 9 years ago

People can definitely write bad code in any language, however Rust relentlessly forces you towards single-ownership(unless you're using RefCell) which is a really good thing.

zanny• 9 years ago

The thing is nightmare Rust code is usually obvious - the dev is using a lot of unsafe{} blocks, or Cell, or is spewing out a really complex type signature.

With C++, the nightmares are just really obscured pointer manipulation that can work but have infinite edge case failure states that cause endless undefined behavior.

In Rust, if it compiles, it is at least constrained to only break what the dev explicitly broke, it doesn't break everything.

modeless2• 9 years ago

I have been using this for a few weeks, as a newcomer to Rust. Although it has some issues, I would not try to develop Rust code without it. It is incredibly useful and works well enough for day-to-day use.

Some of the issues I've found:

* Code completion sometimes simply fails to work. For example, inside future handlers (probably because this involves a lot of type inference).

* When errors are detected only the first line of the compiler error message is accessible in the UI, often omitting critical information and making it impossible to diagnose the problem.

* It is often necessary to manually restart RLS, for example when your cargo.toml changes. It can take a very long time to restart if things need to be recompiled and there isn't much in the way of progress indication.

* This is more of a missing feature, but type inference is a huge part of Rust, and it's often difficult to know what type the type inference engine has chosen for parts of your code. There's no way to find out using RLS in VSCode that I've seen, or go to the definition of inferred types, etc.

Other issues I've seen as a newcomer to Rust:

* It's very easy to get multiple versions of the same dependency in your project by accident (when your dependencies have dependencies), and there is no compiler warning when you mix up traits coming from different versions of a crate. You just get impossible-seeming errors.

* Compiler speed is a big problem.

* The derive syntax is super clunky for such an essential part of the language. I think Rust guides should emphasize derive more, as it's unclear at first how essential it really is. Almost all of my types derive multiple traits.

* In general, Rust is hard. It requires a lot more thinking than e.g. Python or even C. As a result, my forward progress is much slower. The problems I have while coding in Rust don't even exist in other languages. I'm sure this will improve over time but I'm not sure it will ever get to the point where I feel as productive as I do in other languages.

fabrice_d• 9 years ago

Running `cargo tree -d` helps with checking if you have multiple versions of a dependency and where they come from.

You can install it with `cargo install cargo-tree`

LambdaComplex• 9 years ago

The problems I have while coding in Rust don't even exist in other languages.

Yes, Rust probably requires more thinking to program in than C. But C's hard-to-troubleshoot runtime segfaults become hard compiler errors (with line numbers and useful error messages!) in Rust. Trust me, I've had plenty of fights with the borrow checker. But, once I finally get it to compile successfully, I know that my program isn't going to fail at runtime by accessing memory in some invalid/incorrect way.

modeless2• 9 years ago

This is true and I love this about Rust. However from a pragmatic point of view, I'm definitely spending a lot more time wrestling with the type system than I ever spent debugging memory errors in C. Overall I am less productive. As I said that may change, but I am not certain that it will.

To me the benefit of Rust's type strictness is not productivity, but security. I would not write any network-facing code in C today. I would choose Rust over C even with the productivity hit. But other languages, such as Go, might be a better choice if productivity is higher.

piaste• 9 years ago

This is more of a missing feature, but type inference is a huge part of Rust, and it's often difficult to know what type the type inference engine has chosen for parts of your code. There's no way to find out using RLS in VSCode that I've seen, or go to the definition of inferred types, etc.

VS Code has a 'code lens' feature that allows extensions to display annotations above each lines of code - you can see it in action if you install e.g. the Git Blame extension.

Some language plugins use that feature to display inferred types; the Rust plugin could do the same.

farnsworth• 9 years ago

With TS/JS, it will show this when you hover the cursor over the variable (or invoke it with a keyboard shortcut)

jackmott• 9 years ago

the plugin seems to do it sometimes. definitely a useful feature when learning. can do codelens too so you don't have yo hover. would be a nice option.

yorwba• 9 years ago

there is no compiler warning when you mix up traits coming from different versions of a crate. You just get impossible-seeming errors.

There is a check when error messages are generated to detect messages like "expected X, got X" and add a warning that you might be mixing different versions of the same crate.

There are probably some cases that slip through, but if you file an issue with your specific example or look into the compiler yourself, you might get it fixed (my one patch in rustc handles "a::b::X" being reexported and accessed as "a::X").

EugeneOZ2• 9 years ago

I have been using this for a few weeks
In general, Rust is hard

It's only in first weeks. Soon you will use borrow checker and lifetimes rules without any thinking, you will just do it automatically.

CSDude• 9 years ago

I tried it, it works really nice. If you are looking for an alternative, the Intellij IDEA works very well when you install Rust plugin.

saghm5• 9 years ago

I've recently switched to using Intellij for my Rust coding, and it's been phenomenal. I'm not usually much of an IDE person, but the experience has sold me enough on Jetbrains IDEs that I picked Gogland for my editor for the Go code I'm starting to do at work now, and I've been very pleased with it.

Dowwie• 9 years ago

Is anyone working on support in Atom?

saghm5• 9 years ago

From looking at the README in Atom's languageclient (the editor side of the language server protocol), it doesn't look like there's a dedicated Rust plugin yet[1], although I'd like to think that there would be some way to use it without needing a dedicated plugin given that it's the whole point of the language server protocol.

[1] https://github.com/atom/atom-languageclient#available-packag...

RussianCow• 9 years ago

Does this support macro expansion of any kind? I'm currently using the plugin for IntelliJ IDEA, and it works really well aside from completely lacking support for macros, which makes its type annotations and similar features nearly useless for the project I'm working on.

muizelaar2• 9 years ago

It does support macro expansion for some things. i.e. all of the type information is gathered post macro expansion.

saghm5• 9 years ago

At least the last time I tried it, RLS wasn't able to handle inference for values coming from macros (e.g. completing methods on a variable initialized with `vec![...]`. None of the Rust tooling/editors I've tried thus far have been able to handle that, so I'm hoping that either RLS or Intellij's Rust plugin add it soon.

muizelaar2• 9 years ago

I'm not sure when you last tried, but IntelliJ Rust handles completing methods on a variable initialized with vec![] for me just fine.

ericfrederich• 9 years ago

Slashdot was running this story:

http://cc.bingj.com/cache.aspx?d=1462716999241&mkt=de-DE&set...

bennofs• 9 years ago

That does sound like a bad UI though. Perhaps vscode could stage the files before, so that they end up in Git's objects at least? Or somehow store them in the reflog

Mad_Mac• 9 years ago

It's pretty bad UI design, but pressing the discard button does open a confirmation box that says "Are you sure you want to discard ALL changes? This is IRREVERSIBLE!"

With that kind of a message, it's amazing how he didn't think twice about discarding them. Especially when he didn't have a proper source control before.

threatofrain• 9 years ago

If I'm reading the situation correctly, Git was also involved in the problem.

This person seemed to have his project under Git version control... but he hadn't committed for 3 months, which implies he viewed Git as an inconvenience at best. Perhaps the company is just passing around some project scaffolding?

Any other GUI over your version control software is going to have the option to discard recent changes. Discarding changes sounds like a potentially damaging thing, so it makes sense that you'd want to gate it with a warning dialogue. But they did gate it, and if files are deleted in the process, they do say DELETED in caps, and then they gate you again with another popup by saying IRREVERSIBLE in caps.

Adding a third popup gate would be excessive.

kbenson• 9 years ago

LOL. I mean, it sucks to be that guy, but you have to consider that a project editor has the possibility to overwrite your files with gibberish at any time. I would never load some new software that was supposed to manage a project on my project of 5000 files without having a real good backup first. The same way if I was a video editor and was switching to new video editing software, I would make sure to have a good copy of the originals as well as the work up to that point saved so that I could recover any unexpected weirdness of the new software.

None of that helps this guy. I understand that. Maybe Visual Studio Code could have worded it better. This guy played fast and loose with the safety and integrity of his work and he was bit by it. I do feel for him, but more in the way I feel for anyone that does a stupid thing they should have thought more about first, but this is more a problem of him not understanding what he was doing and the category of software he was giving control of all of his files to. If you plugged your weirdly formatted USB drive (but usable by your other systems) into a computer and it said "We can't read this! Should we reformat?" you probably shouldn't click yes if you don't have backups of what was on that USB drive.

EugeneOZ2• 9 years ago

but you have to consider that a project editor has the possibility to overwrite your files with gibberish at any time

You really need to use other editors if you think so. Removing 15k files without any warning is a pretty lame move from editor developers.

outside1234• 9 years ago

This reminds me of when I was 12 years old, learning to program in BASIC, and my probably 15th program was drawing a star on the screen in ASCII.

I named it *.bas, which the interpreter actually ran despite that being a terrible name for anything.

Yeah, I lost all of the other programs in the directory.

Use backups and source control. Sometimes you need to learn things the hard way, but this one, take it from us. :)

caconym_• 9 years ago

Honestly if you have three months of work not in version control and not backed up and you're willing to click a button labeled "discard" anywhere near your files without taking any precautions then you have only yourself to blame.

Also, I feel bad saying it, but I haven't laughed this hard in a while.

KenoFischer• 9 years ago

I haven't had the chance to try the Rust language mode, but I've been using VS Code for all my julia development lately, and I'm pretty impressed. It's quite a nice editor. I avoided using it for a very long time because I thought it'd match Atom's slowness due to their shared Electron heritage. But for some reason VS Code feels a lot snappier. Not quite Sublime levels, but perfectly usable.

look_lookatme• 9 years ago

[Hijacking to talk about VS Code in general]

Moved to VS Code last week. Coming from JetBrains products, the performance is wonderful. On the other hand the quality of language plugins varies quite a bit, though I've gotten the debuggers and jump to definition to work in PHP and Python. Oddly go to definition can be janky in Javascript [1].

There's also a very nice plugin called vscode-journal [2] that works great for quick logging tasks and notes.

Compared to the JetBrains products I am not a fan of the Git interface, but I think Atom shining in this respect could motivate VS Code to provide a more coherent SCM interface.

I am happy to be back to one-editor-to-rule-them-all. For years I used Emacs, but after using the JetBrains language specific IDEs with quality debuggers built in, I gravitated to them. VS Code seems to strike a fine middle ground.

[1] https://github.com/Microsoft/vscode/issues/19942 [2] https://github.com/pajoma/vscode-journal

Amezarak2• 9 years ago

Just curious, what are you system specs?

I like VS Code and I've been using it for Rust projects, but I have lots of intermittent UI jankiness, where I will start typing and nothing will happen for up to a second or two. In addition UI operations in general are perceptibly (though not to me annoyingly) slower than a native application. It's not all the fault of extensions: all I had installed was Hg and the Rust extensions, and though the latter, particularly with RLS mode enabled, did make things worse, the problem's still there without them.

To be fair, it's an older laptop (Core 2 Duo), but it has absolutely zero problem running Sublime or even full-on Visual Studio, and to me it's a little disappointing.

tomc1985• 9 years ago

I would love Rust support in Visual Studio proper...

steveklabnik• 9 years ago

There is syntax highlighting, but that's it so far.

demarq2• 9 years ago

Autofix doesn't seem to trigger for me, would someone confirm it's not just me?

try this in your editor

    let x = 4;
    if x = 5 {}

it should figure out you wanted x == 5.

nrc• 9 years ago

This should work (it's my goto test case). You have to put the cursor in the erroring code to see the possible fix icon in the margin. If you don't see it please file an issue with the project you're trying this in and I'll investigate.

demarq2• 9 years ago

my bad, in a new project it works just fine. I'll keep investigating.

int_19h3• 9 years ago

It looks like code completion is extremely basic. I tried this:

    struct Point { x: i32, y: i32 }

    fn main() {
        println!("Hello, world!");

        let pt = Point { x: 1, y: 2 };
        println!("{} {}", pt.x, pt.y);

        let v = vec![ pt ];
        let vpt = &v[0];
        println!("{} {}", vpt.x, vpt.y);
    }

And I can't get any dot-completions on vpt (but I can on pt). Which is also kinda weird, because if I hover over vpt, it does know that it is a &Point...

Even more weird is that if I add a type declaration to "let vpt" (specifying the same type that would be inferred), then completion works.

That sounds like a really basic scenario... I mean, type inference for locals is pervasive in Rust.

saghm5• 9 years ago

I can't get any dot-completions on vpt Even more weird is that if I add a type declaration to "let vpt" (specifying the same type that would be inferred), then completion works

I'm fairly certain the reason for this is that RLS (and every other Rust editor/tool I've tried) isn't able to handle completions for things coming from macros (transitively or otherwise). Although the prevalence of the `vec!` macro might make it seem like the completion is "extremely basic", variables coming from macros are pretty much the only case I've found that RLS can't completely properly for. If you manually write the code that the macro would produce (i.e. `{ let mut temp = Vec::new(); temp.push(pt); temp }`, I think it should work fine.

tomjakubowski• 9 years ago

It might also help to manually annotate the type of the binding being assigned to.

            let v: Vec<i32> = vec![ pt ];
            let vpt = &v[0];

int_19h3• 9 years ago

It's not an issue with vec! - the same problem occurs if I use Vector::new and push. It seems to be a problem with the vector itself, or perhaps indexing.

Besides, it does know the type of vpt in code snippet above - like I said, when I hover about it, it correctly tells me that it's &Point. So it clearly can handle macros, or at least vec! specifically.

jussij• 9 years ago

I suspect this is an issue with Racer, the tool that provides the completion information.

rl3• 9 years ago

Anyone here writing Rust on Windows and using WSL (Windows Subsystem for Linux) in your workflow?

I've found using WSL's "bash -c" from my Rust project's working directory in Windows to be a rather elegant way to compile and run code for a Linux target.

Theoretically it should be possible to remote debug Linux binaries in WSL from an editor in Windows, but I haven't had time to explore this yet. Both GDB and LLDB have remote debugging functionality.

TheCoreh2• 9 years ago

It is possible from Visual Studio: https://www.hanselman.com/blog/WritingAndDebuggingLinuxCAppl...

alkonaut• 9 years ago

The vscode rust support is progressing nicely and if vscode is already your go-to editor it's the obvious choice.

However if you just want to dip your toes and get going with rust with minimal fuss, I find IntelliJ community+Rust to be the best combo. Vscode+Rust is not as polished yet.

Try Out Rust IDE Support in Visual Studio Code

Related Stories