Why do you use Linux for dev over Windows?

It depends what you want to do.

For most gamedev windows is the platform of choice. All the major graphics card manufacturers put more effort into their windows drivers, and all the major AAA games are released for Windows not Linux, which means more gamers use the platform, so it's a vicious circle of sorts.

As for Linux if you're writing resilient server code e.g. for a server for a Web based or other online game, or something Internet daemon related and not related to games at all, use Linux for it, that's what it's designed for...

As for Mac, I can't vouch or advise as I've used it rarely and it seemed like windows with a smaller user base to me, perhaps you should use that if you're making an ios game.

Edit: at home I have both a windows laptop and desktop for gamedev (windows 10), and another laptop and small office server running Debian.
They both serve important purposes and I've written both big windows projects and big Linux/FOSS projects in the past and needed both.

Hope this helps!

2. Do you Win devs use cygwin for system interaction in your builds?

I have used many build systems and tools based on cygwin in my career and it has always been an unpleasant experience. I'd rather cobble together an arcane cmd batch script than enter the world of cygwin.

However, with the Win10 anniversary update, MS has added bash on Windows (turn in on in "Optional Features") which seems to work great and almost seamlessly, despite being a beta version. It basically gives you a familiar debian/ubuntu based CLI and has managed to run everything I have thrown at it so far, with the exception of "screen".

Another caveat is, that integrating "bash.exe" with other script is made a lot harder by the fact that "bash.exe"'s stdout and stderr can't be redirected. This can be worked around, but it is an annoyance and will hopefully be fixed.

… and has managed to run everything I have thrown at it so far, with the exception of "screen".

Psst, tmux works great under WSL! :^)

All I got is Windows 7 because 8 and 10 go "even further beyond" in the realms of UI fuckery. So I'll compare against that (its also what I got at work).

I cant apply a dark theme on Windows without fucking up some important MS program (like fucking Word or Excel, Visual Studio, and non-Microsoft ones like TortoiseSVN, and a couple of DB managers). In most Linux desktop environments, such thing as "changing the color of the font" is expected, so most applications come out of the box more prepared for whatever wacky color theme you got.

In Xfce I can add/remove/move/resize all the panels I fucking want, while editing all the fucking items inside them I want. I got 3 right now. In Windows 7 I got the one and only menu bar, which is a fat bastard that can be barely resized.

Fucking virtual desktops. I got 4 of them. I can set a manager to a panel, that auto hides, and switch them with the mouse wheel.

In Windows, I have to add shit to the Environment Path so they fucking appear on the console because no one ever expected you to install something in Program Files and call it from a cmd.

I like the package manager.

As for actual developing in one or the other, I do completely different things in each. Web dev with VS2010, .NET 4 in Windows, and desktop dev with Eclipse and Java 8 in Linux. I do enjoy using Debian more, that's all I can say about it. When I get a new computer at work, I might try to install Debian and just run VS2010 out of a VM.

In the office the network is windows 7 through 10, with Windows and Linux servers.

That is apart from us in IT where I've got us using a Linux distribution of our choice, and it's worked well for a good 3 years without issue.

I find there's very little we actually need windows for.

If we were doing game development though... Not a chance we'd use Linux for it...

I code for X-Plane in C++ because it simply works on all os. If you code on Windows or Mac, you suddenly remark that you have to rewrite stuff to compile on other os.

I'm also faster with Linux tools than on Windows. Grep, bash etc. save me time.

With bash now in windows 10 the line is becoming blurry. Windows 10 GUI with the power of bash when you need it!

With bash now in windows 10 the line is becoming blurry. Windows 10 GUI with the power of bash when you need it!

It's not just bash. It's full-blown Ubuntu. If you use WSL you're running GNU/Windows, which is identical to real GNU/Linux with the Linux part crossed out and Windows written in with blue crayon. The line is not really blurry, and the GNU bash shell is only one fairly small part of the equation.

I code for X-Plane in C++ because it simply works on all os. If you code on Windows or Mac, you suddenly remark that you have to rewrite stuff to compile on other os.

I'm also faster with Linux tools than on Windows. Grep, bash etc. save me time.

This. Unless I'm targeting my code for windows (the need for which is becoming less and less as time flows on) using a Linux shell is pure joy. Even in powershell I'll forget what I'm on and try to write a quick perl line and *bam* pw doesn't know what I'm talking about. Remember: Linux was written by coders for coders (arguably), where as Windows was written by a corporation for people to consume, NOT MODIFY, at least to the extent that Microsoft wants.

Windows works, and well enough for what its meant to do, but its obvious that some things are an afterthought next to Linux. Powershell being an example. Every Linux has shipped with shells and the ability to automate simple tasks easily from waay back, with grep, wget, telnet, perl, awk, etc. Powershell came after Windows developers more and more discovered Linux shells...

When I need to do anything 3 times or more often, my first instinct is to write a script or program for it, since practice teaches that you'll need to do that trick way more often than you think.

Linux allows everything to be done from command-line level, which means I can automate everything. Configuration is in text files, so you can just edit it (or script editing, eg sed/awk), unlike the Gui stuff. Looks nice, but navigating and automating is a hell, not to mention all the work-arounds "first select this from here drop-down, then change that in sub-sub-sub-dialogue there, or it doesn't work for unknown reasons".

It provides all the power-tools you can imagine, and a few more you didn't know even existed. They come with the system out of the box, or you install them in 30 seconds with a package manager. Automatic updating takes less than a minute, and rarely requires a reboot, and definitely no "Don't dare turn me off now, I first have to plough through these 238 updates, please try again in a few hours!"

All tools come in several versions, each with its own strong and weak points, so you can pick the tool you like best, or use both, depending on what you need to do.

"Focus follows mouse" is configurable, ie you type in the window where your mouse is, no need to explicitly activate it by first clicking on it, saves a heap of mouse-clicks every day. You can just work in a partly visible window, raising a window is an option and not a requirement. (in non-unity desktop). Sadly slowly disappearing, but selecting some text with the mouse is a selection, no need to CTL-C that explicitly. Also, paste is from the mouse and not from CTL-V.

Where you sit and where you work are separate concepts. I can work at my local system, but also remotely without ever leaving my chair. My desktop can have a mix of windows from both local and remote systems. The mouse decides (focus follows mouse) at which machine I work.

Even if I'm targeting Linux, I still prefer Windows as my development environment.

Visual Studio extensions like VisualGDB mean I can keep the bulk of my coding workflow the same. I can run a Samba server and map my drives for access to the filesystem. And in the event I need a terminal, I just use one of many freely available terminal applications (MobaXterm being my current favorite).

Where you sit and where you work are separate concepts. I can work at my local system, but also remotely without ever leaving my chair. My desktop can have a mix of windows from both local and remote systems. The mouse decides (focus follows mouse) at which machine I work.

This exactly. Development environment comes down to which tools you like and are most productive with. The platform cross-over is virtually seamless with modern tools and technologies.

I prefer Linux as a more stable development than Windows.

Windows is easier to work with but the maintenance effort for the long run disappointed me, I don't want to re-install my Windows and its tools (and some games) occasionally because it gets slower and produces software errors (haven't been long with Windows 10 yet, it could be different now), not to mention viruses infection. I've switched to Linux and quit gaming for a period of time. Managing to get 2 computers so I could have Linux to develop and use Windows to test/play games if needed.

All of my colleagues who have been the odd one out with a Linux OS have used vim and some cool looking tiled window managers. They do always seem quite productive so it's tempting to learn.

I've tried to learn vim but always give up half way up the cliff-like learning curve...
I only use linux for some microcontroller work because that vendor only has a cross-compiler available on Linux.

One pro for Linux as a hobby hacker for me is that most distros have a very handy package manager that makes it possible to very easily install all the libraries/sdks that you'll be depending on.
However this is also a con for me as a professional, as release engineering is a nightmare when dependencies/libraries are system-wide installs (globals are bad, people!) instead of local/private to your app.

However this is also a con for me as a professional, as release engineering is a nightmare when dependencies/libraries are system-wide installs (globals are bad, people!) instead of local/private to your app.

Well, to flip this on its head, it's annoying when your OS has patched a core library to fix a huge security bug, and a program is static linked against a vulnerable version or a dll/shared object in its directory and hasnt been updated, leaving it vulnerable :(

However this is also a con for me as a professional, as release engineering is a nightmare when dependencies/libraries are system-wide installs (globals are bad, people!) instead of local/private to your app.

There are some dependency management tools for C++ out there, but I haven't tried any of them though.

All of my colleagues who have been the odd one out with a Linux OS have used vim and some cool looking tiled window managers. They do always seem quite productive so it's tempting to learn.

It might be that they're efficiency-minded in the first place and are looking for the fastest ways to do things.

I'm a pure Windows user, but I hotkey and automate everything that I notice I'm wasting time on. I occasionally watch my vim-oriented coworkers and they do the same. Then I watch my other Windows-oriented coworkers and they're slowly using the mouse to hunt and peck through menus.

I explore the available software and the options it has so I can find ways to use it more effectively. Some people don't even bother to learn how their tools work.


A specific example of an extremely common day-to-day task: C# find-all-references, examine results, then return to where you left off.

My way:
- Place cursor on identifier, press hotkey.
- The IDE symbolically finds only the exact identifier I care about.
- If I see the one I want I double click on it, otherwise I hit F4 to step through each one.
- I hit a custom hotkey to navigate back to my old location when I'm done.

Their way:
- Press Ctrl+F (opens the text search box).
- Type in the identifier name into the box (they don't copy+paste the identifier name in).
- Press enter.
- Eyeball the search results window - look at all those identifiers named the same thing but are actually part of different classes!
- Double click on a result to go to that code.
- When they want to return to their original spot they try to remember the name of the file they were working on, look through the tabs opened in the IDE, and click on it.
- They then scroll up/down in that file until they're finally where they were before.

My way is orders of magnitude faster.

It's stupid little things like this which add up constantly and determine efficiency in our day-to-day work.


As far as command-line suckage in Windows, I don't particularly mind. Nobody in their right mind uses the windows command line or batch files. I write my own C# console apps if I really need anything; it does take longer than a proficient grep user, but on the other hand there are cases where I want to do something crazy like grep, parse as json, run a jpath query, read the results as floating point values and convert them from radians to degrees. That, I can definitely do faster in C# than the time it would take me to figure out whether there are linux console commands capable of it and what funky syntax to use with them.

Large complicated automation scripts? I would much rather just write a C# program. Can you even step through shell scripts in a debugger?

I've tried to learn vim but always give up half way up the cliff-like learning curve...

Yep, learning is a mess.

Best approach I found was to split it in small steps. Take a few basic commands, like 'x', 'dd', 'ZZ' and 'i', and do those for some time until you can do them without thinking. Then add a few that you're really missing, and use them until you're familiar with them, etc.

Keep in mind that vim is bigger than your needs, nobody uses or knows everything that exists in vim.

Also, your use of commands changes over time, When I started I learned about ZZ, nowadays, I use :wq , probably because of :w useful for writing a file while editing.

What I really miss in IDEs is integration with the OS. In vim, I can select a range of lines, then type

:'a,'b ! sort

(for the range of lines between markers a and b, feed these lines into 'sort', and replace them with the output)

However this is also a con for me as a professional, as release engineering is a nightmare when dependencies/libraries are system-wide installs (globals are bad, people!) instead of local/private to your app.

Unix is a multi-user system from the ground up. Just because you never share a system doesn't change its architecture :)

Everything 'system', ie not under /home/youraccount (or where-ever you have your home directory) is shared space between all users of the system. Applications in /usr and /local are intended for general use by all users, and yes having them shared is useful, it reduces maintenance effort.

Since access to the general directories is controllable with environment variables, you can create your own layer on top of the system layer. Nobody stops you from downloading some library and installing it in $HOME/lib. I have a $HOME/bin directory with my own common scripts in $PATH. I used to have a set of installed python-libraries, as the Centos system either didn't have them, or they were too old.

There are some dependency management tools for C++ out there, but I haven't tried any of them though.

Many are wrong, in the sense that they don't separate build from install (ie "build" shouldn't touch anything outside the build directory), one may want to switch to root only for final install. Another common fail is not distinguishing install path (the path used for installing the build artefacts) from the installed path (the path used for accessing the installed artefacts). Yes these can be different if you share /usr between systems over the network read-only, so you need to install to /mnt/usr which is a temporary mount with write access.

Another common cause of different paths there was different processor architectures (install at /x86/usr, access at /usr for example), but that problem mostly resolved itself, it seems.

Large complicated automation scripts? I would much rather just write a C# program.

I tend to use Python for that, as it's quicker to write, but yes, shell scripts aren't that useful for me, although being able to enter

for f in *.txt
do convert $f
done

at the command-line us useful every now and then :)

I am using Linux for almost everything because of the workflow i adopted years ago which is working pretty well for me. I am one of the crazy vim users (same goes for emacs, i guess :-p). I just open a bunch of tabs in my terminal emulator and switch back and forth, type code, compile, run, debug all without ever lifting my hands from the keyboard. It sounds crazy at first, but after a while you realize how much time you waste by waving this funny little rodent around your desk. And I have the same workflow for whatever language I happen to use. Also, I have all those fancy little UNIX CLI tools just a few keypresses away. I am using bash loops in my normal workflow regularly, or several tools to arrange certain parts of code or data.

Things like "pipe the selected lines of code through a program and replace them in the file with the output of the program" are super useful when clean-formatting code.

I don't say this workflow is for everybody, but for me it works really well and I feel very constrained when switching to a GUI think like VS or Eclipse. These have their advantages, too, like some parts of debugging can be more pleasant on them (not all though, nothing beats the power of being able to attach any debugger command to a breakpoint). This workflow also has a certain learning curve to it, I have to admit that and I was probably a lot slower when I began than my buddies on Windows were. I'd like to think I'm more productive today though ;-)

It's just a more direct way of talking to the computer, and I like that. Fewer layers of abstraction give me more freedom at the cost of more complexity. Everybody has to find out where in that spectrum they feel most comfortable.

Can you even step through shell scripts in a debugger?

You know, in the nearly 50 years since Steve Bourne invented his shell, you'd think some developer would have need of debugging shell scripts. Weird that a single google for "shell debugger" would yield tens of thousands of results.

The most frequently-seen criticism of using Linux boils down to "I am more familiar with Microsoft Windows." It's not a very good criticism. People who make such criticisms are evidently not very capable logicians and you would be well advised not to hire them into a programming position.

To the OP: there are simple, effective all-Linux workflows for Haxe. If your own personal workflow is a hybrid that uses Windows for some parts and Linux for others, and it would be improved by integrating everything on Windows, then use that more appropriate workflow. It's not a religion. You will find exactly the same technical capabilities on each platform, just sometimes dressed differently.

Mean time I use Linux exclusively, because I am more familiar with it. That's not a criticism of Windows, since I can run vim and the shell on Windows (and Mac OS) just fine when I am called to work on those platforms. It's just that I've been using Unix since before MS-DOS was invented, and I have never become enculturated with the Big Friendly Brother way that comes with the Apple or Microsoft operating systems. Why would anyone "switch to" Linux? Because of the culture of freedom and choice, not because of the technology.