[Speaker 0]: I would invite all on the,
who are currently watching,
who have questions, put them into the pad
that I can ask them. I'm kind of monitoring
the IRC concurrently. So the first question
that we have on the pad is concerning why you
have switched from OCaml.
Maybe the person has missed it in the talk,
if you've mentioned it.
Why have you switched from OCaml to,
in this case, I guess,
Rust?
[Speaker 1]: Yeah, I mentioned like with writing a
language server that I wrote mine for my
company in OCaml But I wouldn't recommend it
just in general unless like you're doing
something specific with OCaml And the reason
for that and I recommended Rust or like
TypeScript is like OCaml is great.
It's very performant but it's cross
compilation story is not great.
It's like really hard to cross compile like
from 1 platform to another.
And then like the ecosystem and its standard
library is also not great.
And like Rust, its cross compilation is
great. Its ecosystem is great.
OCaml is great if you need to use it,
but it's just it's not ideal.
And there's just also no good examples of a
language server in OCaml.
There's the official like OCaml language
server, But they use a ton of super advanced
language features, like module functors and a
bunch of other random stuff.
So it's not really readable.
But Rust, there's Rust analyzer,
which is readable. In TypeScript,
there's like a million different ones.
So it's less of a, not OCaml is like,
it's not that OCaml isn't great.
It's more of a, these other languages would
probably just be easier.
So.
[Speaker 0]: I guess since the integration to,
for example, like NeoVim or some other
editors are just revenue fine because of the
[Speaker 1]: Sorry, can you say that again?
[Speaker 0]: LSP, I guess. The LSP,
so it's a standard LSP specification that
you're using. So you can also,
for instance, use it and other editors,
like for instance, new them or so.
[Speaker 1]: Yeah. Yeah. You can use it.
It's most, most editors nowadays support it.
Like obviously Emacs, NeoVim,
Sublime, VS code, Intel,
all the IntelliJ ones.
So yeah, that's, that's the fun part.
You don't have to write 10 different
languages to get a bunch of editor support.
[Speaker 0]: Also experience writing it.
So I didn't have really time to hear into
your talk. So I'm sorry if I ask you
questions that you have already said.
How was the experience of writing an LSP?
So have you any knowledge beforehand or do
you just read it all on yourself?
[Speaker 1]: Yeah, there's not a ton of documentation,
which is what motivated me to do this talk.
Basically, I just looked at the
specification, and I knew Rust Analyzer was
cool. And so I looked at Rust Analyzer,
and I looked at PyRite.
And I just went from there.
I found out about all this because I already
using Emacs, I already knew about it.
I was like, this is going to be easier than
something else. So yeah,
there's the experience is fine.
It's just a lot of wiring stuff up.
It's not a lot of like hard thinking until
you get to like performance heavy stuff.
Like, so for some graph,
like we're doing a ton of like code parsing
and like analyzing. And so that's,
it takes up like a ton of processing power.
So like for stuff like that,
like now you have to think about caching and
like ordering things. So that part's hard,
but that's more of a, like very much
application specific thing.
[Speaker 0]: Right. Anything in the IRC chat.
I think not. It's nothing I can see.
No questions, that's kind of odd to be
honest. I cannot really ask questions
concerning LSP specific.
[Speaker 1]: Yeah, no worries.
[Speaker 0]: Good question, what could be asked?
Let's call, let's ask something very
unspecific concerning the Emacs usage.
And when have you started?
How did you came through it and stuff like
this?
[Speaker 1]: Yeah. I like and when I was in high school,
me and my friends just were like,
got obsessed with Linux for whatever reason.
And then like we traveled down like the,
like the free software,
like we just thought that was like very
entertaining and like interesting to read
about all the free software stuff.
They were like, yeah, that's cool.
And so we all started using Linux.
And I'm like, well, if I'm using free
software, I'm going to use Emacs.
And so I started using Emacs just to try it
out. And then I kind of got,
I feel like, Stockholm syndrome into it.
And now I've realized like,
I don't know, now that I've done the like
actual work to get into Emacs,
it's just, there's so much more I can do with
it. But yeah, it was somewhat unintentional.
[Speaker 0]: I probably have the same course I've started
like 2 years ago using Emacs.
And also just, oh, there's at first some cool
people on YouTube, so systems crafters and
people like this. And also,
ah, VS Code, I used a lot of VS Code
beforehand and then VS Codium because open
source and then oh are there any other
alternatives and I came to like Neovim and
Emacs and often switching around but I stick
to Emacs at some point to be honest.
[Speaker 1]: Yeah, I think Emacs also just looks really
cool. I will say that.
And also just like I like Vim.
Vim is cool but like being able to like write
lists and like modify your editor on the fly
is just like very appealing to me.
I don't know, Emacs was tough at first
because like all the like default key
bindings are just kind of like and then and
then I read somewhere someone was like yeah
well Richard Stallman uses evil mode so it's
okay. I was like alright I can that's like
blessing enough for me Like I'm just gonna
switch to evil mode. And I was like,
this is way, way better as far as key
bindings go.
[Speaker 0]: Kind of relates. So I switched for,
I think, half a year to the default key
bindings from Vim beforehand.
I switched back to Evil and now I'm losing
some kind of hybrid styles.
It's kind of weird. But we have a question on
the pad. So what are the corner cases,
limitations, and other issues you encountered
in implementing an LSP server with client in
Emacs that were surprising?
[Speaker 1]: Yeah, I would say the corner cases and
limitations are definitely like,
once again, they're going to be very
application specific, but it's usually just
the performance part. So like I was saying
before, right, in general if you're doing
language tooling, you're gonna be doing
either parsing or interpreting or something
like that, which is very just like
computationally heavy and so if you're trying
to like do that stuff while someone is
editing a file right like every keystrokes
every like 1 to 2 seconds if they have a fast
computer that's great but a lot of people
don't have like that fast of a computer that
they can go and like do compilation every
single keystroke. So like,
I would say, I would say the like limitation
is just how fast your computer is and how
good you are at like implementing caching for
like whatever you're doing.
That's also just the main issues I've run
into is just it's a constant uphill battle.
People will somehow find larger and larger
files. You'll end up with files that are like
thousands, like tens of thousands of lines
long and you think yeah,
surely no 1 would expect like instantaneous
response for like like editing a file that
has like tens of thousands of lines,
but then they do. As far as corner cases go,
I would say the corner case is like,
just in general is actually distributing the
language server. Cause like writing the
language server is fine.
Like wiring everything up is fine.
But then like, once you actually have to go
and distribute it, well,
now you're distributing in a binary.
Like I was saying before with OCaml,
doesn't have great cross compilation.
So for some graph for our language server,
we target Linux and Mac OS,
and we have a ton of people who use Windows,
but compiling OCaml for Windows is basically
impossible. So our corner case there,
the way we solved it was now we're
transpiling OCaml to JavaScript,
which is a huge can of worms.
Like it's a lot of fun.
It's very interesting,
but like it's not ideal.
And so that's what I was saying before.
I recommend like Rust or TypeScript because
those are way more portable and a lot easier
to install. And you don't have to worry about
any of that weird packaging stuff.
So yeah, I would say that's like the main
corner case and the main limitation is just
speed and caching.
[Speaker 0]: You mentioned this obscure large file so
someone doesn't want to refactor or
something. How did you start?
So did you have any way to still be
relatively performant when they have big
files or is it just not supported?
I don't care.
[Speaker 1]: Yeah, no, we, so we support larger files now
And the way we ended up doing that,
so SemGrep is like you write this generic
pattern. You kind of write the language,
but then there's these other symbols and
stuff that are included in that,
this like meta language.
And so what happens is,
is most languages get,
they get parsed and then into a syntax tree,
right? Like whatever the language is syntax
tree is, and then they get,
the syntax tree gets converted into this,
like, we call it like an abstract syntax
tree, which is like abstract from like any,
like languages specific syntax tree.
And so then we can cache that,
which is really good because like if someone
types something like we don't have to go
through and do like the full parsing and like
converting, we only have to do it
incrementally. And so that's,
that's how we dealt with that.
Or the other option is that we just,
we just cache whatever the previous results
are, and then run it asynchronously,
and they might get it delayed.
But we've ended up doing more AST caching,
which is fun and cool.
[Speaker 0]: Sounds good. So we have here a question from
Blaine. If Eaglet is a subset of LSP mode,
can EGLOT conflict with LSP mode if both are
present in your initial .el
file?
[Speaker 1]: Yeah, so I haven't played around with EGLOT
mode a ton, so I'm not 100% sure.
I think all of the key bindings and commands,
if you just install it out of the box,
I Think they're different.
So I don't think there's like any like
overlap as far as that stuff goes but you
will have the overlap of like you entered,
like you started a major mode for like some
language, like they'll both probably start
the language server and provide diagnostics
and everything. And so then now you're
getting like, you're just like doubling the
work your computer is doing.
So there's that conflict.
But if you prefer EGLOT mode or LSP mode for
like 1 language or framework,
like 1 major mode and LSP mode for the other,
I think you should be fine.
[Speaker 0]: All right. Just to let you know,
we have like 1 minute on the stream and then
we'll switch back and to the pre-recorded
stuff I guess.
[Speaker 2]: Yeah yeah yeah let's hi sorry for the rude
interruption but I'm just doing a little bit
of time keeping so thank you so much Austin
sadly I wasn't able to follow the Q&A because
I was in the other track answering questions.
If, Austin, you want to stay and answer some
more questions, feel free to do so.
People tend to start talking as soon as we go
off air, And I wouldn't be surprised with LSP
that people would do the same.
We're gonna move on for this track.
We're gonna move on in 20 seconds to the next
1. So Floey, thank you for hosting.
Austin, thank you for all your answers.
And We'll see you in a bit.
[Speaker 1]: Cool. Thanks. See you.
[Speaker 0]: Thanks for the Q&A.
[Speaker 2]: All right. All right. You are now off air.
Thank you so much, Austin.
I'm going to go back running in the
background. And thank you,
Flowey, for everything.
[Speaker 0]: And thanks. Yeah. Have a nice,
probably a nice day at your work.
[Speaker 1]: Yeah, no worries. Yeah.
Yeah, it's still it's like lunchtime for me.
[Speaker 0]: So okay, here, it's like,
09:00. 9pm. Thanks for the talk.
Sorry for the inconvenience was not having
any, any questions, really.
[Speaker 1]: So yeah. Oh yeah, no worries.
It's like, there's like no documentation on
any of this stuff. So I didn't really expect
any.
[Speaker 0]: Yeah, I was kind of interested when I jumped
into NeoVim. I write it 1 or 2 things on my
own, but never really got really deep into
it. And you're gonna see with like compiler
design and stuff like this,
but not really specific.
So I was
[Speaker 1]: kind of- Yeah, that's the hard part.
It's like, it's, LSP is cool,
but then you have to like deal with all the
like compiler stuff and programming language
theory.
[Speaker 0]: So yeah. So it's, it shouldn't be too
complicated. I had not really a question,
so, but it worked out fine.
Thanks for the Q and A.
And if I have any questions to Oak Hamill,
Elderspeak will get an email from you.
[Speaker 1]: Oh yeah, definitely.
[Speaker 0]: Dan?