answer to that. I, I think the infrastructure for an
ecosystem in Julia in general is as mature as other
languages, and even debugger infiltrator themselves are
not particularly well developed. And so I don't think
there's much we can do about that right now. I think that It's
unfortunate that most of the development for these type of
tools is tightly linked to VS code. But even there, I don't
think that there's much done in terms of interactive
debugging. So I, yeah, I think this has to be worked on mostly
on the Julia side first. And then probably Emacs can get
something out of that. I know that there's development in
debugger.jl itself for future releases to make it at least
faster and more stable. But yeah, I think we're not there as
Julia community itself. So let alone Emacs, integration
with Emacs. The way I personally debug is mostly using,
well, debugger and infiltrator with Julia REPL mode in
Emacs. The second question, can you call out something that
Julia has that Emacs does not and which could benefit Emacs?
Nothing stands out to me except the usual multi-threading
and things like this. I don't necessarily see something
that Julia has going on that DMX doesn't have, but I see some
differences and approaches that I think are important,
like the community. I think Julia is a very active and tight
community. Julia uses Slack and is very, very active. I
think he might say something like that, but it's maybe more
on Reddit, IRC. JuliaCon is big and brings together lots and
lots of people. And I think the sense of community is really
powerful. It's very easy to essentially meet people that
are interested in what we're building and interested in
what we're doing and interested in Julian, our, you know,
hacker spirit. I think Emacs is a very strong community.
We're here on a Saturday talking about Emacs, which again
proves that we are doing this. But I'd like to emphasize that
the community is a really important aspect in Julia that I
think we should double down on our side. The next question is
about Lisp syntax with Julia, like what we can do in Python.
I don't think that's, I don't, I am not aware of any package
that does that. I would bet that there's something there. I
think that that's possible. Indeed, there used to be a Lisp
interpreter in Julia itself until the latest release. The
syntax parsing was done with a Lisp, it was called TemtoList
indeed. I think this got rid, get rid of this for our more
Julia-based solution that is faster and with better code
provenance. I think that it should be possible to use the
metaprogramming features in Julia to change the structure
of your syntax to be a Lispy syntax. I do want to emphasize
that
Julia is heavily inspired by Lisp, so I wouldn't be
surprised if if something like this were possible. I have
tried Julia Snail. So the next question is about Julia
Snail. I found Julia REPL to be a little bit easier to set up
and use. So I just settled on that. I should maybe revisit
that. In particular, I use the Julia REPL with the vterm
backend, which essentially makes a companion REPL to my
scripts. And that works for me. I do think that the tooling
uh, could be improved. I think there is definitely much room
and I would like to see improvement in that area. Um, and, uh,
so we have, uh, okay. Data inspector for, for Julia Red Bull.
Uh, I, I don't think so. I don't, is there any data inspector
in for, for the Julia Red Bull that we can use in Emacs? I, I,
I'm not sure. I don't think so. I think the way I look at data is
essentially ignoring AMX when encoded. It's just using the
REPL. And again, with Julia REPL. So I'm not aware of any
specialized tool And again, maybe this is, again, a good
moment to emphasize that tooling, the Julia community
clusters around VS Code. And there is tools like the, pretty
much all the work with VS Code, unfortunately. And while
there's a very, very decent Julia mode and Julia repo mode
and Julia snail, there's definitely, definitely room for
improvement.
Next, we have a question about literate programming in
Julia. I haven't done much of it with Oracle Babel or
anything else. I haven't done much of it. I can say that Julia
has developed a new iteration of notebooks called Pluto.
Here I'm thinking about Jupyter notebooks. The Pluto
notebooks for Julia try to remove a bunch of the pain points
that Jupyter notebooks have, meaning you cannot easily
commit them to Git or things like this.
I haven't used them, but I know some people are very fond of
them. And so I think that that's what some of the Julia
community would use for notebooks. And I think they can
interact with Emacs with no problem. And that would be a form
of later programming. But if you can do it in Python, you can
do it in Julia. I think there is no reason. And actually, you
can take advantage of all this just-in-time or
just-out-of-time compilation by keeping the same
session. So I think it will be definitely a nice use case. So
these are the questions that I see here. I'm going to scroll
through the comments and see if there's something that I
should say about comments. I'm excited people want to learn
Julia. I have to say that if I want to do GPU computing
nowadays, I find it much easier to do it with Julia than with
CUDA. So I encourage people to look into that. And I do,
again, I would like to share what makes me excited about
Emacs, about this being open, being collaborative, being
respectable with documentation is something that I find in
Julia. So I think people that are excited about the same
features will find a little bit of joy in working with Julia.
I think I addressed what I have here. I don't know if there's
anything else that I should add.
It took me a minute to unmute there. No, I think that was
awesome. And thank you so much. I guess I thought it would
collapse that shared area on BBB, my mistake, on the stream,
or I would have left it open. But in any case, no, I thought
that was great. You did a great job of responding to all the
questions and comments. And thank you again so much for your
talk and getting us all excited to learn Julia. Thank you.
Enjoy EmacsConf. And again, thanks so much for attending,
for being EmacsConf. Thank you.