5 ms·

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 quirk

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.

neonsunset 2y ago
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/1ebf2cf639300728ffc024784f5dc1704317b0b3/src/java.base/share/classes/java/lang/String.java#L162-L173 https://github.com/openjdk/jdk/blob/1ebf2cf639300728ffc02478...
- koito17 2y ago
  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/java/nio/charset/Charset.html#defaultCharset https://docs.oracle.com/en/java/javase/18/docs/api/java.base...() [2] https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFStrings/Articles/StringStorage.html https://developer.apple.com/library/archive/documentation/Co...
  - neonsunset 2y ago
    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 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.
bigstrat2003 2y ago
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.
- hi-v-rocknroll 2y ago
  Anecdotal evidence. Although I agree about OS support parity, because OS religiosity is generally dumb.
8n4vidtmkvmk 2y ago
- 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.
stephc_int13 2y ago
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.

neonsunset 2y ago

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/1ebf2cf639300728ffc024784f5dc1704317b0b3/src/java.base/share/classes/java/lang/String.java#L162-L173 https://github.com/openjdk/jdk/blob/1ebf2cf639300728ffc02478...

koito17 2y ago
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/java/nio/charset/Charset.html#defaultCharset https://docs.oracle.com/en/java/javase/18/docs/api/java.base...() [2] https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFStrings/Articles/StringStorage.html https://developer.apple.com/library/archive/documentation/Co...
- neonsunset 2y ago
  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 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.

bigstrat2003 2y ago

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.

hi-v-rocknroll 2y ago
Anecdotal evidence. Although I agree about OS support parity, because OS religiosity is generally dumb.

8n4vidtmkvmk 2y ago

- 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.

stephc_int13 2y ago

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.