Hacker News Reader

Comment by stephc_int13 | Hacker News Reader

Not releasing a cross-platform code editor on the dominant OS seems quite weird in my opinion. (I know they plan to do it, but as someone who has built cross-platform apps, this is not rocket science to have Win32 support from the start.)

View on HN

Anecdotally, I have never seen Windows widely used for development, outside of .NET shops (but that shouldn't be a surprise).

Moreover, there's plenty of quirks Windows has with respect to:

- Unicode (UTF-16 whereas the world is UTF-8; even Java uses UTF-8 nowadays, so it's only Windows where UTF-8 is awkward to use)

- filenames (lots of restrictions that don't exist on Mac or Linux)

- text encoding (the data in the same string type changes depending on the user's locale)

- UUIDs (stored in a mixed-endian format)

- limit of open files (much lower than Mac and Linux; breaks tools like Git)

If you write software in Java, Golang, or Node.js, you'll quickly encounter all of these issues and produce software with obscure bugs that only occur on Windows.

I'm not sure about Rust, but using languages that claim cross-platform support isn't enough to hide the details of an OS.

In every job I've had, the vast majority of devs were on Mac OS, with Linux coming in at a close second (usually senior devs). So I wasn't surprised Zed first supported Mac then Linux. Windows support is nice for students, game developers, and people maintaining legacy .NET software, but those people won't be paying for an editor.

This comment is not correct.

Java uses mixed Latin1/UTF-16 strings. The Latin1 mode is used for compact storage of alphanumeric text as the name suggests: https://github.com/openjdk/jdk/blob/1ebf2cf639300728ffc02478...

The internals of OpenJDK may use either Latin1 or UTF-16, but the Java API, as of Java 18, defaults to the UTF-8 character set for string operations and text codecs.[1] Just like the standard APIs of Mac OS default to UTF-8 text encoding even though CFString internally uses various different representations to optimize memory usage.[2]

[1] https://docs.oracle.com/en/java/javase/18/docs/api/java.base...()

[2] https://developer.apple.com/library/archive/documentation/Co...

The macOS reference is irrelevant to Java here.

The charset defines the encoding which applies to first and foremost I/O behavior on how it treats otherwise untyped stream of bytes that are being converted to or from (UTF-16) text as stored by Java.

https://openjdk.org/jeps/400 is yesterday's news and something that .NET has been doing since long time ago (UTF8 encoding is an unconditional default starting with .NET Core 1.0 (2017)).

Whether Win32 APIs take UTF-8 or something else (well, it's usually ANSI or UTF-16) is something for the binding libraries or similar abstraction packages for a language of choice to deal with, and has rather minor impact on the overall flamegraph if you profile a sample application.

I find it strange having to defend this, but the UTF-8 vs UTF-16 argument really has no place in 2024 as dealing with popular encodings is as solved problem as it gets in all languages with adequate standard library.

Everywhere I've worked, most users (including devs) are on Windows. Windows is the major OS in enterprise environments, it's a huge mistake to not support it imo.

Anecdotal evidence. Although I agree about OS support parity, because OS religiosity is generally dumb.

- Why is unicode an issue? The editor should use UTF-8. I don't think its forced to follow the Windows standard if they have their own font rendering? - Filenames is an issue, but it shouldn't be too hard to pull in a path library to do most of that for you. Which is why you should code for Windows from the start because you will quickly realize, oh yeah, maybe I couldn't hardcode forward slashes everywhere because it's going to be a pain to refactor later. And oh yeah, maybe case-insensitivity is a thing that exists. - Text encoding..? Just don't do that. Encode it the same way. Every modern editor, including Notepad, can handle \n instead of \r\n now. You needn't be re-encoding code that was pulled down from Git or whatever. - Also don't see why UUIDs are relevant - Limit on open files is probably a legit issue. But can be worked around of course.

Anyway, none of these sound like major hurdles. I think the bigger hurdles are going to be low-level APIs that Rust probably doesn't have nice wrappers for. File change notifications and... I don't know what. Managing windows. Drivers.

None of that matters in practice, because in this context it would be trivial to solve with a correctly built OS abstraction layer.

And Windows is by large the development platform of choice for any serious gamedev work.

For those that want to try it, and have a rust development environment installed, the following runs Zed on Windows. (The editor part at least, I haven't tried the collaborative functions).

  git clone https://github.com/zed-industries/zed
  cargo run --release

It's especially weird they released linux (with x11 AND wayland backends) before windows.

* Both Linux and MacOS are unices, there is less effort.

* The framework they use supports X11 and Wayland out of the box, it wasn't as much effort as you'd think.

* They accept contributions.

For the kinds of devs they've hired, Windows is the third most common development or production environment. I've worked at startups like this for 20 years and haven't touched a windows system.

I realize yall are out there, but from where I'm sitting, this isn't odd at all. They're likely most familiar with and using Unixes.

Give them time, developing cross-platform GUI apps was never that simple

Reply on news.ycombinator.com