Many Rust IDE features are difficult to implement on Windows. So, is Windows widely used among Rust developers who want a better IDE?

I recently asked about features for my upcoming Rust IDE, and I got a lot of great responses. Unfortunately, implementing many of them on Windows would require significantly more time and effort than doing so on just Linux, so I'm wondering how widely-used Windows actually is among those who are interested in my IDE. To learn more about where IDE support would be most useful so I know how much effort to spend on making my IDE work on Windows, I'd like to ask that as many Rust developers who want a better IDE experience as possible fill out this poll. Feel free to reply here if you're uncomfortable with Google forms (the questions are copied below) By filling it out, you can help ensure that my IDE will be available on your platform of choice.

Poll Questions (slightly modified for alternate format):

Which OS do you write your Rust code on?

Which OS (if any) do you target with your Rust code? *

  • Linux Userspace Programs
  • Mac Userspace Programs
  • Windows Userspace Programs
  • Embedded/Drivers/Other non-Userspace programs
  • Android Mobile
  • IOS Mobile
  • Other (please specify)

To users of Windows, are you willing to switch to developing on Linux for better IDE support?

To users of Mac OS, are you willing to switch to developing on Linux for better IDE support?

In what context do you develop Rust (so I can understand how OS use varies in different groups that may use my IDE)? Note that this question is optional in the Google Forms poll, as some people may not want to divulge this information.

  • I program exclusively or nearly exclusively in Rust for my job.
  • I program in Rust and other language(s) for my job.
  • I program in Rust for my own projects, but in something else for my job.
  • I program in Rust for my own projects, but my career is not in software development.
  • I do not program in Rust in any context.

Your poll will not let me develop Rust on Linux and Windows.

Which I do all the time.

Even both at the same time with the Linux Subsystem for Windows. Code is edited in VS Code in Windows and runs under Debian in the LSW. Or the source is remotely accessed with sshfs and is on a remote Linux box.

Also I don't want think about switching from Windows to Linux or vice versa. My VS Code runs on both, as do many other tools I use.

Anything that is not cross-platform is likely to go unused. Finding a tool you depend on is not available some place that the wrong OS is installed would be a pain.

Are you seriously proposing to build an entire IDE from scratch? !


WSL counts as "developing on Windows," sorry for the lack of clarity. I have considered making my IDE just for Linux though, and telling Windows users to use the new WSL2. I'm curious what anyone who reads this thinks about that.

I'm wondering what IDE features are difficult to implement on Windows?

Not that I know anything about creating IDEs.

Someone had a similar question on Reddit, here's what I said there:

There are a few such features. They mostly revolve around a GUI library. Each library that I've looked into has similar problems, but I'll talk about just GTK here for brevity. Just to get GTK running on Windows is a bit of an adventure, as they don't publish official builds. Yet, I managed to do that by extracting the files from MSYS2. MSYS2's files are incomplete, however, as they lack the VTE library, which is the only reasonable choice of library that I can find for integrating a terminal into my IDE (a must-have feature, even just for showing the output of the program that one is developing). I could try to port VTE myself, but that's a huge project in and of itself, and I've already done quite a bit of GObject mucking as part of this development and it's a terrible experience.

1 Like

Using Sciter or Web-View is not option to avoid problems with GTK?

I'm writing most of my programs on W10, WSL is an option - but I'd rather avoid using it if I could.

1 Like

Thank you very much for the suggestion, but in this context using web-based technologies for desktop GUI is questionable at best. The technologies that underlie web-based programming were originally designed to show marked-up documents, not modern interactive GUIs, and for decades extra features have been bolted in, often in poorly thought out ways, making a system that is technically usable, but a horrible nightmare to work with. Just look at how many questions there are on the Internet about how to vertically center something via CSS. Sure, I could pull in a 3rd party library to handle everything, but the overhead of web-based software is already quite large, compared to something like GTK. Sure, GTK isn't anywhere near perfect, but in every way that matters to me (except terminals) it's leaps and bounds ahead of any reasonable web technology that I've seen. One of the main features of my IDE is that it will be lightweight and easy to run on even the most under-powered of computers; I don't want to ruin that via an unnecessarily embedded web browser.

1 Like

Don't mention it - your point makes total sense.

If you'd prefer to focus on it being lightweight and performant, perhaps it'd make more sense to look towards a TUI like cursive then? To say it looks old-school is an understatement, but playing a bit with the colors should yield an interface that is as snappy, as it can be.

Most of the Rust'ers (from what I had a chance to pick up - and this includes me) seem to prefer safe and fast performance over highly polished interfaces. And most of them (if not all) are quite comfortable using a command-line. Otherwise, I suspect, we'd already have the best bindings we could get to all the major GUI toolkits out there, or we'd have already invented something of our own by now. There's been some discussion and progress in this field, but it just not seems to be of such a high priority. And if it's not, why not just go for what people are already using - which is their terminals? And base an IDE purely on that?

Heck, I'd be the first to try it out. Especially if all the right tools were milliseconds away - with hotkeys.

I'm currently using Neovide on windows (without WSL) and with the coc-rust-analyzer plugin it's great.

I haven't dug into the source but it seems to be totally native stuff with low-level gpu calls - no webview or gtk bindings.

As a Windows developer, WSL is great, and I'm glad that Rust supports it, but it's not native support. When I hear "you can do stuff on Windows via WSL" I hear "I am hoping support Just Works and don't prioritize Windows users."


I don't quite follow what you are saying there.

What does it mean to say "WSL is great, and I'm glad that Rust supports it"?

I do all my Rust work in Debian running under WSL. That Rust does not know it's on a Windows machine. It's the same Rust as on my Debian machines.

As it happens, and perhaps beside the point, I have Rust installed on the Windows side of things as well. Unfortunately I have yet to get it to build any non-trivial program.

It is a good technology. I am glad that it’s a thing, and I’m glad that you can use Rust with it and it Just Works. Especially in the early days it was not always that simple.

1 Like

A silly question but am I to assume from that statement that Rust was originally developed on Windows and the fact that it works on Linux came later?

If so, I find that surprising.

I meant the earlier days of WSL.

Ah, OK, thanks. Perhaps I'm late to the scene. The WSL has always "just worked" for me. Apart from stuff that actually needs a Linux kernel under it.

In fact the WSL is the only reason I can use Win 10 at all. Without that I would have continued in my Linux only world.

A meta thought on this topic... It seems to me that in some ways the Rust community tends toward ideals rather than realities. Things like

  • Wouldn't it be nice if everyone used Unix-like systems
  • Wouldn't it be nice if everyone used UTF-8 everywhere
  • Wouldn't it be nice if we had safe, efficient abstractions for everything
  • Wouldn't it be nice if we could think up a perfectly designed abstraction and syntax before adding a feature to the compiler

And to be fair, all of these things would be nice and Rust does a better job of approaching them than the vast majority of the programming world. It's just that reality never 100% reflects ideals.

Isn't that a good thing? A driving force for better?

If one were happy with the existing "realities" why create a new programming language in the first place, just carry on using C++?

Given that ones new language is motivated by memory safety, type safety and general correctness together with language ergonomics then the items on your list follow naturally as requirements. Otherwise one is wasting ones time.

I'm sure the ideals are not met 100% even after all that.

1 Like

To rephrase Steve's point, just telling Windows users to use WSL is not an ideal solution and will lose you a lot of Windows users.

WSL is a great way for Windows users to run Linux tools, but that's all it is- applications running under WSL do not "support Windows" any more than applications running under a Linux VM on a Windows host. No matter how integrated the user experience gets in the future, true Windows support means using Windows APIs, ABIs, and formats, which enables interop with the rest of the Windows ecosystem.

(This is fine if full Windows support is not your goal, of course!)


If I went the WSL route to support Windows, it would involve thorough testing and a commitment to fix any bugs should they get missed in testing. Is there some way that I could convince you, as a Windows user, to see it more as a library that I used to help than a non-Windows experience?

Not really. But, as @rpjohnst mentions, that's also okay! Not everyone has expertise on every platform. I am still a relatively new Windows user myself.

The closest analogy I can come up with is WINE. If I said, "hey, my software is a Linux program, but you have to install WINE to use it," you would probably be appreciative, but also know that odd bugs and behaviors are ahead, because you're not really using the platform directly. That doesn't inherently mean that you wouldn't use it, or think the project is full of a bunch of jerks or anything, but given two choices, picking the one that supports the platform natively wins out over one that doesn't.

Does that make sense?