|
|
|
|
|
by meddlepal
1914 days ago
|
|
There's definitely a few quirks. My biggest annoyance right now is https://github.com/microsoft/WSL/issues/5762 . Note this only impacts calling the Linux go toolchain from the Windows side (via the /$wsl/ path). Its not an issue inside WSL... but it comes up when you want to say configure Windows IntelliJ/GoLand to use the Go compiler hosted inside of the WSL VM. > When you say "proper Linux distribution", I assume that's still CLI only? Do you develop with e.g. emacs, vim on WSL, or do you have some IDE with remote running and debugging into WSL? Or have a missed a trick and in fact X/Wayland applications can be run on WSL? You can run X apps just fine in WSL2 as long as you have a display server running on the Windows side. I use X410. Important to note, Microsoft is working on native Wayland support long term. For what it is worth, I run IntelliJ/GoLand from inside of WSL and use X410 to render the GUI. This works great. |
|
> I think my end goal is to have a contained development environment whilst not being forced to use specific tools (i.e. VSCode remote debugging, eugh) and not sacrificing compilation times by running in a VM that's too slow.
Are there any other gotchas to working like this? As it happens I'm a go dev using GoLand so your go-specific issues are of interest to me. I'm not too bothered about not being able to use Windows GoLand as I'd be just using it from WSL2 anyway, but I'd be interested to know if there are any other pain points. Any issues with VPNs, if you're using them?