Using Rust in Windows | Hacker News Reader

Using Rust in Windows

jonathanturner.org

164 pointsmiqkt60 comments

Also, if using VS2017, you may also have to set the env var `VisualStudioVersion` to `15.0` to get some cmake-using crates (libssh2-sys, etc) to build. See https://github.com/alexcrichton/cmake-rs/pull/16#issuecommen...

(Note that 15.0 == VS2017, not VS2015)

Or run Cargo from the VS 2017 developer command prompt

I recently switched to using Windows full-time. It started off using the Linux subsystem, but then I accidentally trashed it. So I'm now using native Windows. Powershell is surprisingly easy to adapt to, and while I still use vim often, I've been enjoying occasional use of VS: Code.

Most stuff Just Works, but there are still some rough edges. A lot of them are simply "I'm not used to the Windows Way" yet instead of Rust problems, though.

How did you manage to trash the WSL? I'm not suggesting that it's hard to do or anything, just genuinely curious.

I decided to try using VS: Code (which was installed under Windows) to work on my projects. Opening a file ends up trashing it entirely. This is actually expected behavior; I just wasn't aware :(

What? Files get trashed by just opening them? This is supposed to be expected behaviour?

Yes. Native windows doesn't know how to read the filesystem, so it totally screws up the metadata.

It's actually kinda hard to even do; the files are hidden by default, so you have to really go snooping to do this.

Linux -> Windows works just fine. Windows -> Linux, not so much.

For what it's worth, `lxrun /uninstall /y /full` followed by `lxrun /install /y` will put the WSL environment back to "factory settings".

Then as long as you don't try to look into the WSL side from Windows you'll be fine.

Totally. I just decided it was a good opportunity to actually move to Windows for real :)

Thanks. I made a complementary guide to use the visual studio build tools 2017. http://lustysociety.org/programming/how_to_rust_language_vis...

It's way too hard to get anything that requires OpenSSL to work, I decided not to write Rust code on my windows PC because of that. I remember the process of just getting it to work as really painful and time consuming. Other than that I really enjoy writing rust code on my Linux machine.

Fwiw, native-tls [0] is intended to solve this problem for the set of uses involving TLS (e.g. hyper [1], reqwest) by using the defacto standard on the platform you're on. This means no openssl is necessary on Windows.

Longer term, I would like to see some way for a crate consumer to optionally replace openssl with ring [2] where possible. But that's a harder problem, figuring out a common interface, specifying two crates satisfy that interface and are swappable by cargo...classic package management problems really.

[0] https://github.com/sfackler/rust-native-tls

[1] https://docs.rs/hyper-native-tls/0.2.2/hyper_native_tls/

[2] https://github.com/briansmith/ring

Rustls[1] is a work in progress to build a TLSv1.3 Server in 100% safe Rust. Uses Ring for crypto.

It could use more contributors/eyes/auditors. It works out of the box on Windows currently.

[1] https://github.com/ctz/rustls

Considering the fact that Windows has it's own SSL API and most apps don't use OpenSSL - any reason you're not using the native stack?

Oh god yes. This is one of the reasons i switched back to Go. I wanted simple cross compiling, it was really important to me, and OpenSSL is just too commonly needed to run into problems for me.

This confuses me a bit, but I honestly have not spent a ton of time with Go, so perhaps you can explain. How exactly do you get simple cross compiling with OpenSSL using Go? Once you use an external library don't you lose all of Go's cross compiling simplicity?

In my understanding, in the usual case, you don't use OpenSSL. You use https://golang.org/pkg/crypto/tls/.

Yup, as Steve mentions, it's builtin. So in short, it's never even on my radar.

I really like Rust, but compiling OpenSSL was a huge headache for me. One of those growing pains i felt like.

FWIW I never bothered to compile OpenSSL; I just installed it and link to it.

Can't wait until we can just use ring everywhere, though.

+1 to the openssl problems.

For me it was only stopping my investigations into hyper and other web stuff (on windows), just writing CLI and GUI apps works fine on Windows. (I use VS Code and a git bash)

For what it's worth, to anyone who may encounter problems with OpenSSL, I long ago tried my best to write up clear instructions for someone who was having trouble: https://github.com/Thinkofname/steven/pull/60#issuecomment-2...

It's a bit out of date, but I think it should help navigate the setup.

You can also just use it on Bash on Ubuntu on Windows.

Then you can't deploy to end users on Windows.

Visual Studio Code has a pretty decent Rust extension: https://marketplace.visualstudio.com/items?itemName=kalitaal...

Note that this is the up-to-date fork of the older "RustyCode" extension.

Does is also work with the Free-Software MinGW toolchain?

That would make it possible to generate Windows binaries without having to run a Windows VM, through cross-compiling, using e.g. MXE: http://mxe.cc/

It does. It supports mingw on windows as well as cross-compiling from linux using cargo (rust's package manager and build tool). Installing mingw-w64 from my distribution's package manager and telling cargo where to find its linker and assembler was all I needed to cross compile stand alone windows binaries of some command line tools I wrote.

Been working with Rust on Windows for almost a year now.

My go-to is VSCode + Rust plugin. You get the same debugging as VS2015 via C++ plugin(they both use the same backend). Only time I need to drop over to MSVC is if I need data breakpoints or look at disassembly(usually when I'm dealing with a C library that's misbehaving).

VSCode rust plugin gets you racer, rustfmt and a bunch of other goodies(cargo test/check right in the IDE).

Have you found any good resource on setting up the debugger for rust in VSCode? I've been having issues getting this running smoothly and have found very little support online

I am literally fighting with this right now. LLDB is not a happy camper.

Yeah, MSVC target tends to work much better(although viewing of some more complex types doesn't work yet).

I'm using the MSVC build of Rust. That doesn't preclude using lldb as a debugger.

Yeah, I meant MSVC debug backend.

What's the situation with using the Windows API from Rust? Are you down at the Win32 API level, or can you even do that?

Winapi-rs [1] is the de-facto binding for the Windows API and covers a lot of them (but not yet complete). I don't see a significant project for higher-level bindings.

[1] https://github.com/retep998/winapi-rs/

There's also the winrt crate for getting at uwp apis.

https://github.com/contextfree/winrt-rust

I should really find some time to upgrade to VS2017, my understanding is it's a bit faster than VS2015, not just the install. Can anyone comment on this, I always found VS to be a beast, even on an SSD, HDDs being nearly unbearable.

I really do like VS Code though... looks like there's some work going there.

VS17 has an option to "quick load" projects. It loads up in a jiffy (unlike it's previous versions), but you cannot use some of the IDE features.

I seriously hope they add a lazy load feature in the future.

There's a feature called Lightweight Solution Load [https://docs.microsoft.com/en-us/visualstudio/extensibility/...] which does seem to just lazily load projects.

But even with that turned off, opening large solutions is vastly faster than in VS2015.

Isn't quick load just a rename of lazy load, based on your description?

Nope, apparently quick load doesn't load several IDE features at all. What I mean by lazy load is that it should incrementally load the IDE features after the IDE starts.

Jeez, the obvious optimization would have been to load some of the features first and then load the rest, but to not load them at all? That's not very useful.

Well, as a back-seat commenter I agree with you but they probably had a good reason to not do it. Most likely something to do with development complexity. There's a ton of smart people working on Visual Studio, I'm willing to trust their judgment on this :)

Well, they definitely had good reason, it's just that the feature isn't very useful without the extra work. Although, I don't know exactly how much functionality is missing, so I might be wrong.

Well, it might just be laying the groundwork for lazy loading. They probably thought some people might find it useful even as a "half feature".

Yeah, that seems like the most reasonable explanation. It sounds like the answer was just "deadline".

Instead of VS try out IntelliJ IDEA with Rust plugin: https://intellij-rust.github.io

It gives you the comfort features known from the IntelliJ platform and doesn't add phonehome telemetry to your exe files (like VS2k15).

Have you got a source for the telemetry inside the compiled binary claim?

It was something a specific patch version (of Update 2, iirc) did which was blown way out of proportion. The CRT in that version sent two events on startup and shutdown to the windows event tracing/profiling framework. (Which show up in performance analysis tools like WPA.) People just latched onto the scary name.

To make things even worse (even funnier?), GCC also has something like this, I believe it's this feature: https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.h...

Profiling is not telemetry. Telemetry implies that events are supposed to be transmitted off-site (tele + metry = remote + measuring). Profiling writes a local file with statistics.

http://www.slashdot.org/story/312289

https://www.infoq.com/news/2016/06/visual-cpp-telemetry

Appearently they backed off, due to major outcry. The usual salami tactics.

Nevertheless to this day developers compile binaries with the affected compiler version - still in release builds of various up-to-date software.

Seems you migt want to read this sibling comment:

https://news.ycombinator.com/item?id=13974771

Guy got down-voted for providing an excellent free alternative and mentioned the fact that it linker / libraries indeed does not add crap to your code.

Btw Microsoft representative itself called it telemetry, confirm they added it without any warning, cloud it all in high grade bullshitspeak, while order for removing it in hurry, or just rename/disguise functions "to remove any suspicions" as they do with spying (sorry, complete anonymous telemetry that helps to improve the product) services in Windows 10?

https://www.reddit.com/r/cpp/comments/4ibauu/visual_studio_a...

I personally prefer lxss. While it has some limitations, I am yet to face issues with rust projects. You can also use Intellij-based IDEs with a rust plugin and run `bash` in the command prompt accompanying the IDE. It feels like working on Linux ^_^

Well, because the userland IS Linux (or what people refer to as Linux on the desktop).

But binaries are also ELF binaries and can only be run with lxss. How do you deploy to Windows customers who are not developers?

You dev on linux, try your best to write in a cross-platform way - then only once you've got something that works and you're fairly motivated to actually do something with it, go through the hassle to make a Windows build.

Yep, you're right. I was thinking about it from an easy to set up development environment perspective.

Quick warning about lxss: if you access any of your stuff from a Windows program, it can trash the whole partition.

Source: I'm just using regular old Windows now...

Is VisualRust still active? It seems dead or moving very slowly. I know there's some commits going into the project, but their last release was over a year ago.

Reply on news.ycombinator.com