Wow, I really want a slide rule watch now.

Just going to jump in here and say that there's another reason I might want Rust with a Garbage Collector: The language/type-system/LSP is really nice to work with. There have indeed been times that I really miss having enums + traits, but DON'T miss the borrow checker.

Maybe try a different ML-influenced language like OCaml or Scala. The main innovation of Rust is bringing a nice ML-style type system to a more low level language.

I wouldn't recommend OCaml unless you plan to never support Windows. It finally does support it in OCaml 5 but it's still based around cygwin which totally sucks balls.

Also the OCaml community is miniscule compared to Rust. And the syntax is pretty bonkers in places, whereas Rust is mostly sane.

Compile time is pretty great though. And the IDE support is also pretty good.

There are other nice things about Rust over OCaml that are mainly just due to its popularity. There are libraries for everything, the ecosystem is polished, you can find answers to any question easily, etc. I don't think the same can be said for OCaml, or at least not to the same extent. It's still a fairly niche language compared to Rust.

I remember about 5 years ago, StackOverflow for OCaml was a nightmare. It was a mishmash of Core (from Jane Street) Batteries, and raw OCaml. New developers were confronted with the prospect of opening multiple libraries with the same functionality. (not the correct way of solving any problem)

Jane Street apparently has a version of OCaml extended with affine types. I'd like to test that, because that would (almost) be the best of all worlds.

I think you're referring to OxCaml. I'd love to see this make a huge splash. Right now one of the biggest shortcomings of OCaml, is one is still stuck implementing so much stuff from scratch. Languages like Rust, Go and Java have HUGE ecosystems. OCaml is just as old (even older than Rust since OCaml inspired Rust and its original compiler was written in OCaml) as these languages. Since it's not been as popular, it's hard to find well-supported libraries.

I too wish that some OxCaml features bring new blood to OCaml. I've been using OCaml for a few years for personal projects and I find the language really simple and powerful at the same time, but I had to implement me some foundational libraries (e.g. proper JSON, parser combinators), and now I'm considering porting one of those projects to Rust just so I can have unboxed types and better Windows support.

> even older than Rust

That's an understatement, (O)Caml is between 17 and 25 years older than Rust 0.1 depending on which Caml implementation you start counting from.

I always wrote Lua off, scoffing at the 1-based indexing, until I was "forced" to learn it thanks to Neovim. What a delightful little language it is. I do wish I could do certain things less verbosely (lambdas would be nice) -- but then again, I defeat myself by suggesting it, because not having all the features makes Lua so approachable.

I used Lua professionally. I prefer the 1 indexing... it just feels more natural. For some reason the C apologists here will scream how 0 based is the only way to go. (which is not, it is just a historical artifact). Languages like ADA allowed you to use either 0 or 1, (or any arbitrary) starting index.

Same here, in fact something I wish the neovim team would do is create a book where popular plugin authors create tutorials that recreate basic functionality of their plugins.

Seems like a no brainer that would help bring in more revenue too, it'd also be an "evergreen" book as new others can contribute over time.

I can't be the only one that would immediately buy a copy. :D

I'm actually trying to work on a video-series to do just this. I've made my own rudimentary plugins reproducing several popular ones, and would like to walk through how I made: a) file-tree b) picker/fzf replacment c) hop/leap replacement d) surround plugin e) code-formatter f) hydra (sub-modes) g) many "UI" (interactive) buffers, etc.

None of these are published because the popular ones are better and provide more functionality, but I want to share what I believe is more valuable: what I learned while writing them.

That sounds great! Do you have a youtube channel or something to follow when you release it?

Yep, though I'm still trying to hit my stride recording videos. I don't release regularly because of lots of amazing $life things.

https://www.youtube.com/@nocturing

If you want a sneak peak of what I want to walk through, check this repo (see the examples/ folder): https://github.com/jrop/u.nvim

Lua has lambdas. They too suffer from verbosity, of course, but they're there.

    function(x) return x; end

There are patches for this so the above can be expressed with something like this:

  [ (x) | x ]

http://lua-users.org/files/wiki_insecure/power_patches/5.4/l...

And for Lua 5.1:

http://lua-users.org/files/wiki_insecure/power_patches/5.1/l...

(I personally don’t use patches like this because “Lua 5.1” is something pretty standardized with a bunch of different implementations; e.g. I wrote my Lua book with a C# developer who was using the moonsharp Lua implementation)

That's what I meant and didn't communicate well. I'm wishing for short-form syntax of lambdas, to be clear.

Mise is a hard sell for me when I can have pure Nix-shells. However, I can see this gaining wider adoption since it's learning curve is so much lower than Nix.

I tried nix-darwin for a year, eventually declared nix bankruptcy, and settled on mise.

mise does 90% of what I need, but at only 1% of the hassle.

I like the idea of nix, and the future of building software is clearly something like it... I'm just not sure it'll be nix itself.

I've seen several Mac users have the same experience: going all-in on nix-darwin and then getting frustrated. But nix-darwin is one of the worst ways of getting into Nix, because its goal is to make your whole macOS system configurable with Nix, but macOS is a moving target and (unlike Linux) not built to be modular at all. I know people put a lot of hard work into nix-darwin, but it's simply not the main focus of Nix as a whole and sadly it might not ever become a seamless experience. (I'm not a mac user so not keeping up, but I do see colleagues trying it out from time to time.)

The solution here is: use Nix but don't use nix-darwin (at least not until you're generally comfortable with Nix for package management and dev shells). You do NOT have to use nix-darwin on Mac to reap 80% of the benefits of Nix (especially in a team setting).

After dropping nix-darwin, I think almost everyone will find that it's very easy to use Nix for sharing project setups with bespoke tooling. I just had a new team member onboard, knowing nothing about Nix, in a day or less, with several different languages and unusual tools.

> After dropping nix-darwin, I think almost everyone will find that it's very easy to use Nix for sharing project setups with bespoke tooling

Ahh, but I tried that too. I originally decided to play with nix-darwin because I was on a contract that used nix in their repos to ease onboarding of academic collaborators.

In practice, it was complicated enough that most of us ended up relying on the 2 nix experts to make any real changes, and when they left, the nix configs stagnated.

It might be the case that nix-darwin, and our particular python/ML repos, were "hard mode" for nix, but I truly think I gave it a fair shake.

If nix requires a lot of effort to do anything off the beaten path, it's just not the tool for me.

To be clear, I don't try to Nix-everything. I just use it to 1) install a bunch of CLI tools to my nix-env, and 2) dev-shells. That's pretty much it, though. Even that is a huge boon. Even so, I'm keeping an eye on mise, for sure.

If you think of it more of in the context of making it easy for people other than you and your bespoke machine to bootstrap a project, that's where it really shines. The toml config is very simple for people to understand.

I use it because I want people to be able to get projects up and running quickly without having to comb through an outdated README, trying to deal with all of the different ways people like to install and use non-compiled languages, etc. Managing anything Node/Ruby/Python is all annoying.

Neovim + Git + Aider seems to get close to perfection.

I have tried similar workflows (Neovim + Opencode/Codex CLI), and for me, the biggest downside compared to Cursor is the lack of a tab completion model as good as Cursor's. Supermaven is the best one I've found so far for Neovim, but it gives worse suggestions and can only suggest changes on the same line you are on.

Just based on a few other comments here I tried supermaven and it works pretty well. You have to be on the line, but it’s better than GitHub copilot.

Agree - leaps and bounds beyond anything I would have dreamed possible a few years ago...but... IDK, if I'm honest, the sound was way off too, not just the visuals. The music sounded detuned slightly, and the crowd noise was "crackly" etc. etc. It had a low-fidelity "quality" to it.

Personally, I feel mixed feelings. I'm impressed, but I'm not looking forward to the new "movies" that are going to litter YouTube et al generated from this.

It's on the roadmap: https://ghostty.org/docs/install/release-notes/1-2-0#roadmap

oh, incredible! i'll keep my eyes peeled and will be switching to it from iTerm the moment it's available

I've been keeping an eye on this in the hopes that text-reflow (edit: including for scrollback) could be solved in Neovim-based terminals [1]. I'm loving the innovation Ghostty is bringing to the terminal space.

1. https://github.com/neovim/neovim/issues/33155

Do you consider yourself a neovim terminal power user?

I tried a while back to invert my workflow (from tmux driving neovim to neovim driving terminals) because I thought it might be easier to only ever have one buffer open for a given file, instead of attempting to open a file in a given pane only to realize that it's already open in a different neovim instance in a different pane.

When I was testing that stuff out I don't think I noticed particular issues with text reflow that would benefit from being solved by swapping to libghostty, rather my pain points were just about how to adjust to the different paradigm. I'd be curious to hear more about someone who is all in on Neovim embedded terminals (and possibly how libghostty might make it better).

I'm all in on Neovim terminals, having a remote development setup means it keeps my terminal with my neovim window (I use nvim-qt).

Also not sure how ghostty would help, haven't noticed text reflowing issues.

It's not bad, a little awkward getting used to:

- you might want a plugin to give you a "persistent" terminal across all tabs

- I still haven't found a way to clear scroll back while a command is running

- I had to set up mappings for easier exiting terminal mode (c-\ c-n really sucks)

- I had to set up events so whenever a terminal buffer is focused it immediately enters insert mode. While I love vim, I've never wanted modal editing in a terminal

I do indeed live in the terminal (all day due to work), but tmux adds too much value for me to do all terminal management in Neovim (tmux session-management being what I use most). I've just encountered too many visual "glitches" in the Neovim terminal to rely on it for everything. That's not to say, however, that I never use the built-in Neovim :terminal.

> I thought it might be easier to only ever have one buffer open for a given file, instead of attempting to open a file in a given pane only to realize that it's already open in a different neovim instance

This is not a problem in my config:

    vim.api.nvim_create_autocmd({ 'FocusGained', 'BufEnter', 'CursorHold' }, {
      pattern = '\*',
      command = 'silent! checktime',
    })

Since `'autoread'` is by default `on` in Neovim, this seamlessly reloads the buffer if the underlying file has been updated on disk.

I'd be curious to hear more about how tmux helps you — I tried it and besides keeping a permanent session open on a remote server to me I didn't find much use for it compared to regular terminal tabs

I use it daily locally, and find it amusing how many only think of it as being useful on remote servers (not to invalidate your use-case -- I'm just contrasting my own use). As a precursor, I view UNIX as my IDE, of which tmux is a part: this IDE runs on Windows (WSL2), macOS, Linux, and Android (Termux). That aside, here are a few reasons I find tmux to be useful in this concoction of tools:

- Session management. I've written custom scripts for myself around this (zoxide + fzf). If you want to see how this can be used, look at ThePrimagen's workflow. I don't use his scripts but he has a good demo of how he harnesses sessions.

- Unified scrollback management - easily search the scrollback, yank it, etc. My favorite thing to do is to yank part of the scrollback, then `Prefix+B,=` to list everything I've yanked (think of this like a "clipboard manager" specific to tmux), select an entry, and press `e` to edit it in `$EDITOR`.

- This one might be a stretch, but I tend to try and use only terminal tools (without being utterly insane) because then tmux can be my "tiling window manager" no matter what OS I'm on. Oh, I have to use Windows for work? Not to worry, tmux runs in WSL2, as do most of my preferred tools, so I feel mostly at home even though I normally really dislike Windows.

- It's scriptable. Read `man tmux` and use your imagination!

Notwithstanding any of that, there are cons, the most apparent one being that I am limited to text-based tools this way. An example of this: getting images to work in tmux, though many modern terminal emulators support them, is a huge pane, so I haven't bothered.

For the curious (like me), here’s more info on bullet 1 (session management):

https://www.reddit.com/r/tmux/comments/1ch9tqp/primeagen_tmu...

That's very helpful – thanks for taking the time.

I think my problem is when I realize that I had unsaved changes open in a different neovim instance. If the file was not dirty in any other open neovim instances then I don't have the same problem.

This is what I love HN for. "Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should".

This awakens things I've been thinking about Neovim for a while now: now that libuv is embedded, there's really no reason not to use it as a cross-platform application runtime (except for the fact that that's horrific).

It's linked above (https://github.com/opencode-ai/opencode)

From the repo:

This is the original OpenCode repository, now continuing at Charm with its original creator, Kujtim Hoxha.

Development is continuing under a new name as we prepare for a public relaunch.

Follow @charmcli or join our Discord for updates.