WSL (Windows Subsystem for Linux) is one of the easiest ways to get a Linux environment on a Windows machine. It’s also a place where small assumptions can cost you an afternoon.
Let’s separate the myths from reality, then end with a setup checklist and the pitfalls people keep tripping over.
One helpful framing: WSL is “Linux running alongside Windows,” not “Linux replacing Windows.”
Myth #1: “WSL is basically a Linux VM, so everything works the same”
Reality: WSL2 uses a lightweight VM under the hood, but the experience (and the sharp edges) aren’t the same as a traditional VirtualBox/VMware setup.
- WSL integrates deeply with Windows paths, apps, clipboard, and file access.
- Networking and disk performance have WSL-specific rules.
- Some low-level kernel and device behavior won’t match “real Linux on metal.”
Practical takeaway: treat WSL as its own environment with its own best practices.
Myth #2: “WSL1 and WSL2 are the same; pick either”
Reality: They behave differently, and the differences show up in performance and compatibility.
- WSL2 is the default for most people because it has better Linux compatibility (real kernel).
- WSL1 can be faster for certain file-heavy operations when you work directly on Windows files (but it’s less compatible overall).
If you don’t have a reason to choose, pick WSL2 and follow the file-location advice in the checklist below.
Myth #3: “Where you store your project files doesn’t matter”
Reality: This is the #1 performance pitfall.
WSL2 is fastest when your code lives inside the Linux filesystem (the ext4 disk that WSL manages), not on C:\ mounted into Linux.
- Fast path: work under Linux paths like /home/you/project.
- Slow path (often): working under /mnt/c/Users/you/project with lots of small file operations (node_modules, git status, test runs).
Simple rule: if your toolchain is running in Linux, keep the repo in Linux.
Myth #4: “Copy/paste paths between Windows and Linux and it’ll just work”
Reality: Windows paths and Linux paths look similar enough to be confusing, and that confusion causes subtle bugs.
- Windows uses drive letters and backslashes: C:\Users\name
- Linux uses forward slashes: /home/name
- WSL exposes Windows drives under: /mnt/c/...
Common pitfall: a script that works in PowerShell fails in WSL because it contains Windows-style escaping or backslashes.
When in doubt, decide which environment “owns” the script (Windows or Linux) and keep its paths native to that environment.
Myth #5: “If it’s installed in WSL, Windows apps automatically see it”
Reality: WSL and Windows can call into each other, but installed tools and environment variables aren’t shared by default.
- Installing Python/Node/Go in WSL installs Linux builds, not Windows builds.
- Installing a tool with Windows installers doesn’t make it available inside WSL unless you call it explicitly (or configure your PATH carefully).
- You can run Windows executables from WSL (for example, notepad.exe), but that doesn’t make them “Linux-native.”
Pitfall: mixing Windows Node with Linux Node in the same project can create weird lockfiles, native module failures, or line-ending issues.
Myth #6: “Networking is identical to Linux, so localhost behaves the same”
Reality: It’s usually smooth, until you hit firewall rules, port binding, or the fact WSL2 has its own virtual network.
- Reaching a service from Windows via localhost usually works, but there are edge cases with VPNs and corporate security tools.
- Binding servers to 127.0.0.1 vs 0.0.0.0 matters more than you expect (especially for access from other devices).
- Windows Firewall can block inbound access even if Linux thinks the port is open.
Pitfall: “It works in WSL but not in the browser.” Often that’s a bind address or firewall rule, not your app.
Myth #7: “Disk space is simple; deleting files frees space immediately”
Reality: With WSL2, the Linux filesystem lives in a virtual disk file. Deleting files inside Linux doesn’t always shrink that disk file right away.
- Your Linux distro can look small “inside Linux,” while the WSL virtual disk remains large on Windows.
- Big spikes (like Docker images, build artifacts, caches) are common culprits.
Practical mindset: watch what grows (images, caches, node_modules), and don’t be surprised if “free space” feels delayed.
Myth #8: “If something’s slow, it’s just WSL being WSL”
Reality: Slowness usually has a specific cause you can fix.
- Project stored on /mnt/c (most common).
- Real-time antivirus scanning your repo/build output.
- Too many file watchers (frontend tooling) pointed at Windows-mounted directories.
- Docker + WSL + heavy I/O with the wrong file location.
Before you change tools, change the file location and reduce cross-boundary file churn.
Myth #9: “A quick setup is fine; you’ll ‘clean it up later’”
Reality: Small early choices (distro, file location, default user, terminal habits) determine whether WSL feels calm or chaotic.
A practical WSL setup checklist (with the common pitfalls called out):
- Pick WSL2 unless you have a specific reason not to. Pitfall: debugging weird compatibility issues that disappear on WSL2.
- Create a Linux-first workspace (for example, keep repos under /home/...). Pitfall: slow installs/tests when working under /mnt/c.
- Decide where Git runs (Windows Git or Linux Git) per repo, and stick to it. Pitfall: mixed line endings, permissions confusion, odd file mode changes.
- Use one toolchain per environment (Node, Python, Go, etc.). Pitfall: “it works in PowerShell but not in WSL” dependency drift.
- Be intentional about terminals (Windows Terminal is a solid default). Pitfall: multiple shells with different profiles and PATH rules.
- Keep an eye on security tooling (antivirus, endpoint protection). Pitfall: silent performance hits from scanning massive dependency folders.
- Know your networking basics: bind to 127.0.0.1 for local-only, 0.0.0.0 for broader access. Pitfall: blaming your app when it’s a bind/firewall issue.
- Plan for disk growth: caches and images add up. Pitfall: deleting files but not understanding why Windows free space didn’t bounce back.
Takeaway: the “two worlds” rule
WSL works best when you treat Windows and Linux as two cooperating worlds: keep Linux work in Linux paths, avoid mixing toolchains, and expect networking and disk behavior to have WSL-specific quirks.
If you do just one thing today, move your active repos into the Linux filesystem and rerun your slowest command. The difference is often immediate.