Glad to see you are already thinking of vim 9 and it is good to see the rythm of having a new goal ever year. I was personally waiting to hear more people comment on the ECMAScript (https:/ta.github.io/WasmExplorer//github.com/vim/vim/pull/5198) support before I share more details but here it goes.
Just one minor thought, have you thought about storing the intermediate Vim > script format into a new binary file (similar to how python uses .py and > .pyc)? > This is exactly what WASM (WebAssembly) is. Why not make WASM a first class citizen in Vim 9 instead? FASTER VIMSCRIPT wasm does a fabulous job here and was designed for this. Here is an exact quote from their github repo. https://github.com/WebAssembly/design > "WebAssembly is efficient and fast: Wasm bytecode is designed to be > encoded in a size- and load-time-efficient binary format. WebAssembly aims > to execute at native speed by taking advantage of common hardware > capabilities available on a wide range of platforms." > Currently the new function prototype only makes function fast. There will be lot more work to make rest of the features fast. While I would love vimscript to be fast I'm not sure if it worth it. I would rather have vimscript compile to WASM and then execute. This way we only think about making the runtime fast. There are also lot of WASM runtimes currently some of which even supports JIT and native compilation and other optimizations. You can try this website and see what native assembly code it generates. https://mbebenita.github.io/WasmExplorer/ PHASING OUT INTERFACES Lot of languages now supports compiling to WASM and this would solve the issue of having multiple language interfaces. Another option would be to use jobs and channels but currently someone still needs to write a small wrapper to take full advantage of this. Neovim has a remote RPC concept and official libraries for their languages and hence there is more abundance of the neovim plugins taking advantage of this and doing more complicated stuff then vim8 plugins. I personally don't use any of these interfaces but there are lot of people who use python plugins just so they can have the speed or use libraries that come with languages. WASM fixes this issues about supporting someones best language. BETTER VIMSCRIPT This is the one I'm worried the most. I would personally be against breaking the language compatibility as it would be pain for us to support as a plugin author. I don't think comparing javascript with vimscript on adding breaking languages is the right comparison. While most devs might write in the ES6 or newer they either compile it down to ES3 or ES5 so it works in older browsers or they compile it to both versions but give hints to browsers to only pick one of them so that it continues to work in older browsers. Here is an example: <script src="es5.js" nomodule"></script> <script src="es6.js" type="module"></script> Old browsers will only use es5.js because if type is not specified it automatically treats it as text/javascript and nomodule is not understood by them and they just ignore it. es6.js has type module so while it may download that file it doesn't know how to execute it so in terms of executing it becomes a noop. For mordern browsers, they understand nomodule so it doesn't download es5.js but understands type=module and treats it as javascript file and executes it. How would vimscript do this? Same for typescript, it compiles down to either ES5 or ES6 or some variant of javascript with mostly typings removed. Typing is also something I miss a lot in vimscript because as a vim plugin author I would most likely continue to use func instead of def even if def is faster if I wanted to support vimscript. If I really wanted it to be fast I would rather continue to use Python or lua interfaces or WASM. I personally prefer WASM>LUA>VimScript. Lua is a good alternative if it ships in vim primarily because the language it self is very much set and is very powerful with features such as co-routines allowing us to express async code in an easy way (this is actually my personal pain compared to speed of vimscript). To me I think vim9 should all be about WASM. This solves everything mentioned eariler in the thread and in a better way without too much work. Why? * It is fast, really fast. This will only continue to be better due to the energy the current industry is betting on. Create a compiler to compile vimscript to wasm * I can write in whatever language I want solving the language interface problem. WASM is most likely also officially supported by your favorite language. * WASI Interface https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/ Think of this as standard c library which is portable. * WASM threads https://github.com/WebAssembly/threads ex: using immutable data structures to fuzzy search effeciently by sharing between threads. * WASM webgl https://rustwasm.github.io/wasm-bindgen/examples/webgl.html Similar to popup window but imagine getting a raw canvas to draw in gui vim ex: rendering markdown files. Who knows might be one day we will get 3d games running inside vim :) * WASM c api https://github.com/WebAssembly/wasm-c-api Once this takes off I'm hoping it will be easy to swap out runtimes into a faster runtime. On Tuesday, December 17, 2019 at 10:13:30 AM UTC-8, Bram Moolenaar wrote: > > > Christian wrote: > > > On Di, 17 Dez 2019, Bram Moolenaar wrote: > > > > > Vim 8.2 has been released, so what is next? > > > > Wow, respect for the well-thought roadmap. I like that approach, but > > this sounds like an awful lot of work, but looking forward :) > > Yes, it's going to be a lot of work. But it's the kind of work I enjoy > doing. > > > Just one minor thought, have you thought about storing the intermediate > > Vim script format into a new binary file (similar to how python uses .py > > and .pyc)? > > It might help a bit, but only for large files. Quite often locating and > opening the file takes longer than parsing the contents: CPUs are very > fast these days. And then we need to read the original file anyway if > the compilation changed. Not sure if it is worth the hassle. It would > help more to avoid searching for files and to postpone work by using > autoload scripts. > > -- > Facepalm reply #9: "Speed up, you can drive 80 here" "Why, the cars behind > us > are also driving 60" > > /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net > \\\ > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ > \\\ > \\\ an exciting new programming language -- http://www.Zimbu.org > /// > \\\ help me help AIDS victims -- http://ICCF-Holland.org > /// > -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/194a98cf-f846-427d-93b2-d9c381cf7944%40googlegroups.com.
