Hacker News Reader

Comment by strictnein | Hacker News Reader

The question isn't "Is Windows ...", what he's actually addressing is the question "Is WSL actually ready for developers?"

Windows is. All of his issues either seem to be from WSL, complaints about keyboard shortcuts, or not setting up his monitors properly (his claim that Windows doesn't properly support 4k monitors is a strange one).

To be honest, I don't get why he's installing VS Code on top of WSL, when you have native windows VS Code. This seems completely unnecessary, but maybe I'm missing some benefit?

View on HN

> In a way, managing WSL feels a bit like managing a VM and it is not completely integrated with Windows.

I think the author missed the point of WSL, I can't see any benefit from that

> To be honest, I don't get why he's installing VS Code on top of WSL, when you have native windows VS Code. This seems completely unnecessary, but maybe I'm missing some benefit?

When I develop Python with Visual Studio Code, I run it from a virtual environment. I have auto-formatting enabled, so whenever I save a file, it will automatically be formatted with the formatter which is installed in my virtual environment.

I don't know if the same is possible if your virtual environment is in WSL and your VS Code is in Windows.

There are some integration issues between VS Code on Windows and WSL. (there are currently 29 open issues on Github for this.)

Windows does properly support 4k monitors, I have two connected to my new desktop at home and it's fine.

As is cinnamon, 4K is not exotic technology in 2019 mine where not even that expensive tbh.

If you’ve got flawless eyes, then obviously native 4K is fine.

If you want larger and blur-free text, get a Mac or stick to lower-res screens...

Or do what I did on Linux and set font scaling to 1.5 and not worry about it one moment after.

Eyes aren't perfect either fwiw.

1.5 fonts scaling worked decently on ubuntu 16.04, but needs magic on 18.04 .

And there's no standard hidpi way for applications to work, so ymmv. Some apps won't understand your settings. So you'll tweak some env for them. Then some apps will double recognize your settings.

Well, it Just Works™ on my out-of-box Plasma. The only things I needed to tune manually were git-gui and choosing a hidpi theme in GIMP.

> The only things I needed to tune manually were git-gui and choosing a hidpi theme in GIMP.

So it doesn't just work. It works only for a subset of the applications, those that fall within a certain DE/GUI toolkit.

Yes, it does. This is an equivalent of selecting "compatibility mode" for that one old Windows app you still use.

Also, this is on X11. On Wayland you don't even have to do that, as non-hidpi aware apps get automatically scaled up.

(and amusingly, just yesterday I had an occasion to test it truly out-of-the-box and turns out that things improved over past few years and now both GIMP and git-gui work just fine - and both are rendered in full resolution)

DPI scaling doesn't blur the text unless the app is not compatible with it.

Windows has dpi scaling...

Turn ClearType off

there is zero benefit. windows can now access wsl files. also, you can setup visual studio code to run bash in an integrated terminal and thus call command line application in the wsl. also, using "wsl.exe <name>", you can call a wsl application from cmd or powershell.

But you can't, for example, tell a Windows instance of VS Code to use the WSL Python binary for debugging Python applications. It will run the binary just fine, but it won't know to translate the Windows file paths into WSL ones. So you will just get a file not found error any time you try to use it.

that's not true. i use visual studio code and emacs, both on windows, to develop scheme that runs on wsl (since many schemes don't support windows). in visual studio, i use bash in the integrated terminal which takes care of running the binaries on wsl, and in emacs, i update my user init file to use "wsl.exe scheme" for the scheme application, where "scheme" is in my wsl path. launching a repl works just fine, and it's able to load files without issue.

what path translation are you talking about? if there's an actually a problem with something you've tried, then it is probably a problem with python and not the setup. as i said, i regularly do what i mentioned above with no issues. wsl can see both files local to it and on the windows system.

I didn't say you can't run a REPL in the terminal. Actually I said you can do that. What you can't do is use the VS Code debugger. You also can't: get code autocompletion, linting, automatic refactoring like renaming variables, you can't run files by right clicking and clicking "run", etc.

ahh, sorry. that wasn't clear because i haven't used the python debugger in visual studio code and don't use python in general.

i would guess my hunch that this is a python problem is correct.

i use ionide for f#. i am wondering if i point ionide (if it's possible) to use f# running on ubuntu through wsl, will its type inference, linting, autocompletion, etc. still work?

It's not a python problem. Like I said, when you initiate a debug session, VS code will launch the python binary just fine, but it passes it the Windows path of the file you're debugging which obviously the WSL python binary can not understand. I assume F# on WSL would have the same issue, although I haven't tried personally.

Here you can see a bug report for the issue: https://github.com/Microsoft/vscode-python/issues/67

And the same issue for other languages: https://github.com/Microsoft/vscode/issues/22663 https://github.com/Microsoft/vscode-go/issues/926

Looks like they've implemented fixes for C++ and nodejs though: https://github.com/Microsoft/vscode-cpptools/issues/85#issue... https://github.com/Microsoft/vscode/issues/39144#issuecommen...

Ok, since that's a heading from the article itself, we'll use it for the title above.

Reply on news.ycombinator.com