
Goism – Use Go instead of Emacs Lisp inside Emacs - demiol
https://github.com/Quasilyte/goism
======
Tenobrus
I haven't taken an incredibly close look at this, but it seems like a pretty
bad idea. Elisp is definitely not a great language, and I'd like an
alternative as much as the next Emacs user. But I feel pretty strongly that
any alternative has to be a Lisp, or very close to one. Code-is-data/data-is-
code is very important for the more "config-file" aspects of configuring
Emacs. Being able to use and write DSLs to succinctly encode exactly how you
want aspects of the editor to behave is a critical strength. I've tried
systems that were configurable in Python and other good-but-non-Lisp
languages, and it's always much more annoying, because the language is
(purposefully) limited w.r.t metaprogramming and possible DSLs. That's a good
thing when optimizing for maintainability by others and obviousness, but not
so much when optimizing for maximum personal customizability.

Go seems like quite possibly the polar opposite of this, as far in the "keep
it simple and understandable by literally everyone by cutting out many
techniques for metaprograming and code reuse". Which perhaps is the point, but
if so it seems like that point misses much of the draw of Emacs?

While this is definitely impressive technically, I think Guile Emacs is a much
more plausible option.

~~~
quasilyte
I used Emacs Lisp for scripting tasks like code and data generation. It is
great to have an ability to evaluate form right inside the spot you want
results to be inserted. This kind of code does not require AST manipulations
or macro.

Also, some of my projects that become bigger than 1000 LoC could benefit from
static typing and (subjectively) better tooling.

By the way, I think extending Emacs in Racket would be great; just do not have
an idea on how to implement that integration smoothly.

~~~
kkylin
You may already know about Guile-Emacs, but in case not, take a look at
[https://www.emacswiki.org/emacs/GuileEmacs](https://www.emacswiki.org/emacs/GuileEmacs)
. Guile is not Racket, or more precisely Racket is no longer exactly Scheme,
but they are closer to each other than to elisp.

------
busterarm
The idea of using a language without Map/Reduce/Filter as a substitute for a
Lisp, in an editor built around Lisp...seems vaguely antithetical to me.

~~~
quasilyte
You can call map/reduce/filter from Go code: `xs := lisp.Mapcar(f, ys)`.

Mapconcat is already used inside runtime implementation:
[https://github.com/Quasilyte/goism/blob/master/src/emacs/rt/...](https://github.com/Quasilyte/goism/blob/master/src/emacs/rt/builtin.go)
(Print and Println functions).

~~~
43224gg252
Why did you get downvoted for this?

------
josteink
I agree Emacs Lisp is pretty inferior as far as lisps go, but IMO this seems
pretty misguided.

Technically impressive, I'm sure, but will it be around for another 30 years?

If someone writes a module using this, will I be able to rely on that module
keeping on working for the years to come?

~~~
bigdubs
Why wouldn't that be the case? The golang authors have been pretty strong on
backwards compatibility so far (even though it is admittedly a young
language).

~~~
kornish
Is josteink talking about Go or Goism? Probably the latter.

------
justinmk
Neovim has a go client[1] for nvim's RPC API. Vim doesn't have bytecode to
speak of, so of course there's no transpiler step. But it removes the friction
of integrating between nvim <-> go, and that is "useful when it's useful". In
particular it enabled a new UI[2] to be built in go.

[1] [https://github.com/neovim/go-client](https://github.com/neovim/go-client)

[2] [https://github.com/dzhou121/gonvim](https://github.com/dzhou121/gonvim)

------
ajarmst
Dear God, no. No. Please, just give me Guile. Please. We've been so good. So
patient. Guile.

------
flavio81
What a sad idea.

Seriosuly, is that hard to learn Emacs Lisp? Even if one is using Go or Rust
(etc) at work, any programmer worth his salt should at least already be
familiar with Lisp syntax.

It is one of the easiest languages to learn!!

~~~
quasilyte
I love Emacs Lisp.

Emacs has really good support for it which continues to improve over time.

But.. I love more than one language (and more than one Lisp for sure). Will
you try to persuade me that I am wrong in that regard?

~~~
gkya
Emacs only having elispallows me to fix the third party code that I have in my
config, and simplifies all the things. Thoemacs already has C too now, there
is module support. I guess it could be possible to use Rust via that interface
too, and maybe go. But better keep these to a minimum because elisp is one of
the things that makes emacs great

------
jlarocco
Another case where it'd be nice to have a "Why are we doing this?" section in
the README.

If it's just a demo then it's neat. Interesting that it can be done.

On the other hand, if it's a real push to get people scripting Emacs with Go,
then I don't see the point at all. It's solving a problem people don't really
have.

~~~
hk__2
> It's solving a problem people don't really have.

Isn’t "I want to script Emacs but I don’t like LISP" a problem to solve?

~~~
ue_
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.

~~~
jchw
>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.

~~~
ue_
>I'm going to guess 36.1% more power, to be exact. Where's this figure from?

>We could always start performing eugenics to get rid of them.

I meant more like what we could do to improve the more powerful languages to
make them more appealing.

I'm less bitter than I am perplexed about the choice to use Go over Lisp.

~~~
jchw
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.

------
lngnmn
...and write all the types (without generics) - no, thank you!

Sarcasm aside, Lisp is as much as possible well-suited for the job of text and
AST processing, Emacs is one of the Lisp's "killer apps" and the second best
"case study" after classic old-school AI code (PAIP).

------
fithisux
Congratulations, keep up the good work.

------
testcross
How does it compare to something like
[https://github.com/janestreet/ecaml](https://github.com/janestreet/ecaml) ?

~~~
quasilyte
I see three main approaches for the tasks projects like ecaml and goism try to
solve:

1\. Use a plugin system (ecaml)

2\. Transcompile to a target language (gosim and emscripten-like platforms)

3\. Embed another VM inside Emacs and call its eval

There are many differences between these approaches and I am not sure one of
them is objectively better as a general solution.

For the end users, all of these approaches can deliver good level of
integration (they require different sets of tricks to achieve that).

------
kmicklas
Replacing a 50s language which a 60s language! Amazing!

------
solidsnack9000
Being able to script the editor in something other than Lisp seems good to me
(despite the objections of others in this thread). After all, many people are
just scripting settings and stuff for themselves. Might as well not make them
jump through hoops to do so.

I wonder about the implementation strategy -- why compile to Emacs LISP
instead of doing a plugin (FFI) or RPC style setup?

------
wcummings
What happens if I hover over a goism function and hit M-.? Do I get dumped
into the go source?

~~~
quasilyte
Currently, no. Hope I get your question right..

Name mangling scheme preserves fully qualified package path. All goism sources
live inside GOPATH (1), so nothing stops us from implementing a jump to Go
definition.

For given `goism-foo/bar.baz` Emacs symbol, Go definition can be found in
`GOPATH/src/foo/bar/` package. Exact location can be found by using existing
Go tools (simple grep-like solution can work, too).

(1) It can change in future; see
[https://news.ycombinator.com/item?id=13368846](https://news.ycombinator.com/item?id=13368846)
and even more relevant:
[https://github.com/golang/go/issues/17271](https://github.com/golang/go/issues/17271)

------
dreamcompiler
Why?

------
ww520
Is it possible to have a language transpire/compile to elisp?

~~~
quasilyte
It is possible to emit Emacs Lisp instead of bytecode/lapcode. This was the
first code generator target actually.

Easier to debug, simpler to trust (for the end user) and not that hard to
generate.

The problem is that it is harder to implement some features of Go in terms of
Emacs Lisp without going down to the virtual machine level. Best examples are
arbitrary return statements (can be emulated by throw/catch) and goto.

~~~
ruricolist
Could you implement arbitrary return with cl-block and cl-return-from?

~~~
quasilyte
With minor Emacs Lisp compiler patch (addition of %return, %goto and %label
intrinsics), it is now possible to output Lisp that is optimal.

Possible implementation (about 20 lines of code):
[https://github.com/Quasilyte/goism/issues/57](https://github.com/Quasilyte/goism/issues/57)

Not sure if "defadvice" around "byte-compile-form" is acceptable for all
users.

