A better thing to answer would be why people prefer less powerful languages to the more powerful, and what can be done about it? Framed that way,this seems like an XY problem.
Some optimizations are easier in Go than in Emacs Lisp, hence the potential quality of produced bytecode can be higher. For big packages that can be implemented in Go naturally (nearly without pain), this can be an advantage.
I found some optimizations that are not implemented inside Emacs lapcode optimizer.
If I will port them to byte-opt everyone win, right (if they pass Emacs team review, of course)?
>why people prefer less powerful languages to the more powerful
Clearly, power is the only measure one should consider when picking a programming language. And Lisp surely has more power than Go. I'm going to guess 36.1% more power, to be exact.
>and what can be done about it
We could always start performing eugenics to get rid of them.
... Okay, I apologize for being an ass. But I hope my points aren't lost; the way you're phrasing things makes it feel like you're bitter that anyone would consider using something that's not Lisp.
It was sarcasm. Obviously one can't objectively measure the power of two languages. I assume you mean it has more powerful metaprogramming than Go, which is what everyone else is saying.
But I find the rhetoric quite closed-minded, because I doubt any of the people replying here who've just found out about this and are calling it a bad idea have actually tried it yet. Clearly, there are advantages to Lisp that you would lose if you tried to do something in Go. But nobody is acknowledging the reverse, that there may also be advantages in Go to Lisp that are unforeseen, even for this specific task.
All in all this is a disappointing development. I don't think it would go over the same in other text editor communities, because people seem very defensive about the use of languages in place of Lisp where they might not be so defensive about the use of languages in place of say, VimScript.
I think GP's idea was that having a more flexible language is specifically useful for configuring Emacs, not that Lisp is better than Go in every imaginable case.
I haven't tried the linked package, but it seems like the idea is that it can be used alongside Lisp. If so I'm not fully understanding how this isn't a reasonable idea. Surely _being able_ to use Go is not a bad thing and not useless?
In practice, it's close to useless. A lot of the power of Emacs comes from the homogeneity and that Emacs itself is mostly written in Emacs Lisp.
There have been attempts in the past to do similar bridges to Python and Javascript IIRC, but they ended up nowhere since they didn't mesh well with the existing ecosystem.
No matter how bad people think Emacs Lisp is (an incorrect impression, Emacs Lisp has improved tremendously) it's still a powerful Lisp and only a Lisp would provide the powerful extensibility that Emacs has.
I don't think the author is challenging most of the notions here. In fact, it seems pretty well inline with this.
I think language bridges suck, but this isn't one. It transpiles Go to Lisp bytecode, making it much closer to a first class citizen.
But more importantly, the tagline of the project isn't "Let's write Emacs in Go," nor is it "Emacs Lisp is bad," it's "Not a fan of Emacs Lisp? Hack Emacs in Go!" -- that seems pretty straightforward to me. The aim of this seems to be potential Emacs users who do not code Lisp and don't like it. There are plenty of reasons to not like Lisp, not just Emacs Lisp, including the power that it possesses, just like there are plenty of reasons to not like Go. To suggest otherwise would be elitist.
The way I see it, the potential here is to open Emacs scripting up to a wider audience of people who are not necessarily all the same kind of programmers, who may prefer more typing to more magic.
If you don't like Lisp for editor programmoing, then an editor which is literally built upon a million lines of Lisp code seems to be a very bad choice. Even providing another extension language won't make the Lisp go away.
'Not useless' is not a high enough bar in software. Flexibility always adds complexity, and complexity is a cost. Sometimes that cost is worth it, but the benefit needs to be much larger and clearer than 'not useless'.
Not a high enough bar for what exactly? So far this entire thread is a lot of vague talk spawning off the idea that it doesn't solve a problem. That's the statement I don't agree with. If enough people decided to use it, that's the only bar that actually matters. But it clearly solves a problem, just not necessarily a problem every Emacs user has.
I found some optimizations that are not implemented inside Emacs lapcode optimizer. If I will port them to byte-opt everyone win, right (if they pass Emacs team review, of course)?