You could ask the same question about why he decided to make the async api and terminal mode incompatible with existing equivalents in neovim. Sadly, the ecosystem seems to be splitting more and more between vim and neovim.

My impression is that Bram is trying his best to outcompete neovim.

That goes without saying, and it's just unfortunate that he chooses to compete rather than collaborate

Competition is good, and it’s the reason why Neovim was created in the first place!

I mean, the reason is that those async patches were just sitting in the queue for a year, and by starting Neovim, they could get them in right away.

Then Bram started competing afterwards.

Those patches were broken to begin with when submitted to Vim, and never got fixed until NeoVim was forked out of the blue. People generally don’t know the details of this, and blindly blame Bram.

Why did it take neovim being forked to get those patches fixed?

Is there evidence that the fork was the root cause of that action. and not a mere coincidental correlation?

> building a new language from scratch is just not worth it

Seems this has been said about every single language ever (except the first I guess?), even languages as Golang and Rust have gone through a phase where many question "why even build a new language when X does Y and Z perfectly fine already?", and then they end up really popular anyways as they solved some slice of problem(s) is a particular way that many like.

For every golang and rust, there's probably tens or hundreds of programming languages that will never end up popular. I guess that is to say the probablity that vim9script will succeed isn't high.

And golang initially started off as a replacement for C, and then pivoted because they couldn't achieve that purpose ... now, it's touted for simplicity. When Rust was a pet project of Graydon, it looked VERY different to what it is right now. My point is that vim9script as it stands right now doesn't solve any real world use case that lua wouldn't be better suited for. Maybe vim9script will be better for something else entirely in the future, and that will be, as you describe something people may like. But right now we don't even know what that is, and surely that can't be a reason to decide to go explore language design in such a large community such as the one vim has? It is definitely Bram's right to do so, but I fear that people will rather move to neovim or vscode or emacs than learn and write vim9script, and as a user of that community I think that would be bad.

Also, it's not like people were proclaiming vimscript was awesome you know. There's a talk from one of the core devs of vim-lsp on YouTube [1], on features of vimscript, and literally in every slide the presenter caveats the vimscript feature in one way or another. I find it hilarious, it's a perfect example of the frustration of when writing plugins with vimscript.

[1] https://www.youtube.com/watch?v=7fcJWwl1-SU

I think there is a big difference between designing a new freestanding language vs one designed for extensions/plugins. The freestanding languages are free to iterate and incorporate novel, wacky ideas. An extension language should do the best it can to avoid rocking the boat.

I have a dear place in my heart for tiny focused languages and think if Vim had stated they were going to suddenly make Wren, Gravity, Janet, etc first class languages, there would be less reluctance than a new thing.

Nate's Law says, "Only an idiot expects anybody to use their new language". First corollary is "All new languages are designed by idiots".

Very, very rarely, lots of people find reasons use a language designed by (such) an idiot, anyway. We are lucky when the language is not terrible, because how good it is even more rarely affects whether it will take off.

In practice, languages almost always ride to popularity on the back of something else. C rode Unix, C++ rode C, Java rode Sun Microsystems' $billions and the promise of getting off Microsoft's framework-hell treadmill, C# rode .Net, Javascript rode HTML (and then web services because the same people were coding both, at first), Go rode Google and Docker. Lua got where it is by being really easy to embed, and being simple, powerful, not weird, and (lately) fast.

Python got there mostly the hard way, but also by being easy to embed and to extend with C ABI-compatible plugins, despite being weird and extra-super-slow.

Amazon, BTW, might be unique among IT behemoths in not hustling its own walled-garden language. (Or maybe I just don't know about it.)

I think there is some concern among some people in the rust community that amazon will gain more influence over the steering of rust to guide it towards it's own walled garden.

I don't share that sentiment and I personally think that as amazon adopts rust it will gain rust community principles. But I'm probably wrong.

I don't think making a new language is so much more crazy than making any other piece of tooling. Obviously, it's going to have to have compelling advantages to convince people to move from the tools they know and love. But, if you're putting in the time, you probably imagine you have some compelling advantages. Rust is an obvious example of this, as is something like Java, or C++.

Java and C++ won the lottery. It is far too early to tell whether Rust will, or will sink out of sight, like Ada. History predicts the latter.

I think you're underselling Java and C++. The JVM idea is clever because it means you do all the portability stuff as part of the language, rather than asking programmers to do ifdefs for every platform. Making it a safe, memory-managed language is clever because most programmers don't care about the performance hit, but they do care about the bugs.

C++ has equally compelling advantages. If you write less code, you get less bugs, and more work done at less eyeball-hours. If you can do that 'zero-cost', with abstractions, a lot of people who care about performance are going to find that really exciting.

Rust basically continues this pattern.

Obviously you have to sort of win the lottery as well, because you need enough people to bring the language from clever-research-project to useful industrial tool, but I think the fundamental point is that successful languages have both luck, and a killer feature.

I imagine all of these languages will sink out of sight at some point, because it's just clear that as a culture we're in the very early days of living with computers, so these languages are a bit like bone needles or flint axes. I still think the innovations contained in them will go on to inform future development.

Go and Rust compared to vim script is an Apples to Space Shuttle comparison.

Yes, if you compare their functionality, performance and on a bunch of other attributes sure. But I'm not doing that, I'm comparing them on the attribute of "new programming language", which all of them have been at one point or another.

It might just have been that Vimscript didn't go the way it was intended to, or people moved towards different paradigms to doing modal editing in a sane(r) way, but maybe in some alternative universe, Vimscript became a popular scripting tool.

It was the result of a poll:

1 - https://groups.google.com/g/vim_dev/c/__gARXMigYE/m/iskHVwgU...

2 - https://github.com/vim/vim/issues/3573

Vim and Lua evolved in similar timelines. It's plausible that vimscript was written without him knowing Lua was a choice.

I don't know about the timeline of Vimscript in particular, but seemingly Vim was first released in 1991 while Lua first 1993, so by the first release of Lua, Vim already existed by then. Not sure when Vimscript appeared though.

On other trends (Google Trends to be specific), search volume for Lua only became larger than for Vim in 2004, with Lua hitting it's peak in 2009. Search volume for Vim would have been much larger before 2004 if we had a single search engine everyone could have used, but hard to know in afterhand I guess.

vim9script was most definitely written way after lua was integrated into neovim, and well well after lua was popular as an embedded programming language choice. While it is plausible that the idea for vim9script was conceived without him knowing Lua was a choice, it is unlikely that work on it was started without Bram knowing. There's even people that have commented on the google groups as far back as 2016 about neovim's use of lua. It's unlikely that Bram wouldn't have seen that.

vim9script, though, is the evolution of vimscript, and has some amount of backwards compatibility, short-ish migration guides, etc. Initially choosing an embedded script language and migrating to a new one are fairly different scenarios.

Vim already could be compiled with Lua, Ruby, Python with their own respective vim APIs. How is it possible that he didn't know he could use an established programming language for scripting?

Lua and vimscript are both the same age; Lua came out in 1992, and vimscript in 1991, so it would not have been an obvious choice. I think that vimscript has the same problem as shell scripts: there are a lot of editor/shell commands, and they didn't want to introduce a special syntax for distinguishing between the language proper and the editor commands.

I don't think that vimscript is that bad. What i don't like about are the scope rules, i.e. special prefixes for function arguments, locals and globals. Also the call keyword is required for function calls and let keyword for assignments.

Anyway, Python can be used as a vim extension language, i am not sure if Lua is superior in this respect to python.

Lua is probably way, way faster. Does that matter? It could matter. It would be awful if it did matter, and you chose wrong.

What would cause such a performance difference? I thought that both lua and vimscript were interpreted languages. (asking as a long time vim user, really curious about it)

Lua is JITed nowadays. Python has numerous design gotchas that force it to be slow. (But Numpy manages to work around many of them, and be fast.)

Interesting. With java the just in time compiler starts to work, if you have iterated several thousand times over the same spot (java cmd line option -XX:CompileThreshold sets this, the default 10000 by default for hotspot server) Interesting if lua has a similar thing... have to learn more about it.

JITs are more-or-less portable now. Lua's, like most, probably came originally from some Javascript's. But of course they all trace back conceptually to HotSpot in the '90s. Even Guile Scheme is JITted now, though it probably shares no code with the others.

The term "JIT" is getting abused lately to describe what happens to users' eBPF code that runs in the Linux kernel, and Wasm that runs in browsers. In those, all types are known statically, code is compiled to a portable form offline, and transcribed to machine code before any execution, and none of the runtime instrumentation, analysis, and progressive rewriting occurs.

Correction: cpython, the reference implementation of python, does not have a JIT; however Pypy does have one.

I think he does not like to go with the flow, but instead implement things the way he thinks best suited and best performant with Vim. I don't think he cares about NeoVim.

Vim started in 1991. I don't know when VimL became a thing, but there's a serious possibility that Lua wasn't a great option at the time, and the only established embeddable language might have been some lisp or Tcl. I am not super versed in this area though.

What is NIH syndrome?

Edit: got it, its called "Not Invited Here" syndrome.

“Not Invented Here” is how I’ve always known it.

This is the correct one.

not in house.