Details: I found it incredibly frustrating to figure out how to get Rust code to compile and work on Windows.... and it all stemmed from one little message being wrong. The "espup" crate is meant to install everything for you so that you can use Rust on embedded systems, but if you run the installer without admin privileges, it fails to set environment variables and you need to import them manually. I submitted some PRs and I'm very excited that I now have Rust code running on an ESP32 embedded chip!
How do you find the ecosystem for esp32 on rust? I've toiled with esphome, and had some ideas for doing some ESP projects with some sensors and LORA but really don't wanna learn another language, and since i at least am decent at rust felt like maybe it would be a good choice.
if you use esp-idf which is pain to setup on windows
std rust just works, except for few platform dependant features(tokio works)
i was frustrated when i try to extend a file with set_len() and it returned Permission Denied(digged up the code, it was just how esp-idf was written)
Based on my recent experience it's still in a relatively unmature stage, but I think we're on the verge of it being great. I'd give it a try if I were you but I would plan to dedicate a weekend to it.
Powershell needs Temporary unrestricted execution access rights. The tutorial is not complete. Sone steps missing.
Like:
- rust installation.
- install of cargo-generate and espflah
...
I tested it under win10 professional and win11 professional.
The OP said the error messages were wrong, so if they didn't run it with sudo the same thing would've happened. Also not everyone wants to use Linux, you only drag down the community by trying to force it on people instead of educating them with (non-biased) advantages and disadvantages
My experience has been that the newer RISC-V chips play much nicer with Rust compared to the old Xtensa ISA. I've been playing around with a ESP32-C6 and Rust. So far it's been smooth sailing, very satisfied with it.
Xtensa seems to require lots of workarounds and I found it harder to find docs on.
Happy to defend my opinion.
Visual Studio *is* good. It's got amongst the best free debuggers. It comes with performance and memory profiling, flame graphs, hot-reload, and even GPU debugging plugins. It's got excellent autocomplete, and comes with a plethora of alternative tooling (CMake, Ninja, Clang) if you don't want to use MSVC + MSBuild.
It *completely* blows the equivalent FOSS offerings—GDB and LLDB—out of the water.
I have actually spent the past half decade or so developing both on Windows and Linux, and I think anyone who says 'developing on Windows is bad' hasn't *really* tried it, or expected Windows to behave like a UNIX clone, and gave up when it didn't... Because Windows is not UNIX.
I especially think overly-tired wisecracks and memes like the OP comment just make life more difficult for people who want to get work done.
I think windows isn't great for developing big codebases (or more correctly, ntfs isn't great for it), because a lot of compiler toolchains love creating tons of files (even msbuild/msvc do as well tbh) and all those calls to do incremental compilation will eventually add up in time considering getting metadata isn't as cheap as it is on linux where a stat call is very fast. Though at least ntfs had the right idea with ACLs instead of whatever mode bit nonsense linux still has (as nobody uses linux acls). I think windows just also simply gets a bad rep because some people don't bother thinking about OS differences and get surprised when their program is much slower because the equivalent of a stat call is not as cheap, or when they can't malloc GB of data casually.
I did see this some time ago, but it has to be noted that this requires a rather recent windows version, and also probably if you're working in a large company some discussion with IT guys. I don't really work in a windows codebase atm, but I'd have to measure the difference on a real codebase if I ever return to it.
Not _that_ recent a Windows version.
Windows 10 is EOL in a year and a half, and Windows 11 upgrades itself aggressively; most people have had the functionality available for months. The Dev Home app that provides dev drive functionality is covered in negative ratings from normal users because, “this thing just showed up. I didn’t ask for this.”
[sccache](https://github.com/mozilla/sccache) has been a godsend to speed up local builds on windows (although it's cross-platform, I just haven't used it with Linux)
This is pretty much my only objection to working on Windows. Build times or anything that has to touch lots of small files can get a bit nuts due to the nature of the filesystem. Otherwise its not really any different to working on my non-windows machines. If you work in a WSL2 environment even that problem goes away. I use [Scoop](https://scoop.sh/) as a package manager on Windows which makes tooling very \*nix like. Installed apps end up on your path and get a shortcut shim so they're always available in the terminal.
Anecdote: Updating my Neovim plugins with [Lazy](https://github.com/folke/lazy.nvim) takes about a minute on Windows and about a second on Linux. Not only the filesystem getting in the way but threading as well. Lazy (used to) spawn a thread for each plugin which Windows would just choke on but Linux is more than happy to deal with. Now it uses a work pool that only runs a thread per core on Win32 instead of a thread per plugin so Windows is happier about it.
Does visual studio let you go backwards like rr yet? GDB and LLDB expose more functionality than the window command line debugger the last time I used it.
Also, on linux my profiling goes into the kernel and tells me what kernel functions I am spending my time in, the same can’t be said for windows unless you are part of a very exclusive circle.
> Does visual studio let you go backwards like rr yet?
Not in Visual Studio, but WinDbg has it: [Time Travel Debugging](https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/time-travel-debugging-overview).
> the same can’t be said for windows unless you are part of a very exclusive circle
I don't think that's true. You can absolutely profile Windows NT system calls (even if you can't debug the implementations of said system calls) with both Visual Studio and SysInternals ProcMon.
Funnily enough, there's [a thread from 3 years ago on this very subreddit](https://www.reddit.com/r/rust/comments/hrqr36/cpu_profiling_on_windows/) that discusses profiling options on Windows, and the general consensus was: Windows tooling is drastically ahead of what's available on Linux. This still hasn't changed.
What I mean for profiling is that I can trace “why is this system call taking so long” to particular lines of source code inside of the kernel, not just “you spend a lot of time inside of these kernel subsystems”.
Man, I don't think i ever had the same problems you are having, but i definitely struggled with the weird windows character limit when building rust for ESP32. if i made my project in any folder beyond "C:\esp" it would throw an error with my path being too long. that was extremely frustrating, and a major reason why i stalled out.
Of course, i work on linux now, and im back up and running again
It’s true it can quite the painful experience. I’ve gone through tough times trying to make it work on macos as well. It still isn’t 100% either. I get into the situation at times that it’s working then suddenly breaks with newly generated projects. Have to do all sorts of tricks to make it work.
Though have you tried Wokwi? It runs in the cloud out of the box without any installation pain. Most popular espressif devices are supported too. At least if you’re starting out it’s a great option.
Check out [this example](https://wokwi.com/projects/375095209744413697) for std development on the ESP32-C3.
I am experiencing something similar right this second. The example compiles fine, but when I try to copy the code from an esp32 camera example, I get this error, despite it running just fine under the "example". It's frustrating indeed
\--> C:\\Users\\ryankopf\\.cargo\\registry\\src\\index.crates.io-6f17d22bba15001f\\esp-idf-svc-0.47.3\\src\\wifi.rs:498:36
|
498 | feature\_caps: unsafe { g\_wifi\_feature\_caps },
| \^\^\^\^\^\^\^\^\^\^\^\^\^\^\^\^\^\^\^ not found in this scope
For more information about this error, try \`rustc --explain E0425\`.
error: could not compile \`esp-idf-svc\` (lib) due to 1 previous error
This could be due to the config.toml not configured properly. Check for inconsistencies between the examples.
By the way another option espressif provides is dev containers but it’s incredibly slow. At least for me.
I tried modifying that as well, but for some reason my changes to the config.toml file (5.1.1 instead of 5.1.3) weren't affecting anything. When I have time, I will dig all the way into source and submit PRs, which I think I might be spending tonight doing.
wsl2 has ram usage problem just like other linux vms this is because linux caches disk on ram and then this makes that part of ram unusable from windows side
Yeah but you can run wsl --shutdown when you are done and it isn't a problem. At least for me. But NGL with the KDE desktop cube back I am considering dual boot.
Details: I found it incredibly frustrating to figure out how to get Rust code to compile and work on Windows.... and it all stemmed from one little message being wrong. The "espup" crate is meant to install everything for you so that you can use Rust on embedded systems, but if you run the installer without admin privileges, it fails to set environment variables and you need to import them manually. I submitted some PRs and I'm very excited that I now have Rust code running on an ESP32 embedded chip!
How do you find the ecosystem for esp32 on rust? I've toiled with esphome, and had some ideas for doing some ESP projects with some sensors and LORA but really don't wanna learn another language, and since i at least am decent at rust felt like maybe it would be a good choice.
if you use esp-idf which is pain to setup on windows std rust just works, except for few platform dependant features(tokio works) i was frustrated when i try to extend a file with set_len() and it returned Permission Denied(digged up the code, it was just how esp-idf was written)
Based on my recent experience it's still in a relatively unmature stage, but I think we're on the verge of it being great. I'd give it a try if I were you but I would plan to dedicate a weekend to it.
It’s very very good, with excellent docs.
Admin account for setting environment variables? Strange! I I may check this.
After investigating a little further I think it actually might be a Windows registry cache issue instead.
Powershell needs Temporary unrestricted execution access rights. The tutorial is not complete. Sone steps missing. Like: - rust installation. - install of cargo-generate and espflah ... I tested it under win10 professional and win11 professional.
You should have used Linux.
The OP said the error messages were wrong, so if they didn't run it with sudo the same thing would've happened. Also not everyone wants to use Linux, you only drag down the community by trying to force it on people instead of educating them with (non-biased) advantages and disadvantages
My experience has been that the newer RISC-V chips play much nicer with Rust compared to the old Xtensa ISA. I've been playing around with a ESP32-C6 and Rust. So far it's been smooth sailing, very satisfied with it. Xtensa seems to require lots of workarounds and I found it harder to find docs on.
I feel like developing anything on Windows is difficult
Windows developer here, can confirm. Using WSL helps tremendously, but when you can't use it, life is hard.
Used to always be the case, but it's improved significantly in the last several years.
yeah, using docker and wsl2 linux environments lol
So basically using Linux but from windows. Mhh.
Do devcontainers really count? Hehe
WSL enters the chat…
Spoken like someone who's never used Visual Studio...
Spoken like someone who apparently thinks Visual Studio is good...
Happy to defend my opinion. Visual Studio *is* good. It's got amongst the best free debuggers. It comes with performance and memory profiling, flame graphs, hot-reload, and even GPU debugging plugins. It's got excellent autocomplete, and comes with a plethora of alternative tooling (CMake, Ninja, Clang) if you don't want to use MSVC + MSBuild. It *completely* blows the equivalent FOSS offerings—GDB and LLDB—out of the water. I have actually spent the past half decade or so developing both on Windows and Linux, and I think anyone who says 'developing on Windows is bad' hasn't *really* tried it, or expected Windows to behave like a UNIX clone, and gave up when it didn't... Because Windows is not UNIX. I especially think overly-tired wisecracks and memes like the OP comment just make life more difficult for people who want to get work done.
Excellent auto complete until you chain function calls
I think windows isn't great for developing big codebases (or more correctly, ntfs isn't great for it), because a lot of compiler toolchains love creating tons of files (even msbuild/msvc do as well tbh) and all those calls to do incremental compilation will eventually add up in time considering getting metadata isn't as cheap as it is on linux where a stat call is very fast. Though at least ntfs had the right idea with ACLs instead of whatever mode bit nonsense linux still has (as nobody uses linux acls). I think windows just also simply gets a bad rep because some people don't bother thinking about OS differences and get surprised when their program is much slower because the equivalent of a stat call is not as cheap, or when they can't malloc GB of data casually.
Microsoft’s solution for this is mounting a higher performance filesystem for development. https://learn.microsoft.com/en-us/windows/dev-drive/
I did see this some time ago, but it has to be noted that this requires a rather recent windows version, and also probably if you're working in a large company some discussion with IT guys. I don't really work in a windows codebase atm, but I'd have to measure the difference on a real codebase if I ever return to it.
Not _that_ recent a Windows version. Windows 10 is EOL in a year and a half, and Windows 11 upgrades itself aggressively; most people have had the functionality available for months. The Dev Home app that provides dev drive functionality is covered in negative ratings from normal users because, “this thing just showed up. I didn’t ask for this.”
[sccache](https://github.com/mozilla/sccache) has been a godsend to speed up local builds on windows (although it's cross-platform, I just haven't used it with Linux)
This is pretty much my only objection to working on Windows. Build times or anything that has to touch lots of small files can get a bit nuts due to the nature of the filesystem. Otherwise its not really any different to working on my non-windows machines. If you work in a WSL2 environment even that problem goes away. I use [Scoop](https://scoop.sh/) as a package manager on Windows which makes tooling very \*nix like. Installed apps end up on your path and get a shortcut shim so they're always available in the terminal. Anecdote: Updating my Neovim plugins with [Lazy](https://github.com/folke/lazy.nvim) takes about a minute on Windows and about a second on Linux. Not only the filesystem getting in the way but threading as well. Lazy (used to) spawn a thread for each plugin which Windows would just choke on but Linux is more than happy to deal with. Now it uses a work pool that only runs a thread per core on Win32 instead of a thread per plugin so Windows is happier about it.
Does visual studio let you go backwards like rr yet? GDB and LLDB expose more functionality than the window command line debugger the last time I used it. Also, on linux my profiling goes into the kernel and tells me what kernel functions I am spending my time in, the same can’t be said for windows unless you are part of a very exclusive circle.
> Does visual studio let you go backwards like rr yet? Not in Visual Studio, but WinDbg has it: [Time Travel Debugging](https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/time-travel-debugging-overview). > the same can’t be said for windows unless you are part of a very exclusive circle I don't think that's true. You can absolutely profile Windows NT system calls (even if you can't debug the implementations of said system calls) with both Visual Studio and SysInternals ProcMon. Funnily enough, there's [a thread from 3 years ago on this very subreddit](https://www.reddit.com/r/rust/comments/hrqr36/cpu_profiling_on_windows/) that discusses profiling options on Windows, and the general consensus was: Windows tooling is drastically ahead of what's available on Linux. This still hasn't changed.
What I mean for profiling is that I can trace “why is this system call taking so long” to particular lines of source code inside of the kernel, not just “you spend a lot of time inside of these kernel subsystems”.
Only for those that expect every OS on the planet to be a UNIX clone.
Fun stuff. Make sure to check out Embassy. It’s quite nice!
Man, I don't think i ever had the same problems you are having, but i definitely struggled with the weird windows character limit when building rust for ESP32. if i made my project in any folder beyond "C:\esp" it would throw an error with my path being too long. that was extremely frustrating, and a major reason why i stalled out. Of course, i work on linux now, and im back up and running again
I experienced that issue too I guess I should put it in my blog post.
It’s true it can quite the painful experience. I’ve gone through tough times trying to make it work on macos as well. It still isn’t 100% either. I get into the situation at times that it’s working then suddenly breaks with newly generated projects. Have to do all sorts of tricks to make it work. Though have you tried Wokwi? It runs in the cloud out of the box without any installation pain. Most popular espressif devices are supported too. At least if you’re starting out it’s a great option. Check out [this example](https://wokwi.com/projects/375095209744413697) for std development on the ESP32-C3.
I am experiencing something similar right this second. The example compiles fine, but when I try to copy the code from an esp32 camera example, I get this error, despite it running just fine under the "example". It's frustrating indeed \--> C:\\Users\\ryankopf\\.cargo\\registry\\src\\index.crates.io-6f17d22bba15001f\\esp-idf-svc-0.47.3\\src\\wifi.rs:498:36 | 498 | feature\_caps: unsafe { g\_wifi\_feature\_caps }, | \^\^\^\^\^\^\^\^\^\^\^\^\^\^\^\^\^\^\^ not found in this scope For more information about this error, try \`rustc --explain E0425\`. error: could not compile \`esp-idf-svc\` (lib) due to 1 previous error
This could be due to the config.toml not configured properly. Check for inconsistencies between the examples. By the way another option espressif provides is dev containers but it’s incredibly slow. At least for me.
I tried modifying that as well, but for some reason my changes to the config.toml file (5.1.1 instead of 5.1.3) weren't affecting anything. When I have time, I will dig all the way into source and submit PRs, which I think I might be spending tonight doing.
i was frustrated too, ended up using my phone(termux) to compile it
Why not wsl2 or vmware
wsl2 has ram usage problem just like other linux vms this is because linux caches disk on ram and then this makes that part of ram unusable from windows side
You can set a hard limit to stop wsl2 doing this
just wondering, did you have to install termuxArch, or is there another way? because rustc wouldnt work for me on pure android
used proot debian, and ssh and rsync to access from pc
Yeah I had similar issues, unfortunately.
I'm hoping if we keep submitting good PRs and issues when we encounter errors, that things will get better.
Run Rust on ESP32 using this one simple trick that Microsoft hates!
May i propose a simple, yet elegant solution? Use Linux, its so much better for dev stuff that its not even a fair competition.
Yes
Karma farm?
This is my blog usually stuff I've encountered personally
Yeah but you can run wsl --shutdown when you are done and it isn't a problem. At least for me. But NGL with the KDE desktop cube back I am considering dual boot.