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.
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 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.
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.
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.
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.
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)
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?
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 :(
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.
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
61 comments
[ 4.1 ms ] story [ 127 ms ] thread[1] https://github.com/retep998/winapi-rs/
https://github.com/contextfree/winrt-rust
It gives you the comfort features known from the IntelliJ platform and doesn't add phonehome telemetry to your exe files (like VS2k15).
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.
https://news.ycombinator.com/item?id=13974771
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...
(Note that 15.0 == VS2017, not VS2015)
I really do like VS Code though... looks like there's some work going there.
I seriously hope they add a lazy load feature in the future.
But even with that turned off, opening large solutions is vastly faster than in VS2015.
But binaries are also ELF binaries and can only be run with lxss. How do you deploy to Windows customers who are not developers?
Source: I'm just using regular old Windows now...
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/
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)
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
It could use more contributors/eyes/auditors. It works out of the box on Windows currently.
[1] https://github.com/ctz/rustls
I really like Rust, but compiling OpenSSL was a huge headache for me. One of those growing pains i felt like.
Can't wait until we can just use ring everywhere, though.
It's a bit out of date, but I think it should help navigate the setup.
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.
Then as long as you don't try to look into the WSL side from Windows you'll be fine.
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.
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).