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.
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 :(
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.
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?
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)
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
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.
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.
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.
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.
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.
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?
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 ^_^
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.
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.
(Note that 15.0 == VS2017, not VS2015)