[tenacious_tuna]

Hiya! Former mac native developer here, moving to a new company. My new corp gave me the option of a thinkpad running windows or a Mac, and I chose the mac just so I could have a sane terminal experience, UNIX-like tools, etc.

I would vastly prefer to use Linux, but unfortunately that's just not an option for a company-issued machine at this juncture--and in my experience it's easier to spin up a VM on a Mac than a Windows box.

Being a Mac native dev, I'm very acutely aware of the pain other devs go through with Apple and their APIs, but unfortunately Macs remain a better platform to write code on in my personal experience.

[fluidcruft]

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.

[lalaithion]

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.

[Izikiel43]

> 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?

[poutrathor]

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.

[rocqua]

Are you using windows git, or linux git inside WSL? The latter seems a lot more reliable in my experience.

[turtlebits]

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.

[WorldMaker]

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.)

[roblabla]

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.

[searchableguy]

> 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.

[WorldMaker]

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.

[Teknoman117]

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.

[DangitBobby]

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.

[tenacious_tuna]

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.

[hundchenkatze]

You should give Windows Subsystem for Linux a try. It's what I'd choose in your scenario.

https://docs.microsoft.com/en-us/windows/dev-environment/ove...

[pimeys]

I'm heavily invested in Linux for years already, a i3+terminal+firefox+emacs guy.

I forced myself to work on Windows 10 Enterprise for a week and left kind of feeling OK about it. It's a bit slower than Linux, a bit too many moving things by default and I definitely prefer the env vars and config files over registry and control panel. But. I didn't use WSL or WSL2. I just had nushell and Microsoft's terminal app, with winget and all that. Some keyboard shortcuts and multiple desktops enabled, writing Rust software with emacs, firefox and a good terminal was not bad at all. I would not dislike working more in there, but in the end find Arch Linux to be the end game OS for me, so keeping the installation just when I need to debug some Windows issues.

[tenacious_tuna]

I actually have been trying this recently! I've been using VS Code via SSH into a WSL2 container running on my windows box and it's been going surprisingly well.... but that was after a moderate amount of effort to get WSL2 working to begin with, which was partially complicated by my past efforts of getting WSL1 to do similar behavior. I'm also not 100% confident NewCorp's IT would be kosher with me spooling that up. I could be wrong, but it seemed easier to go with the lower-number-of-abstractions-to-get-an-acceptable-experience via mac at the time.

Though who knows! Maybe I'll change my mind and get a new machine :)

[searchableguy]

> that was after a moderate amount of effort to get WSL2 working to begin with, which was partially complicated by my past efforts of getting WSL1 to do similar behavior.

Could you explain more?

I know installing and switching to WSL2 isn't as straightforward on windows stable. Is that what you are referring to?

If so, on insider - you can run wsl --install and it will work.

If not running wsl2 by default, wsl --set-default-version 2

I think they could make it easy to onboard users by setting better defaults and decreasing friction.

[tenacious_tuna]

I had to fight with enabling/disabling Hyper-V in windows features for a while, and also somewhere I flashed the BIOS on my motherboard and it reset my virtualization-enable switch to "off" (which I guess was the default?)

50/50 PEBKAC and Windows being difficult, IMO, but my total unfamiliarity with troubleshooting windows made the process a bit more annoying than I felt it ought to be.

[sneak]

There is the other issue that Windows is full of spyware. Most of the mac's telemetry is inadvertent and leaks much less data to the OS vendor.

[fluidcruft]

I would assume any IT-issued devices are full of spyware regardless of OS vendor.

[goatinaboat]

I chose the mac just so I could have a sane terminal experience, UNIX-like tools, etc.

Well, that’s on you. You could have had WSL2 which is amazing.

[pfranz]

While I think WSL is an option worth investigating, it is not the answer for everyone.

I jumped from XP to Windows 10 with WSL1 and had used Linux and macOS in between. It took me a few days to come across a bunch of pain points I was surprised had not changed; I do not like the install/uninstall scatter-shot method, monthly reboots for updates, control panels feel like archeology digging older UIs for settings, the window freezes and I cannot resize/minimize when the app is busy, I do not like Explorer or the windowing UI. PowerShell in practice seemed too verbose for interactive use and the learning curve/adoption was too steep to be productive (everyone else on the small team was writing BAT files). I got tripped up by odd things like offline documentation and you had to wrap it in a BAT file to automate it. I also don't like compiling stuff for Windows. I don't begrudge anyone who likes Windows, but I have a very strong preference for the other OSes. I might have some of those details wrong, but that's what I remember from the transition. I wished I had kept a diary because I forget a lot of it now.

WSL (admittedly v1) was a bit odd and hefty to install. The account/permissions and locations of files was awkward. I found myself ssh-ing into a Linux box to do a lot of things.