4 ms·

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

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

ghh 2y ago
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
ksylvestre 2y ago
It's especially weird they released linux (with x11 AND wayland backends) before windows.
- zamalek 2y ago
  * 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.
- segfaltnh 2y ago
  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.
koito17 2y ago
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
ivanjermakov 2y ago
Give them time, developing cross-platform GUI apps was never that simple

ghh 2y ago

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

ksylvestre 2y ago

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

zamalek 2y ago
* 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.
segfaltnh 2y ago
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.

koito17 2y ago

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

ivanjermakov 2y ago

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