- 133comments
- 184comments
- 33comments
- 218comments
- 58comments
- 11comments
- 44comments
- 71comments
- 241comments
- 15comments
- 237comments
- 35comments
- 17comments
- 51comments
- 9comments
- —discuss
- 167comments
- 146comments
- 24comments
- 12comments
- 3comments
- 89comments
- 174comments
- 16comments
- 71comments
- —discuss
- 15comments
- 280comments
- 135comments
- 148comments
Well I know what I'm wasting next weekend on now.
Glad I could be of assistance :D (sorry in advance for any time lost to Lisp fun times)
Fennel is a Lisp that transpiles to Lua.
One of Neovim's goals is to make Lua a first-class citizen. Eventually, it will be possible to replace your init.vim with an init.lua. Making an init script in Fennel sounds like a great way to bring Emacs ideas to Vim, like how Emacs' evil-mode brought Vim ideas to Emacs.
Recently, Neovim got an official client for the Language Server Protocol merged into master. All the example configurations[0] are written in Lua.
[0]: https://github.com/neovim/nvim-lsp
For some time, I happen to use a machine with very very meh CPU performance. Turns out, popular scripting languages are slow, except for Lua. (And maybe also Perl, didn't check yet.) I thought that JS has fast start-up, but some Lua scripts of mine that do file IO are finished in less time than Node's ‘hello world’.
I now wish people used Lua everywhere instead of JS, Python or Ruby. Some are doing desktop programming in JS, for personal productivity software, like Alfred alternatives Zazu and Cerebro. Eeeeh nah, productivity software needs to be fast. Would be lots better to do that in Lua. And it's certainly a better idea for editor plugins than using Python.
Fennel transpiles code to Lua so fast that it's feasible for scripting, even on my machine.
I believe also that Lua might be able to do true parallelism, via libraries. (Haven't tried yet, though.)
I build Lua programs in prod. I use fennel or moonscript as the frontend, and everything runs on openresty (cli tools using resty and servers using the full stack).
Parallelism is enabled by a data flow architecture on top on nginx workers (compare TPL Dataflow in C# or Intel TBB in C++).
Concurrency is enabled using coroutines (nginx threads). It's virtually impossible to write blocking code and that's without any async or other bs in sight.
It's really fcking fast. Like, some parts of the overall arch are rust, but in the real, io bound world there's virtually no speed difference. Of course safety is good. But you get types and other neat zero cost abstractions for Lua using Haxe.
This Dataflow architecture also benefits from openresty built in concurrency safe queues, maps etc with atomic commit and cross worker access. Everything feels so damn effortless. I didn't have to do any work on making it scale. Just tweak the number of workers knob and boom, almost linear benefit. That's for rust and Lua, both awesome at parallelism in this case.
Anyway, even though I never write pure Lua, I still think it should have won against python (man did we try, even riding that ML wave).
I'm in love, but me is not many.
What sort of queueing mechanism do you use? I’ve bee trying to get into OpenResty but there are few documented examples of that kind of thing, and anything that does Dataflow is interesting to me.
Bidirectional queues are built-ins in openresty[1]. The scheduler is project-specific and uses that.
[1] - https://openresty-reference.readthedocs.io/en/latest/Lua_Ngi...
I have been using guile on my rock pi to do multithreaded things (using guile fibers, which works over pthreads). It is not a big project, only an IRC bot. Heavily over-engineered with the goal of being able to process more IRC messages from more sources than anyone will ever need. It isnt usable yet, but it can handle all traffic a raspberry pi 4 can deliver which is close to 60 mB/s spread over 100 simulated channels. Currently each channel bot just tried to find the largest integer posted , so there are no IO bottlenecks.
Startup is instant once compiled, and compilation usually takes less than 0.5s depending on how much I changed.
Interesting to see. The Vim people at work are constantly harrasing us two Emacs users, claiming that lisp is old and silly, and that vimscript is good. Maybe change is acoming.
That sounds really strange to me. Even amongst major vim users and proponents I have never heard anyone say vimscript is good.
Maybe I don't get out enough.
Vimscript is good for setting simple configurations, but bad for large/complex software.
The Neovim team found that Lua seems to do both pretty well and has a fast implementation (LuaJIT), so they're trying to get Lua to be Neovim's primary extension language. Python and Javascript also seem to be popular languages for Neovim extensions.
In the official vote for Vim features, the top one was ‘stop extending Vimscript and improve Python integration instead’.
I'm a vim user, and the most attractive thing about emacs is that I don't have to write vs. I mean it really is that bad. Plus you have org mode, ivy, company, magit, and flycheck. There's plenty to be jealous about. Although you should be jealous that we have ALE and modal editing is far superior to the emacs defaults.
I'm the author, I've been in love with Lisp for years now (I'm a recovering JavaScript programmer) but refuse to leave Vim, Vim Script is absolutely awful for anything more than simple option setting in my opinion. Hence this massive detour into writing a plugin / library / framework to allow me to write better plugins.
I just wanted best of all worlds: My favourite editor with my favourite syntax without sacrificing any performance. If anything, my dotfiles should be faster now since there's less VimL which is damn slow to execute. I haven't benchmarked it though.
The Clojure world in Vim is getting better and better too thanks to various projects. My attempt at that is https://github.com/Olical/conjure
We also have really good s-expression editing plugins! Come on in, the water is full of parens :D
Standard Vim has support for Lua bindings. Does anyone know of a reason this wouldn't be applicable there as well?
Oh does it? Nice! I am a 100% Neovim user so I focus on that but if this works in Vim 8+ with minimal changes I'm totally open to pull requests to support / document it!
If I can find some time, maybe I will take a pass at it.
This is why I don't use neovim. VimScript is god awful (emacs lisp is also a pretty bad lisp imo), but this is just adding additional layers of complexity for no measurable gain in value. If I wanted to transpile to an equally bad scripting language and talk over RPC I'd just go become a front end developer (those web devs are out of control). I just want vim to start quickly, not crash, and generally get out of my way. Vimscript is good enough for any sort of scripting/plugins I want/need and I know it's going to just work.
It's a plugin. It is not shipped with Neovim.
That's a very low bar, which indicates you definitely aren't Neovim's target audience. If you're happy with Vim, carry on.