Hacker News new | ask | show | jobs
by fluidcruft 1987 days ago
My experience is that Windows Subsystem for Linux has been amazing on Windows and just keeps getting better. I've also never noticed any difference in spinning up VMs.

But anyway I get keeping with familiar tools but, I just disagree that MacOS is a better or even "sane" terminal platform. All the ancient GNU tools Mac ships and BSD-style "but Posix!" pedantry drives me up the wall.

5 comments

In my personal experience, git crashes about 1 in 3 commands I run on windows. Haskell takes ~10 times longer to compile on a ~4 year old desktop windows machine than a ~6 year old mac laptop. And I usually spend hours trying to get simple tools installed, vs. minutes on macs.
> git crashes about 1 in 3 commands I run on windows.

I've been using git over 2 years on windows with no issues at all, it seems you have a buggy version?

Definitively a local issue between the chair and the computer.

The whole developers world would be up in arms if Git actually crashed in 1 out of 30 commands on Windows, _whatever the configuration, git bash, powershell, or WSL 1/2_. There would be yearly top hacker news post about "one year and still not fixed"

Heck, Git would not have reached its dominant position if it was such a buggy mess.

Are you using windows git, or linux git inside WSL? The latter seems a lot more reliable in my experience.
I have not used a current version WSL, but it was terrible when I tried it. Could not find files saved in the WSL terminal in explorer (I understand that is a limitation). The was so much unknown going on in the "integration" that I wished I just used a VM and took the perf hit instead of digging to figure out where Windows was mounting the FS and figuring out permissions.

I have no desire to look at WSL ever again.

I experienced the same thing with on F# on mac a year or so ago, the dotnet CLI tool was effectively broken and official onboarding docs didn't work.

I tried revisiting when they announced F# 5 late last year, but same thing, docs don't work/broken on Mac. Turned me off for F# development and leaves me a bad impression on anything Microsoft releases.

WSL2 has fewer "magic unknowns". WSL1 used the NT Kernel emulating the Linux kernel so there was a lot of (seeming) magic in that interop, because it relied on low level NT details that don't look like "normal" Windows to Windows.

The files, for instance, were stored in NTFS but with Linux metadata in alternate data streams. Akin to what macOS used to call Resource Forks, except alternate data streams are far more rare in Windows and most native Windows apps trample over them. Microsoft didn't advertise where to find those files specifically because they didn't want people using Windows apps on those files and breaking Linux metadata. Instead, Microsoft heavily encouraged using /mnt/{drive letter}/normal/windows/path (like /mnt/c/users/me/Documents) and normal Windows paths and keeping files you worked on in both environments in the Windows plain old NTFS without alternate data stream weirdness side (because those /mnt drives didn't use the Linux metadata alternate data streams).

Eventually, Microsoft added a Plan9-based file server to WSL1 serving on the \\wsl$ system path for browsing those files and some smarts around it. (Launching a Windows EXE from a WSL terminal would convert the Linux path to the \\wsl$ path for instance.)

WSL2, on the other hand, is an extremely lightweight (Hyper-V based) VM, uses a real Linux kernel, and generally uses VM tech. Files are stored in a standard VHD, which can be explored with plenty of VM tools (including Windows File Explorer). They are still accessible in File Explorer through the \\wsl$ service. (Though in that case Windows can mount them using standard VHD mounting. The direction of the Plan9-based file server winds up reversed from WSL1 in that it is used instead by the VM to access host machine files through the VM barrier.)

As for F#, F# itself is an open source project with possibly a lot more of a "community project" mentality than it is an "official" Microsoft release. I don't know if that changes your opinion, but it is one of the projects where Microsoft has best embraced open source. (Including some of the potential downsides of open source, like needing Github Issues filed on broken documentation or it will go unnoticed/unfixed.)

You can literally just run 'explorer.exe .' in a wsl1 shell to get an explorer to show up in whatever directory you are currently in. The wsl files are not hidden from windows, and can be edited from there just fine.

F# (and most of Dotnet core) is also a mess on linux, so no surprises here.

> Could not find files saved in the WSL terminal in explorer (I understand that is a limitation). The was so much unknown going on in the "integration" that I wished I just used a VM and took the perf hit instead of digging to figure out where Windows was mounting the FS and figuring out permissions.

You can explore the files stored inside wsl partition by going to \\wsl$ using file manager.

You can now also mount an external drive formatted as ext4 directly.

In very recent versions of Windows 10 WSL will even add directly to File Explorer a shortcut in the usual Locations pane (left-hand panel with quick folders/PC/whatnot) to \\wsl$ with a Tux icon. It's amusing seeing Tux every time you open File Explorer, and possibly even more amusing that Microsoft is installing that shortcut themselves.
Compilation is the bane of my existence on windows. I have a few large cross platform projects (using CMake) I work on (at work), and the builds on Linux are a night and day difference. My 16 core Linux workstation does the build in like 80 seconds, and the same machine booted into Windows takes 15 minutes.
The developer experience on my Mac is IMO vastly superior to that on my Windows machine with WSL because of the complication of configuring IntelliJ products to use environments in WSL. When I use VSCode, the experience is about the same in both machines.
Fair enough! I have run into an annoying number of issues that were because the flags for `cp` varied from mac to other *nix systems, which was very annoying to debug.