-
|
This thread is a continuation of the following discussion:
Making plugins should be easyPlugins in any system or project are supposed to be a relatively easy way to extend or modify existing functionality. And I hope I don't have to explain why Lisp dialect is much more confusing and alien to most people compared to imperative and object-oriented Lua. Most people have never touched Lisp and aren't fond of learning it just to configure their editor ('cos we are also replacing TOML with Scheme; wow, so many great choices). Answering @rsmirnov90
Except we aren't talking Node or Python. We're talking about Lua. Its ecosystems is doing just fine.
Because there is already a ton of legacy-corporate-LTS-domain-specific horseshit. People don't want to learn another domain-specific and niche language just to configure their editor. I honestly don't understand what's so hard to understand here. Lua is easy, stable, battle-tested and it just works. That's something you really-really want from a language you are forcing upon external developers and users of your software.
At the "Schemes are stupidly popular" point.
Wooow, bold claim. You must be really delusional if you think that in 2025 Lisp and Perl are "de-facto defaults for extensions for UNIX-based software". Was there every any poll about what Helix users think would be a good choice for a plugin language? No? Then please don't ever bring the "stupidly popular" point anymore. Sure, blindly following masses is not a good way to run an open-source project. But choosing Lisp dialect for plugins is taking it too far.
And see how you had zero concrete arguments against Lua? I understand that you are emotionally attached to you language of choice, but it's best to be able to (1) support it with arguments and something factual and (2) understand that there are moments that you have to be pragmatic instead of opinionated.
I hope that I've already answered your questions about popularity and don't have to take whatever this is seriously.
You know what else has good interoperability with C? Rust. That's such a stupid argument, I honestly have no words. If you want to shill Scheme so badly, at least choose arguments that don't make it look like you have no idea what's you're talking about. Really confusing comment indeed. ExtraComment about why Scheme is a bad choice:
A lot of people in the same matrix channel did raise concerns about Scheme's user-friendliness, but this has been ignored. All because tree-sitter runtime queries are Scheme, so there's a bit of an elegance of reuse to it. |
Beta Was this translation helpful? Give feedback.
Replies: 20 comments 88 replies
-
|
Scheme is awesome. Helix is awesome. If people like Helix, and they like it enough to use extensions, and they like it enough to want to write an extension - they can learn enough Scheme to write their extension. It's not like Lua or Scheme are complex languages, Lua basically feels like a Lisp without the macros. If you're really fuming over it, do like Racket and reimplement Lua in Steel. You'll survive. Edit: Also, Lua really doesn't have an ecosystem. It has popular libraries and such but you're almost always vendoring them yourself and downloading them from GitHub/some tarball somewhere, and there's no real way to gauge what people are actually using. It's a great language though. |
Beta Was this translation helpful? Give feedback.
-
|
I believe the misconception here is about open-source meaning: if you're not happy with the developers choice, I think everyone is free to fork the project or (better) start to work on a PR to support your scripting language of choice. |
Beta Was this translation helpful? Give feedback.
-
Ending your post with snark like this as a reply to somebody who isn't a maintainer, is at the very least distasteful. Your post could be taken better in good faith without this.
Technically it isn't scheme, it is a form of sexps, but the
Most people aren't fond of configuring their editor at all. If you have a tiny TOML as a config, your config will remain tiny with a different syntax. And as of now, the Steel integration supports both, and I'd imagine
And I understand that people don't want to do that and why. But the reverse is also true, the maintainers right now want to have Scheme so that they can enjoy and maintain an OSS(!!!) project the way that they like. Scheme is easy to parse and mold to your liking, that is the power of this """niche""" Lisp. It's okay for people to not use the popular option in the OSS world. Can you see how your reasoning applies conceptually the same to (neo)vim w.r.t. helix? Verb -> action is the unpopular option( Your post in the |
Beta Was this translation helpful? Give feedback.
-
Yes, that was too much... I am sorry. |
Beta Was this translation helpful? Give feedback.
-
|
I think it's a fine choice for a language. It's just as niche as helix is but people learned to use that. Scheme is not a difficult language and is rather intuitive and elegant. If you just want to use plugins, you don't even need to touch it for the most part. If you want to write plugins, I don't think the language is going to be a large barrier and I think if it was, you'd also need to learn other things anyway. Also, maybe it's worth pointing out that emacs uses lisp which is fairly similar to scheme at a fundamental level. It seems to work out well for them seeing that emacs is one of the most configurable and extensible editors out there (emacs is your OS). |
Beta Was this translation helpful? Give feedback.
-
|
The single question in my head is: why make such a fuss about it? Does this decision really matter, if you think about it? Helix already has a fine configuration system through the static TOML files. Most things you want can be done in there. So if a user really needs more out of their config, they probably know what they are doing anyways, at which point they should know their way about getting accustomed to a language they have never seen before, trivializing the difference between either language. If we really need to compare scheme to lua, they are really similar if you think about it: they are both lightweight scripting languages, both lua and steel are meant to be embedded into a larger system/application, they are both procedural and functional languages etc. the only major difference is the syntax (which imho is a small barrier to overcome). For what it's worth, you still see, to this day, that people are configuring their software through Lisps. Be it their Emacs config, packaging some software with guile or even defining their entire OS with it. At the end of the day, they are both great tools for the job of writing editor plugins. Lua has worked for Neovim, and Scheme will work for Helix. There has been a lot of effort put into writing the engine for this, so our best bet is to improve upon that. I think that our time/effort is best spent addressing actual concerns, rather than "is this language the ultimate perfect choice?" If this was a PR for configuring hx with an esolang like BQN, I think you'd have a point, as such languages handle concepts the average programmer has never seen before, and can become a frustrating experience. But the language chosen here, when you get used to the paren/indentation style, is actually very ergonomic and easy to read and reason about. |
Beta Was this translation helpful? Give feedback.
-
|
Exactly. I think any motivated developer looking to write a plugin is not going to be put off by learning a new (and very small) language at all. This is something developers regularly do anyway. |
Beta Was this translation helpful? Give feedback.
-
|
Go write a plugin system in lua for helix yourself and open a PR or maintain your own fork. Give some respect to the people writing a plugin system in Steele. Stop telling others to do things for you. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, reminds me of "Talk is cheap, send patches" 😆 |
Beta Was this translation helpful? Give feedback.
-
|
what the reason to write it and split the community? and this PR will not accept? it will all in vain |
Beta Was this translation helpful? Give feedback.
-
|
I think a lot of criticism comes from the assumption that users will need to write a lot of scheme, like how they need to write a lot of lua in nvim. This assumption itself may be the cause of all this fuzz. And about it not being the popular choice, I'd say learning helix motions for a vim user is harder than learning a new language. |
Beta Was this translation helpful? Give feedback.
-
|
Even with neovim, you can still get away with a couple dozen lines of vimscript, just setting some options (less and less as time goes on, the defaults are getting better and better) and running a couple |
Beta Was this translation helpful? Give feedback.
-
|
ppl had to invent fennel because they wanted to use lisp in lua, go figure... /jk |
Beta Was this translation helpful? Give feedback.
-
|
You can fork helix. And make plugin system with lua. Let's see the effort to make something similar in your free time. Like the author of the Steel PR did. |
Beta Was this translation helpful? Give feedback.
-
|
I don't have anything against the author of the PR. Doing something this big in your free time is indeed an achievement. The only complain I have is about Helix's maintainers choosing Lisp. This has nothing to do with the person integrating Steel. Voicing that complain in the PR thread was out of place, I get that. |
Beta Was this translation helpful? Give feedback.
-
What I mean is you can really start new pr to propose lua as plugin system lang. And if the main repo did not accept it. You can maintain your own fork. It is an open source project. |
Beta Was this translation helpful? Give feedback.
-
|
The plugin system was intentionally designed to be modular in terms of what language it uses. I don't know if that's still the case, but that's how it was envisioned. So someone could support Lua in their fork easier than what it took for Neovim to support Lua. But I'd suggest waiting and seeing how the Lisp experience goes since I honestly don't think it'll be a deal breaker. |
Beta Was this translation helpful? Give feedback.
-
|
Emacs used lisp for decades and have wide, established ecosystem. |
Beta Was this translation helpful? Give feedback.
-
The long term success of an open source project depends on how easy it is for potential (new) developers to contribute. Forcing people to learn a new language is a hurdle that should be avoided if possible. |
Beta Was this translation helpful? Give feedback.
-
But I also think that Rust plugins fit Nushell well, because they don't handle "text" or stdin/stdout, they handle "data" which is much richer most of the time, which requires a more robust interface between plugin and shell. They handle a whole bunch of things which traditional shell plugins don't do: signals, messages, JSON/msgpack, rich error types, etc. But I think that a text editor such as helix does way better with the "emacs approach". |
Beta Was this translation helpful? Give feedback.
-
|
It's the "bums in seats" argument. I think ultimately the reason why python, Lua and JS persist as the main languages is purely down to their popularity driving adoption. At the start of this thread one of the arguments against a more mainstream language was, and I'm paraphrasing "Half of the plugins will be written by middle schoolers and not maintained". That's fine. Hell, it's desirable. In every extension ecosystem, the projects most people find most useful rise to the top and are generally maintained. Others might be useful, but half baked, so someone will revise the idea and a new plugin will emerge. It's how it's always been. You go where the people are, arguably it's more important than some niche adjacency benefits from choosing another language. The bottom line is - if you choose python, JS or Lua there will be more plugins in the ecosystem, simple as that. With scheme, there will be less. There are no guarantees of long term support with any of these options, so go where the people are. I'm not losing too much sleep over this, and can't wait to have plugins be part of Helix. I'm stoked the scheme PR is shaping up and getting closer to release. But still, it's not seeng the wood for the trees and won't do anywhere near as much to encourage helix adoption. |
Beta Was this translation helpful? Give feedback.
-
Nushell plugins are executable applications that communicate with Nu by exchanging serialized data over a stream (much in the same way VSCode plugins do). The API is fast, robust and mature and well suited for Helix's use case. The protocol is programming language agnostic. |
Beta Was this translation helpful? Give feedback.
-
Most of web programmers in the world was using PHP or ASP back then, and those who doesn't want to learn JavaScript were left behind. I got a quote for this comment |
Beta Was this translation helpful? Give feedback.
-
|
See #3806 (reply in thread) about serialization above |
Beta Was this translation helpful? Give feedback.
-
|
I'm excited to use lisp for plugins in helix. Bring it in! |
Beta Was this translation helpful? Give feedback.
-
|
Here’s my two cents. I believe in the Maker’s choice. So, if the developers want Steel or Lisp as Helix’s plugin language, no one has the right to comment on that unless this person starts its own PR. That said, I personally think choosing Steel or Lisp as the first language for plugins is not a great idea. Lisp is very different from most programming languages, and I’m pretty sure it’s not used anymore except in very specific cases (like Emacs). Neovim chose Lua. Vim started its own Vim9 script language. After a very short time, we have amazing plugins in Neovim with quality equal to or even better than their Emacs counterparts that have been developed for three times longer. So, in my opinion, Steel or Lisp in Helix will work, but it will slow down plugin development (and by extension, the editor usage). |
Beta Was this translation helpful? Give feedback.
-
|
For those who are interested in using Lua for plugins, it seems like the Steel plugin architecture might actually make that feasible without too much trouble: #8675 (comment) I can easily imagine a generic "Lua plugin" build with |
Beta Was this translation helpful? Give feedback.
-
|
I apologize in advance if this is a dupe, but I want to reply to this. As someone said, Lisp syntax is essentially "just S-expressions", so there must be a Lisp dialect (if there isn't, it can be emulated with macros) that supports "imperative semantics", like this: ; I took some "artistic license", so this is hypothetical
(defun compute-pi (iterations) (
(let sum 0.0)
(for k (range iterations) (
(let term (/ 1.0 (+ (* 2 k) 1)))
; ternary operator, but more readable
(+= sum (if (is_even k) term (- term)))
))
(* 4 sum)
))Written that way, Lisp seems somewhat beautiful to me:
(unfair tangent 😅) BTW, Lua doesn't have a ternary operator, so it must be emulated like this: ---@generic T
---@param condition boolean
---@param a T
---@param b T
---@return T
function if3(condition, a, b)
if condition then return a
else return b
end
endWe could use Don't get me wrong, Lua and Lisp are both cool! |
Beta Was this translation helpful? Give feedback.
-
Maybe it's just me, but the Lisp example is the clearest and easiest example to understand of all of these, and by that I mean even if it was shown to someone with no programming experience at all. Not to mention there are a number of different ways you could express that same function in lisp (or steel). At the end of the day that's just simple syntax though, and lisp doesn't have much of it. Any developer with even a little bit of experience will be able to figure out the very simple basic syntax of a Lisp. Also, and this is more personal opinion, but lua is simply a much worse language for this type of thing. Even when I used to use Neovim I used Fennel to write my config instead of using Lua directly. |
Beta Was this translation helpful? Give feedback.
-
|
That being said, steel is interesting and I think a good choice, but the best choice would likely be a completely new lisp DSL (whether made with cl, racket, scheme or rust) built for the specific use case of writing helix plugins and nothing else. Or even DSL made with Steel. |
Beta Was this translation helpful? Give feedback.
-
|
My opinion: Lisp is a non-technical programming language. If you don't want to talk about types and variables, but about problems, solutions, data and algorithms Lisp is a good choice. Most IT people love the technical aspect of programming. That is why they don't like Lisp. |
Beta Was this translation helpful? Give feedback.
-
|
The choice of a plugin language differs form other architectural choices in the way that it defines a "user" interface. Very similar to a UI. The consumer are potential new contributes to the project. The goal should be to attract us much developers as possible who are willing to sacrifice their little free time in order to improve Helix. To lower the ease of use, the plugin language choice is crucial. Who are these potential contributors? With what languages they are familiar with? A poll would tell us more. A side note: it seems there is only one active core developer left in the project. How to grow the active community? A lot can be learned from successful projects like Neovim. The plugin language choice is definitely an important part of the answer. |
Beta Was this translation helpful? Give feedback.
-
|
That’s precisely my point of view! The Helix developers chose Scheme (Steel) because they want complete control over it, including embedding the virtual machine. However, the downside is that everything needs to be done in-house. For instance, if you need a library to correctly parse UTF-8 strings to create a nice plugin, you’ll probably have to code it in Steel yourself if the functionality is not exported from the editor core. Similarly, if you need a library to interface with a web service using a default API, you’ll need to code the glue code yourself. On the other hand, if a more common plugin ecosystem were selected, you could rely on a much more robust background. Therefore, although the plugin system will allow extending the editor, I’m not convinced that we’ll see great applications like we’re seeing in Neovim. |
Beta Was this translation helpful? Give feedback.
-
|
Plugin system prototype for Helix #13945 . Make Plugin with wasm/lua. |
Beta Was this translation helpful? Give feedback.
-
|
Complete Report: Implementation of the Plugins/Scripts Module for the Helix Editor |
Beta Was this translation helpful? Give feedback.
-
|
It seems, that many people are not satisfied with the official plugin system choice. Now someone comes up with an alternative solution: Lua+WASM: #13945 |
Beta Was this translation helpful? Give feedback.
-
|
I don't know if you people are a vocal minority or not, but I for one think Lisp is the right choice for plugins. If this gets done right, Helix will blow Emacs right out the water. |
Beta Was this translation helpful? Give feedback.
-
|
Emacs took a long time to enable compilation for speed improvements. Developing a JIT compiler is extremely challenging. Before native compilation, many aspects of Emacs designed for modern IDE use cases were extremely slow. Steel is a relatively young interpreter (it hasn’t even reached version 1.0 and has only 39 contributors). It would take an incredibly long time for it to reach the maturity level of something like Lua. Lua, for instance, has LuaJIT, which produces remarkable performance. I have no idea how long it will take for Steel to be able to generate compiled code. Until then, any “heavy” task will be slow if implemented within a plugin in Helix. |
Beta Was this translation helpful? Give feedback.
-
You could use rust ffi like that scooter plugin for anything like that. Plus unlike emacs, helix has alot more perf heavy features in core. |
Beta Was this translation helpful? Give feedback.
-
|
I understand the skepticism of the decision for Scheme. But Let me say my personal opinion. Most modern programming languages also bring a mindset and a way of thinking. You can call this a bubble or a bias. When you are in such a bubble, you can compare things, that are also in your bubble. You can say, Python fits better as an extension language than Java, because both are Object Oriented imperative languages. But you cannot compare two languages that are not in the same bubble. The question what language is appropriate as an extension language is as legal as the question what paradigm is appropriate. Functional programming, declarative programming, procedural programming are sound alternatives to object oriented programming. I think, nobody wants to question this. The problem is, once you decide for a paradigm or a way of working, which is not mainstream, you enter a world where nothing is mainstream. By deciding for Steel, the Helix developers did not only make a decision for a programming language. They decided for concepts. In my experience they made a good decision. But of course, this is hard to understand if you have only ever used mainstream languages. Once the decision for an approach is made, there are not many options for a language. I would also have preferred another language from that spectrum. But I think Steel is a great choice. I am more than happy with Steel, and I think, there will be enough people who are enthusiastic about Steel to keep that eco system vibrant. I recommend everybody to buy a textbook about Scheme if you consider doing extension development. It is impossible to have an opinion about Scheme if you have not systematically learnt what Scheme is about. A few Hello World examples cannot teach you this. Before criticizing Scheme, please try to understand, why someone would like to use such an exotic language. |
Beta Was this translation helpful? Give feedback.
-
This is not about choosing a language you like “because,” but about choosing a language that will describe the extensions. You do this based on your needs and limitations. Your main limitation is the entry threshold. Your task is to minimize this threshold as much as possible. Speed is also important to you—because if the extensions work slowly, then what's the point of having them at all? Only a handful of people know this language (Steel). For example, I'm definitely not going to learn a separate language just to configure some editor. LUA is quite simple, with an extremely widespread concept similar to JavaScript (do you know how many developers use JavaScript?). It supports JIT compilation, can be called from anywhere in the program, and has proven itself to be one of the best languages for embedding. LUA is quite widespread, from game platform scripting to machine tools and programming equipment such as mice and keyboards. It is not a dead language. The higher the entry threshold, the fewer extensions you will have and, consequently, the less chance you will have to compete in the market. We must live not in a world of illusions, but in the real world, where there are needs and limitations. |
Beta Was this translation helpful? Give feedback.
-
You say this like they're all bad things. |
Beta Was this translation helpful? Give feedback.
-
do you think that product developers want their product to be less successful than their competitors' or to fail? Do you really understand how the market works? |
Beta Was this translation helpful? Give feedback.
-
If the market is omnipotent, lisp will not continue to revive |
Beta Was this translation helpful? Give feedback.
-
|
I don't think the goal of the project is to compete in a business market
(terms like "competitors", "market", suggest a business environment).
Widespread adoption is nice to have, but it should not be *the* goal.
…On 9/5/25 09:46, Andrew Avsenin wrote:
do you think that product developers want their product to be less
successful than their competitors' or to fail? Do you really
understand how the market works?
--
Marco Dalla Stella
https://marco.dallastella.name
|
Beta Was this translation helpful? Give feedback.
-
so, then you don't understand what it editor and how to have it success 🤷♂️ Helix already has an entry threshold, but increasing it even further by reducing the number of extensions — are you really doing this editor any favors? |
Beta Was this translation helpful? Give feedback.
-
|
This editor is opinionated and I love all its opinions. |
Beta Was this translation helpful? Give feedback.
-
I did just that, switched to neovim I like Helix as an idea because of its simplicity, but I found it lacking in expandability. I'm definitely not going to learn a separate language for an editor that I don't need in other situations. I already know too many programming languages |
Beta Was this translation helpful? Give feedback.
-
|
If we want to talk about real world, I can share my view and experience. I use Emacs on a daily basis for work for about 10+ years; I program in Lisp/Clojure, so I can easily write Elisp if needed. Do I ever wrote a plugin/library for Emacs? No. There are a lot of VSCode users. How many of them write extensions? I bet the percentage is less than 10%. I think the same goes for NeoVim. Helix doesn't have a plugin system at the moment, and this didn't prevent the adoption for the current user base. I think you have to be highly motivated to write your own plugin and, if you are, learning a simple (Scheme is simple) language won't stop you. People doesn't write plugins because the plugin language is easy or largely adopted, they write plugins because they need/want them. |
Beta Was this translation helpful? Give feedback.
-
|
@mdallastella but how much does plugins vscode have? Less obstacles - more chance to get support in niche solutions |
Beta Was this translation helpful? Give feedback.
-
|
I'm gonna add my two cents, as a good-faith user who loves Helix. It's my favourite piece of software. I'm here, so of course, I'm more technical than "average" people, but I'm not a dev, and I preface this to make clear where I'm coming from. On the language side, I actually love lisps and don't think Steel will be that much of an obstacle, but that's not the point of this comment. This thread was incredibly discouraging, and the comments here do not reflect well on the health of the project. For better or worse, Helix has positioned itself as a player in the editor space and as a community project. There is no indication whatsoever this is more of a personal project that happens to be open source, or a project for a limited audience (beyond the obvious limitation of audiences who use text editors). In fact, it is this very positioning that brought me to Helix and with it to the wonderful world of actual terminal workflows and TUIs, and many others. And Helix has almost everything it needs to be the best of the best. It has amazingly talented contributors, professionals and enthusiasts who dedicate so much of their free time to this, with high and technical standards, which is every bit what has allowed it to be the tool that it is. In that light, the responses to the grievances expressed here have been entirely shocking. OPs comment was entirely too sarcastically worded, which is no way to invite civil debate. However, the discussion rather quickly left those original points behind and attempts at thoughtful conversation were made. Despite that, repeatedly, the attitude has been dismissive; not only dismissive, but very rudely so. And I dare say that this is bad. It is true that Helix is open-source and everyone has the freedom to fork it, as indeed some have. It is also true people are free to choose other tools. And similarly, many other points made have complete merit: the maintainers are free to make free choices, including entirely arbitrary ones if they wanted (not what they're doing); Helix doesn't need to aim for mass adoption, it has every right to aim for a niche audience. Where I see a problem, and please don't take this as me being entitled, is that whatever Helix's beginnings, it has grown very large. A big part of this is its many technical merits, but not only that, it does market itself (it has a very nice website and calls itself "the post-modern text-editor"), and the community markets it in its name too. This means many people use it as their daily driver, perhaps even for work. While obviously customer support is not something maintainers should aim for, I believe the community in and around Helix could be much better if there was clear communication. By this I mean, if Helix wishes to be a small, niche product, by all means. That is more than fine. But, as users, and even as developers, it would be good to know that. It means we can all make better decisions. However, if Helix does intend to be a more significant product, something in the same arena as Neovim, then it will require community participation at all stages. Maintainers have already expressed being overwhelmed by the reviewing demands; I can only say that's a matter of course. The scale and quality of such a project is not something one, two, or three people can keep up with on their own. And if that is the desired direction, then some kinds of responses in this thread are very counterproductive; no, they are rather where community projects go to die. Helix deserves better. Currently, I do not, and I believe the broader community doesn't either, know where Helix is going or what the thought process is. Many of us would be more than happy to do everything to support the vision: it has made an amazing piece of software. But for that, knowing what the vision is is necessary. Similarly, the kind of complaint that spawned this thread will likely continue, if not for Steel plugins then for some other issue, simply because it is not clear whether Helix will be a good fit for someone in particular. Those for whom a given issue is a deal breaker would know to walk away or fork immediately or whatever, saving everyone's time and emotional energy. As for myself, I love the project dearly, and I am learning Rust if only so I can understand it better. However, if it intends to be a community project, and if some attitudes expressed in this thread continue, then I know it's only a matter of time before it's unusable. I would like to not keep putting my eggs in that basket only for it to collapse under it. Not, again, that I'm owed anything by anyone here: that's my problem, and I'm insignificant to this whole thing. Thank you kindly for your time. I appreciate you all. |
Beta Was this translation helpful? Give feedback.
-
|
https://github.com/helix-editor/helix/blob/master/docs/vision.md |
Beta Was this translation helpful? Give feedback.
-
I have to disagree from the very start. Lisp isn't any more complex or difficult than Lua, especially if using a dialect specifically designed for simple configuration. And "learning" lisp for simple configuration isn't difficult, the language itself is incredibly simple, without many keywords or weird syntax to learn. Your initial arguments seem to stem entirely from a lack of understanding about what Lisp is, and an overcomplication of it within your own mind. |
Beta Was this translation helpful? Give feedback.
-
The entire sentence is: "I'm responding to a claim that compares helix to macrumors and saying that criticism isn't allowed.", the exact opposite of what you take it to be. Carry on, Arstotzka! |
Beta Was this translation helpful? Give feedback.
-
|
Many people, including myself, have a false-dichotomy misconception. I'll outline some properties of notation so that everyone is on the same page:
|
Beta Was this translation helpful? Give feedback.
-
|
I think going with an archaic 70 years old lang syntax in 2026 is a pure dev crime. Even if you ignore the fact the original Lisp design goals were mostly todo with logical programming, natural language processing, expert systems etc near-AI related edge use cases (a battle clearly lost to neural networks and statistical AI machine learning approach, likely marking the end of any future developments in that direction anyways), I don't think the main issue here is the Scheme vs other lang. I think the main issue with helix is a FOSS project being run like a private company. Some of the methods are straight out of a corpo handbook. Zero communication. Ignore feedback. Zero regard to community opinion. Going with widely unpopular decision. Core features strictly limited to those the maintainers use themselves only. Selfishness will kill this world. In fact it already has to a good extent.. As for the plugin lang, it is clear Scheme only landed because some of maintainers have very warm sentimental feelings toward Emacs and its Elisp ecosystem. Not for any other reason. Fear of going with other languages because they may die while picking the language as good as dead at this point, based on a package maintained by a single dev. Not going with native Rust plugins because this will require Rust knowledge from plugin devs while enforcing obscure Scheme knowledge on the same plugin devs. Not going with WASM of fear to increase the footprint as if it was 1970s and you needed to worry about fitting on a floppy drive, fear having to expose large ABI and what not. E.g. Zed another Rust editor went with WASM and guess what, it hasn't really struggled with any of those things... But what is the most wild to me out of all of it is the maintainers themselves don't need any plugins. Otherwise they'd be in from day one. When they need a feature themselves they declare it a core feature and just add it in. So the picked lang is not for them to use, it is just for the kids to play in the little sandbox. To send them away and not bother the serious adults, to not distract them from real important things. You can clearly read this everywhere between the lines... PS. more on WASM being unusable because of increasing the footprint... heres the list of features of e.g. WAMR (WASM micro runtime) VM which has existing bindings for many langs including Rust:
|
Beta Was this translation helpful? Give feedback.
-
That's why I just completely lost my interest in Helix and went back to Neovim. There was a simple PR for aligning text (left, right, center) that was closed after 1 year (#12944) because the author does not use Helix anymore. I use text alignment all the time for banners and file headers. Yes, I know I can create a set of bash scripts, etc., etc., etc. But a simple alignment feature that had a PR... |
Beta Was this translation helpful? Give feedback.
-
Pretty much same here. The only difference I never actually switched, kept waiting for a few trivial PRs to be merged in to make it useable for work. Then gave up waiting after a couple of years. For me the end of line was a random reddit post from some disabled fella struggling to build a helix fork from sources. He had troubles with his right hand and someone sent him to a fork with mods enabling rebinding of hardcoded keys. Think it had to do with pickers, something along the lines. Sadly struggling to google it up now. It was quite some time ago. It is clear I should just forget and never return. Yet there is something very surreal around development on this project that keeps me coming back every now and then to check what is going on. It is just so so different vs other projects. It is a bit like observing a strange alien creature, idk. Must be the project governance, methinks. Somehow I'm almost certain some of helix maintainers on here have no issues whatsoever submitting feature or improvement proposals for the next round of Rust updates. With a straight face. While denying even remote possibility for anything of a sort on the own project. Surreal... |
Beta Was this translation helpful? Give feedback.
and others
Here’s my two cents.
I believe in the Maker’s choice. So, if the developers want Steel or Lisp as Helix’s plugin language, no one has the right to comment on that unless this person starts its own PR.
That said, I personally think choosing Steel or Lisp as the first language for plugins is not a great idea. Lisp is very different from most programming languages, and I’m pretty sure it’s not used anymore except in very specific cases (like Emacs).
Neovim chose Lua. Vim started its own Vim9 script language. After a very short time, we have amazing plugins in Neovim with quality equal to or even better than their Emacs counterparts that have been developed for three times longer.
So, in my o…