Thanks for posting this. I don’t use Windows as a daily driver, and every couple years it seems I suddenly need to run it and I get lost trying to catch up to what’s good. Oh My Posh looks nice, and powertoys run seems like a decent Rofi replacement.
This is something of a tangent to the main point of your piece, but you mention it in there so I’m going to ask. You like to avoid the mouse. Do you have some kind of tiling setup for Windows that you like, for managing windows using the keyboard similar to i3 or sway? I’ve seen the autohotkey one before, but am wondering if there’s something that integrates a little more easily.
Answering with the tangent: PowerToys also provides a tiling windows tool called FancyZones. It’s not as keyboard-friendly or as automatic as i3 or sway; you define layouts in advance, and can switch a display to use any of those layouts. In the past, though, I’ve used tiling window tools for Windows like bug.n, and (while bug.n was quite good most of the time), they tended to interact in weird ways with the rest of the system. FancyZones seems to be at least better integrated, even if it’s not very dynamic. Amethyst Windows and win3wm are a few new entries I haven’t tried.
But to answer this for my own self, I do not and would not want such because being visually disabled as I am, my eyeballs focus VERY slowly on any given spot on the page, and because of some other neuro-muscular issues my eye also jumps every few seconds so I need to keep the layout aas simple as possible. Windows already provides superlative keyboard controls for “Maximize” which is all I want out of windows and layouts :)
I’ve been following the very recent additions around desktop workspaces with great interest though, since having totally separate purpose built workspaces for various tasks IS something my busted eyeballs can handle and might be a productivity win for me overall.
It sounds like more of the big-name tools are supporting Windows, but the problem isn’t those. It’s all the smaller stuff, all the little libraries you use all the time where Windows is a 3rd-class citizen at best where you’ll get tripped up.
If Python is anything like Ruby there are Ruby gems that required native binaries. Getting ruby gems compiled with mingw gcc was a challenge back in the Windows 7/8 days. WSL came a bit too late for me.
As of 5 years ago or so, the answer would be “Yes it’s a raging tire fire JUST LIKE Ruby”
But there was a call to action among Python educators who wanted to help folks who had zero coding knowledge come up to speed, and BY FAR their biggest pain point was “My students are all running Windows. This tire fire will not do.”
So a TON of people in the community including Guido and lately Microsoft have put a positively enormous (And I’m not exaggerating) amount of effort into making Python drive like a Cadillac under Windows, and they have succeeded admirably which is why I wrote the post.
Note the title citing that 2021 is the year Windows became a TRULY first rate Python development environment. Some of the changes I cite are VERY recent - like Windows Powertoys providing an Alfred analogue and WSL-g which means that pretty much anything you need to build, test or run under Linux will also run on Windows.
The Python 3 conversion had a huge part to play here as well, as there were a bunch of platform / filesystem related issues that became MUCH easier and lower effort to properly code under Python 3.
I’ll probably be flamed to death for this comment, but I tried the Windows and WSL for web development for a grand total of about 2 days before I threw it away and went back to plain linux.
WSL was far slower, and I found the configuration over-complex and completely unintuitive.
First - Do you have disabilities that make accessibility features critical path? If not, then we have very different needs.
Second, was it WSL 1 or WSL 2? There’s a huge difference between them in terms of perf and completeness.
Third and by far most important - no one environment is for everyone. If I had your fully functional eyeballs I would probably be rocking a Linux desktop too and loving it, but I don’t. After spending weeks and weeks reporting the bug, beating the drum, trying to get developer eyeballs, and then finally realizing that the tiny cadre of people with enough understanding to fix the issue simply don’t have time, I realized it was time to give up and recognize that the fully open source promised land is not going to work for me :)
Glad to hear you’ve found a toolset and environment that works for you!
So first let me state that my biggest obstacle and hence my biggest ask is simply this:
I need to be able to actually READ everything - text, UI elements, all of it, with my busted eyerballs.
(Blind in one eye, 20/80 with correction in the good eye)
So, my ideal world ask around this would be an environment where I could choose the scale/size of EVERYTHING. Text, UI widgets, all of it, and where if I DID choose a larger text/UI size all the applications wouldn’t just utterly fail in all kinds of novel ways.
Want to guess how many times I’ve set large text and then had apps put critical bits of content or configuration BELOW the visible page with no scrollbart? You don’t have to guess, the answer is a lot :)
That’s why key chorded full screen zoom is UTTERLY critical for me in the current real world where you can adjust text/font size if you’re lucky and then whether said adjusted size will break your apps is another thing altogether.
In terms of actual “Workflow” my needs are very simple. Mostly, because of my low vision and slow focusing, I pretty much always keep Windows as full screen. So ideally I like to have a bunch of separate “workspaces” each tailored to a task.
Windows does this pretty well, and so does KDE. KDE gets mad props from me for being the ONLY FLOSS desktop that has had real zooming features for many years and never left it broken unlike Gnome.
So all of this is covered by the mechanisms arcan already have, and how the reference DE durden uses them. Everything that is ‘native’ uses Display Density and Preferred Pt size for layouting / positioning, alas non-native clients (so the majority of them) are not as lucky. The inertia, legacy and bias from toolkits spoil much of the fun. Some override toggles may work, e.g. lying “per window” about the display density to force clients to scale rather than post-process zoom, but it is case by case. In my experience, toolkits are slightly more responsive to faked display properties than to listening to reason about font preferences.
If you feel like indulging my curiosity further: how problematic is navigation combined with focus when you have high magnification? From my own use cases, both the ‘pan to center around current cursor’, separate ‘zoom window’ or ‘drag to pan’ are both rather distracting and breaks focus. What has worked better, for me, is:
keybinding for panning around in a zig-zag or button grid for “quadrants”.
cursor-draw/circle-to-zoom or OCR” and then a binding to reset.
an edge detection/edge enhancement post-processing toggle for borders (help with focus).
binding to autopan/zoom to region that had the largest / most recent changes.
zoom to eyetracker gaze point.
I am currently experimenting with adding more text-to-speech on out-of-band signals (e.g. notifications), positional audio mixing of multiple t2s streams to handle more contents (head tracking and HRTFs for more mental “bandwidth”) and image-to-sound like translations.
Windows does this pretty well, and so does KDE. KDE gets mad props from me for being the ONLY FLOSS desktop that has had real zooming features for many years and never left it broken unlike Gnome.
I think the problem these two behemoths are fighting are one and the same; the mechanisms used as building blocks. They are either extremely limited (X+COMPOSE) or fractured and brittle (Wayland) where even a keypress is a full season of “murder, she wrote”. Under those constraints, to get to an ok point (half-way to what apple has in their zoom tools) is a lot of tedious work, and to keep it from breaking is thrice that.
If you feel like indulging my curiosity further: how problematic is navigation combined with focus when you have high magnification? From my own use cases, both the ‘pan to center around current cursor’, separate ‘zoom window’ or ‘drag to pan’ are both rather distracting and breaks focus. What has worked better, for me, is:
keybinding for panning around in a zig-zag or button grid for “quadrants”.
cursor-draw/circle-to-zoom or OCR” and then a binding to reset.
an edge detection/edge enhancement post-processing toggle for borders (help with focus).
binding to autopan/zoom to region that had the largest / most recent changes.
zoom to eyetracker gaze point.
Dunno if you’re still reading this but I totally missed this question in an answer previously :)
The answer is that I don’t generally have a problem with navigation when zoomed, because generally I don’t zoom to such an extent that this problem occurrs, or if it does I just zoom out a bit having already read/parsed/selected the particular problematic text/UI element/whatever.
IMO the edge detection strategy would be the most useful because the one navigation issue I DO Sometimes have when zoomed is that apps don’t always properly detect the zoomed UI elements click zones properly so I have to zoom out, click, zoom back in again etc.
WSL 1 is akin to the FreeBSD Linux ABI layer. This has good and bad points. The good point is that it’s a fully native bit of Windows: it sees the same filesystems, uses the same pipe interfaces (so you can create pipes between Windows and Linux processes and have the same performance as between a pair of Windows or Linux processes), and so on. The down sides are that it uses NTFS via a pile of filter drivers to expose POSIX semantics (which makes FS access slow) and it is always playing catch-up, with some big features not implemented (e.g. seccomp-bpf).
WSL2 is a Linux VM with some tight integration to do things like forward pipes over Hyper-V sockets, expose the host FS as 9p-over-VMBus (which is much slower than WSL1 accessing the host FS, but the Linux-native FS is just a Hyper-V block device formatted with ext4 so is as fast as a normal VM disk). This is 100% compatible with Linux (because it is Linux) but some of the integration has rough edges.
I’m not sure what your issue was with configuration: Install Windows Terminal from the Windows store. Install your favourite distro from the same store. Run the terminal, set your favourite distro as the default profile. Done.
There are bunch of things about configuration.
Profile migration, file permissions,vscode remote server configuration, git client configuration, ssh client configuration and so on.
It’s really cool what the microsoft trying to do, but for professional web development for linux server, plain linux will be always best choice.
As someone who’s partially blind and has fine and gross motor impairment, using the standard Windows Icons Mice and Pointers user interface is downright agonizing. I need to be able to launch apps with just a few keystrokes. On the Mac, Alfred fulfills this role admirably and adds a whole host of next level productivity power ups in addition to keyboard app launching.
Check out AutoHotKey.
I’m serious. AHK is the killer feature of developing on Windows. I have it set up so that pressing numpad2 can launch five different apps and show a list of every app it can launch.
AutoHotkey is great but you basically have to learn the wacky configuration language, and it conflicts with anything else that tries to ‘hook’ the keyboard, so I bounced off.
Lots of power there for sure, but as I mentioned my humble needs are met admirably with the latest PowerToys and its Powertoys Run and Keyboard Remap features.
AutoHotkey is great but you basically have to learn the wacky configuration language
Yeah this one sucks, esp since most users aren’t programmers so all the tutorials aren’t oriented at people who already program.
and it conflicts with anything else that tries to ‘hook’ the keyboard, so I bounced off
I got around this by mapping things to the rightmost modifiers. So leftcontrol+d is normal, while rightcontrol+d is “jot timestamped note”. You can keybind the right control with >^.
Also, modal hotkeys! Any hotkeys defined under #If (expr) are only active if expr is true. So I have
#If (g_mode = "workshop")
WheelLeft:: GroupActivate, workshop, R
WheelRight:: GroupActivate, zoom, R
#If
Which binds clicking the scrollwheel left and right to special actions only if I’m in “workshop mode”, which is toggled with numpad del.
Thanks for sharing that! As someone who’s primarily used Windows for years due to work reasons (large enterprise orgs like that OS and I was a .NET developer for years), I had to avoid languages that didn’t run well there, like Python and Ruby.
Now I’m a data engineer and do a lot of work in Python – tools like Jupyter have made that a lot easier to be portable when I’m not on a client that either gives me a Mac or Linux machine or creates a cloud based environment I can remote into. Sure, there’s a holdup when they are weird about giving admin access, but for the most part, doing things on Windows just works for me.
This is awesome and allows more folks like me to break in to that market.
Lots of excellent goodies in there. I also rather enjoy the “Shortcut hints” so you can hit Windows and if you hold it down for a sec a screen full of most of the more common shortcuts pops up. SUPER useful for folks making the transition from other environments or even wanting to use the keyboard more.
Let me contribute a small list of tools that I find invaluable on making Windows a decent environment to work in:
Cmder -> A pretty good package of ConEmu which makes working with cmd.exe bearable when you need to. Supports front-slashes, current git branch in your prompt, quake-style terminal drop-down, etc…
Fast Find - If you’re using full blown Visual Studio it is the best fuzzy finder that I’ve found. Extremely speedy even on solutions with millions LOC.
No deep insights, just my WSL-centric experience, but I definitely felt “at home” sooner in the last switch from Ubuntu to Windows than when I used something other than Linux in years past. Cross-OS VSCode remote sessions work well: language servers, etc. can run remotely or in WSL. There’s a reasonable first-party terminal (the one you install, not built in) and build of OpenSSH. Haven’t learned PowerShell but I sometimes use the tools I already knew from the Linux side to find things, munge files, etc. in Windows. The shell and other built-in stuff are keyboard-friendlier than before (e.g. Super and type to search, switch apps with Super + number, Alt-Tab and arrows). Gotta look at the new PowerToys the post mentions.
I’ve also got complaints about Windows, but this isn’t a review. Just neat how much the default OS shipped with a bazillion computers has changed from the perspective of a dev with mostly Linux experience.
I’ve also got complaints about Windows, but this isn’t a review. Just neat how much the default OS shipped with a bazillion computers has changed from the perspective of a dev with mostly Linux experience.
WOW so much this!
When I wrote the article, I didn’t mean to declare a deep, abiding love for Windows. It’s more like “Hey wow in the past when I tried it it was PAINFUL, and now it’s smooth like buttah!” :)
I will always love Linux best in my heart of hearts. The idea of a fully FLOSS work environment is super shiny. Maybe when I retire I will have time to dive deep and fix these deal breaker accessibility bugs that make desktop Linux super painful for me to use today, but until then, I’m super psyched to have found an environment that lets me Get Things Done with a modicum of pain.
I hope winget will continue to improve, but for now it seems quite limited - even compared to https://scoop.sh and chocolately?
And apparently you can’t winget iis or sql server? (but on Linux you can docker run sql server.. What à time to be alive…).
Both python and ruby have long had rather good cross platform support -but the real test is compiling and linking against c extensions, and uploading wheels etc. Still seems there’s a bit of effort in getting a native compiler tool chain set up on windows? (but there’s been a lot of improved support for using msvc). And is there support for cross-compiling wheels?
Please note that my post was very narrowly focused on Windows being used as a desktop environment for Python developers.
All I want from winget is “Install the stuff I want from the command line” and the ability to create a JSON file I can make it execute against to get all the things I need on a new machine is awesome.
Thanks for posting this. I don’t use Windows as a daily driver, and every couple years it seems I suddenly need to run it and I get lost trying to catch up to what’s good. Oh My Posh looks nice, and powertoys run seems like a decent Rofi replacement.
This is something of a tangent to the main point of your piece, but you mention it in there so I’m going to ask. You like to avoid the mouse. Do you have some kind of tiling setup for Windows that you like, for managing windows using the keyboard similar to i3 or sway? I’ve seen the autohotkey one before, but am wondering if there’s something that integrates a little more easily.
Answering with the tangent: PowerToys also provides a tiling windows tool called FancyZones. It’s not as keyboard-friendly or as automatic as i3 or sway; you define layouts in advance, and can switch a display to use any of those layouts. In the past, though, I’ve used tiling window tools for Windows like bug.n, and (while bug.n was quite good most of the time), they tended to interact in weird ways with the rest of the system. FancyZones seems to be at least better integrated, even if it’s not very dynamic. Amethyst Windows and win3wm are a few new entries I haven’t tried.
Thanks for an actual answer @gcupc!
But to answer this for my own self, I do not and would not want such because being visually disabled as I am, my eyeballs focus VERY slowly on any given spot on the page, and because of some other neuro-muscular issues my eye also jumps every few seconds so I need to keep the layout aas simple as possible. Windows already provides superlative keyboard controls for “Maximize” which is all I want out of windows and layouts :)
I’ve been following the very recent additions around desktop workspaces with great interest though, since having totally separate purpose built workspaces for various tasks IS something my busted eyeballs can handle and might be a productivity win for me overall.
It sounds like more of the big-name tools are supporting Windows, but the problem isn’t those. It’s all the smaller stuff, all the little libraries you use all the time where Windows is a 3rd-class citizen at best where you’ll get tripped up.
So work with those in WSL. Got an actual example I can test?
If Python is anything like Ruby there are Ruby gems that required native binaries. Getting ruby gems compiled with mingw gcc was a challenge back in the Windows 7/8 days. WSL came a bit too late for me.
Glad you brought that up.
As of 5 years ago or so, the answer would be “Yes it’s a raging tire fire JUST LIKE Ruby”
But there was a call to action among Python educators who wanted to help folks who had zero coding knowledge come up to speed, and BY FAR their biggest pain point was “My students are all running Windows. This tire fire will not do.”
So a TON of people in the community including Guido and lately Microsoft have put a positively enormous (And I’m not exaggerating) amount of effort into making Python drive like a Cadillac under Windows, and they have succeeded admirably which is why I wrote the post.
Note the title citing that 2021 is the year Windows became a TRULY first rate Python development environment. Some of the changes I cite are VERY recent - like Windows Powertoys providing an Alfred analogue and WSL-g which means that pretty much anything you need to build, test or run under Linux will also run on Windows.
The Python 3 conversion had a huge part to play here as well, as there were a bunch of platform / filesystem related issues that became MUCH easier and lower effort to properly code under Python 3.
I’ll probably be flamed to death for this comment, but I tried the Windows and WSL for web development for a grand total of about 2 days before I threw it away and went back to plain linux.
WSL was far slower, and I found the configuration over-complex and completely unintuitive.
First - Do you have disabilities that make accessibility features critical path? If not, then we have very different needs.
Second, was it WSL 1 or WSL 2? There’s a huge difference between them in terms of perf and completeness.
Third and by far most important - no one environment is for everyone. If I had your fully functional eyeballs I would probably be rocking a Linux desktop too and loving it, but I don’t. After spending weeks and weeks reporting the bug, beating the drum, trying to get developer eyeballs, and then finally realizing that the tiny cadre of people with enough understanding to fix the issue simply don’t have time, I realized it was time to give up and recognize that the fully open source promised land is not going to work for me :)
Glad to hear you’ve found a toolset and environment that works for you!
Considering your accessibility feature needs, describe your ideal workflow ;-)
Ooh. GOOD QUESTION!
So first let me state that my biggest obstacle and hence my biggest ask is simply this:
I need to be able to actually READ everything - text, UI elements, all of it, with my busted eyerballs.
(Blind in one eye, 20/80 with correction in the good eye)
So, my ideal world ask around this would be an environment where I could choose the scale/size of EVERYTHING. Text, UI widgets, all of it, and where if I DID choose a larger text/UI size all the applications wouldn’t just utterly fail in all kinds of novel ways.
Want to guess how many times I’ve set large text and then had apps put critical bits of content or configuration BELOW the visible page with no scrollbart? You don’t have to guess, the answer is a lot :)
That’s why key chorded full screen zoom is UTTERLY critical for me in the current real world where you can adjust text/font size if you’re lucky and then whether said adjusted size will break your apps is another thing altogether.
In terms of actual “Workflow” my needs are very simple. Mostly, because of my low vision and slow focusing, I pretty much always keep Windows as full screen. So ideally I like to have a bunch of separate “workspaces” each tailored to a task.
Windows does this pretty well, and so does KDE. KDE gets mad props from me for being the ONLY FLOSS desktop that has had real zooming features for many years and never left it broken unlike Gnome.
So all of this is covered by the mechanisms arcan already have, and how the reference DE durden uses them. Everything that is ‘native’ uses Display Density and Preferred Pt size for layouting / positioning, alas non-native clients (so the majority of them) are not as lucky. The inertia, legacy and bias from toolkits spoil much of the fun. Some override toggles may work, e.g. lying “per window” about the display density to force clients to scale rather than post-process zoom, but it is case by case. In my experience, toolkits are slightly more responsive to faked display properties than to listening to reason about font preferences.
If you feel like indulging my curiosity further: how problematic is navigation combined with focus when you have high magnification? From my own use cases, both the ‘pan to center around current cursor’, separate ‘zoom window’ or ‘drag to pan’ are both rather distracting and breaks focus. What has worked better, for me, is:
I am currently experimenting with adding more text-to-speech on out-of-band signals (e.g. notifications), positional audio mixing of multiple t2s streams to handle more contents (head tracking and HRTFs for more mental “bandwidth”) and image-to-sound like translations.
I think the problem these two behemoths are fighting are one and the same; the mechanisms used as building blocks. They are either extremely limited (X+COMPOSE) or fractured and brittle (Wayland) where even a keypress is a full season of “murder, she wrote”. Under those constraints, to get to an ok point (half-way to what apple has in their zoom tools) is a lot of tedious work, and to keep it from breaking is thrice that.
Dunno if you’re still reading this but I totally missed this question in an answer previously :)
The answer is that I don’t generally have a problem with navigation when zoomed, because generally I don’t zoom to such an extent that this problem occurrs, or if it does I just zoom out a bit having already read/parsed/selected the particular problematic text/UI element/whatever.
IMO the edge detection strategy would be the most useful because the one navigation issue I DO Sometimes have when zoomed is that apps don’t always properly detect the zoomed UI elements click zones properly so I have to zoom out, click, zoom back in again etc.
WSL 1 is akin to the FreeBSD Linux ABI layer. This has good and bad points. The good point is that it’s a fully native bit of Windows: it sees the same filesystems, uses the same pipe interfaces (so you can create pipes between Windows and Linux processes and have the same performance as between a pair of Windows or Linux processes), and so on. The down sides are that it uses NTFS via a pile of filter drivers to expose POSIX semantics (which makes FS access slow) and it is always playing catch-up, with some big features not implemented (e.g. seccomp-bpf).
WSL2 is a Linux VM with some tight integration to do things like forward pipes over Hyper-V sockets, expose the host FS as 9p-over-VMBus (which is much slower than WSL1 accessing the host FS, but the Linux-native FS is just a Hyper-V block device formatted with ext4 so is as fast as a normal VM disk). This is 100% compatible with Linux (because it is Linux) but some of the integration has rough edges.
I’m not sure what your issue was with configuration: Install Windows Terminal from the Windows store. Install your favourite distro from the same store. Run the terminal, set your favourite distro as the default profile. Done.
There are bunch of things about configuration. Profile migration, file permissions,vscode remote server configuration, git client configuration, ssh client configuration and so on.
It’s really cool what the microsoft trying to do, but for professional web development for linux server, plain linux will be always best choice.
Please consider avoiding terms like “always”.
It’s decidedly NOT the best choice if you’re disabled and the Linux desktop fails to provide basic features necessary to get work done.
Check out AutoHotKey.
I’m serious. AHK is the killer feature of developing on Windows. I have it set up so that pressing
numpad2can launch five different apps and show a list of every app it can launch.My most recent AHK script: I can highlight any timestamp and convert it to UTC and Chicago time: https://gist.github.com/hwayne/61dacc2d66dac20cfb0ef7bb9bab7498. AHK is really, really good.
AutoHotkey is great but you basically have to learn the wacky configuration language, and it conflicts with anything else that tries to ‘hook’ the keyboard, so I bounced off.
Lots of power there for sure, but as I mentioned my humble needs are met admirably with the latest PowerToys and its Powertoys Run and Keyboard Remap features.
Yeah this one sucks, esp since most users aren’t programmers so all the tutorials aren’t oriented at people who already program.
I got around this by mapping things to the rightmost modifiers. So leftcontrol+d is normal, while rightcontrol+d is “jot timestamped note”. You can keybind the right control with
>^.Also, modal hotkeys! Any hotkeys defined under
#If (expr)are only active ifexpris true. So I haveWhich binds clicking the scrollwheel left and right to special actions only if I’m in “workshop mode”, which is toggled with numpad del.
Thanks for sharing that! As someone who’s primarily used Windows for years due to work reasons (large enterprise orgs like that OS and I was a .NET developer for years), I had to avoid languages that didn’t run well there, like Python and Ruby.
Now I’m a data engineer and do a lot of work in Python – tools like Jupyter have made that a lot easier to be portable when I’m not on a client that either gives me a Mac or Linux machine or creates a cloud based environment I can remote into. Sure, there’s a holdup when they are weird about giving admin access, but for the most part, doing things on Windows just works for me.
This is awesome and allows more folks like me to break in to that market.
Big +1 from me for making me discover PowerToys. Thanks!
Glad to hear I could help!
Lots of excellent goodies in there. I also rather enjoy the “Shortcut hints” so you can hit Windows and if you hold it down for a sec a screen full of most of the more common shortcuts pops up. SUPER useful for folks making the transition from other environments or even wanting to use the keyboard more.
Let me contribute a small list of tools that I find invaluable on making Windows a decent environment to work in:
Just my $.02 but for me anyway Windows Terminal Preview makes me MUCH happier than any Cmder variant.
The rest are pretty great though :)
No deep insights, just my WSL-centric experience, but I definitely felt “at home” sooner in the last switch from Ubuntu to Windows than when I used something other than Linux in years past. Cross-OS VSCode remote sessions work well: language servers, etc. can run remotely or in WSL. There’s a reasonable first-party terminal (the one you install, not built in) and build of OpenSSH. Haven’t learned PowerShell but I sometimes use the tools I already knew from the Linux side to find things, munge files, etc. in Windows. The shell and other built-in stuff are keyboard-friendlier than before (e.g. Super and type to search, switch apps with Super + number, Alt-Tab and arrows). Gotta look at the new PowerToys the post mentions.
I’ve also got complaints about Windows, but this isn’t a review. Just neat how much the default OS shipped with a bazillion computers has changed from the perspective of a dev with mostly Linux experience.
WOW so much this!
When I wrote the article, I didn’t mean to declare a deep, abiding love for Windows. It’s more like “Hey wow in the past when I tried it it was PAINFUL, and now it’s smooth like buttah!” :)
I will always love Linux best in my heart of hearts. The idea of a fully FLOSS work environment is super shiny. Maybe when I retire I will have time to dive deep and fix these deal breaker accessibility bugs that make desktop Linux super painful for me to use today, but until then, I’m super psyched to have found an environment that lets me Get Things Done with a modicum of pain.
I hope winget will continue to improve, but for now it seems quite limited - even compared to https://scoop.sh and chocolately?
And apparently you can’t winget iis or sql server? (but on Linux you can docker run sql server.. What à time to be alive…).
Both python and ruby have long had rather good cross platform support -but the real test is compiling and linking against c extensions, and uploading wheels etc. Still seems there’s a bit of effort in getting a native compiler tool chain set up on windows? (but there’s been a lot of improved support for using msvc). And is there support for cross-compiling wheels?
Please note that my post was very narrowly focused on Windows being used as a desktop environment for Python developers.
All I want from winget is “Install the stuff I want from the command line” and the ability to create a JSON file I can make it execute against to get all the things I need on a new machine is awesome.