Edit is now open source

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.

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

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

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.

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

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.

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.

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

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.