Aside from Windows being... "windows" (IE; graphical) and the whole "we will do our own paradigm for nearly everything including file paths (UUNC included) and encoding..." Windows is actually pretty stellar if you're writing high performance software.

You can go really far with IOCP and it's so nice to write compared to the contemporary kqueue (BSD) or epoll. I will admit to not trying IO_Uring myself though.

Also the Windows system probes predate any kind of bpf and are easier to use than dtrace.

This is the maximum amount of love I will ever send in Windows' direction though. Everything else is ball-busting.

It's not my idea of a good time, but Windows pioneered some stuff that's really handy for servers.

Receive side scaling[1] is super handy at high volume, and it came from Windows. And Windows has better apis for it than I saw in FreeBSD or Linux when I needed it (I didn't look too closely at Linux though, so maybe it was there).

[1] https://learn.microsoft.com/en-us/windows-hardware/drivers/n...

There are more windows servers than linux desktops

Or Micro[0]

[0]: https://github.com/zyedidia/micro

This might be the most obvious use case: https://learn.microsoft.com/en-us/windows-server/administrat...

I'm a powershell bigot and spend most of my windows admin life in a terminal (or vscode) so my take is to simply use psremoting but ssh is there if you need.

Since windows 10/windows server 2019 afaik.

https://news.ycombinator.com/item?id=15904265

What on earth needs hundreds of megabytes to describe its grammar?

Even the hundreds of kilobytes used in the official grammars seems bulky to me. https://github.com/tree-sitter/tree-sitter-java/releases

That just feels like scope creep. Notepad would also be neat with some better keybinding support, plugins, lsp, ... - but then it wouldn't be notepad, and theres countless not notepads out there.

Tools like nano (well, pico) exist to provide a reliable and always available minimum feature set. If you expand it, then you end up with something that is neither the minimum nor capable enough to sensibly compete with fully fledged alternatives.

> You can use nano over wsl if you want

No, not when ssh'ing to a server to manage it. Pulling in a Linux VM to get a simple text editor also makes no sense.

There is also nothing to integrate - it's a basic text editor for a terminal with no fancy features. It either edits text or it doesn't.

Did they cancel it because dosbox exists? If so, that's smart.

Microsoft has recently said AI writes 30% of their code. Reimplementing things isn’t as expensive as it once was.

Didn't know 32-bit Windows was completely gone.

> What do you like about Zig more than Rust?

It's been quite a while now, but:

- Great allocator support

- Comptime is better than macros

- Better interop with C

- In the context of the editor, raw byte slices work way better than validated strings (i.e. `str` in Rust) even for things I know are valid UTF8

- Constructing structs with .{} is neat

- Try/catch is kind of neat (try blocks in Rust will make this roughly equivalent I think, but that's unstable so it doesn't count)

- Despite being less complete, somehow the utility functions in Zig just "clicked" better with me - it somehow just felt nice reading the code

There's probably more. But overall, Zig feels like a good fit for writing low-level code, which is something I personally simply enjoy. Rust sometimes feels like the opposite, particularly due to the lack of allocators in most of its types. And because of the many barriers in place to write performant code safely. Example: The `Read` trait doesn't work on `MaybeUninit<u8>` yet and some people online suggest to just zero-init the read buffer because the cost is lower than the syscall. Well, they aren't entirely wrong, yet this isn't an attitude I often encounter in the Zig area.

> How did you ensure your Zig/C memory was freed properly?

Most allocations happened either in the text buffer (= one huge linear allocator) or in arenas (also linear allocators) so freeing was a matter of resetting the allocator in a few strategical places (i.e. once per render frame). This is actually very similar to the current Rust code which performs no heap allocations in a steady state either. Even though my Zig/C code had bugs, I don't remember having memory issues in particular.

> What do you not like about Rust?

I don't yet understand the value of forbidding multiple mutable aliases, particularly at a compiler level. My understanding was that the difference is only a few percent in benchmarks. Is that correct? There are huge risks you run into when writing unsafe Rust: If you accidentally create aliasing mutable pointers, you can break your code quite badly. I thought the language's goal is to be safe. Is the assumption that no one should need to write unsafe code outside of the stdlib and a few others? I understand if that's the case, but then the language isn't a perfect fit for me, because I like writing performant code and that often requires writing unsafe code, yet I don't want to write actual literal unsafe code. If what I said is correct, I think I'd personally rather have an unsafe attribute to mark certain references as `noalias` explicitly.

Another thing is the difficulty of using uninitialized data in Rust. I do understand that this involves an attribute in clang which can then perform quite drastic optimizations based on it, but this makes my life as a programmer kind of difficult at times. When it comes to `MaybeUninit`, or the previous `mem::uninit()`, I feel like the complexity of compiler engineering is leaking into the programming language itself and I'd like to be shielded from that if possible. At the end of the day, what I'd love to do is declare an array in Rust, assign it no value, `read()` into it, and magically reading from said array is safe. That's roughly how it works in C, and I know that it's also UB there if you do it wrong, but one thing is different: It doesn't really ever occupy my mind as a problem. In Rust it does.

Also, as I mentioned, `split_off` and `remove` from `LinkedList` use numeric indices and are O(n), right? `linked_list_cursors` is still marked as unstable. That's kind of irritating if I'm honest, even if it's kind of silly to complain about this in particular.

In all fairness, what bothers me the most when it comes to Zig is that the language itself often feels like it's being obtuse for no reason. Loops for instance read vastly different to most other modern languages and it's unclear to me why that's useful. Files-as-structs is also quite confusing. I'm not a big fan of this "quirkiness" and I'd rather use a language that's more similar to the average.

At the end of the day, both Zig and Rust do a fine job in their own right.

Up until around 2 months ago the project actually built with stable Rust. But as I had to get the project ready for release it became a recurring annoyance to write shims for things I needed (e.g. `maybe_uninit_fill` to conveniently fill the return value of my arena allocator). My breaking point was the aforementioned `LinkedList` API and its lack of cursors in stable Rust. I know it's silly, but this, combined with the time pressure, and combined with the lack of `allocator_api` in stable, just kind of broke me. I deleted all my shims the same day (or sometime around it at least), switched to nightly Rust and called it a day.

It definitely helped me with my development speed, because I had a much larger breadth of APIs available to me all at once. Now that the project is released, I'll probably stay with the nightly version for another few months until after `let_chains` is out in stable, because I genuinely love that quality-of-life feature so much and just don't want to live without it anymore. Afterward, I'll make sure it builds in stable Rust. There's not really any genuine reason it needs nightly, except for... time.

Apropos custom helpers, I think it may be worth optimizing `Vec::splice`. I wrote myself a custom splice function to reduce the binary size: https://github.com/microsoft/edit/blob/e8d40f6e7a95a6e19765f...

The differences can be quite significant: https://godbolt.org/z/GeoEnf5M7