WEBVTT

NOTE Q: Do you have any suggestions for interactive debugging of Julia code in Emacs?

00:00:00.000 --> 00:00:05.319
... answer to that. I, I think the infrastructure for an

00:00:05.320 --> 00:00:08.599
ecosystem in Julia in general is as mature as other

00:00:08.600 --> 00:00:12.559
languages, and even debugger infiltrator themselves are

00:00:12.560 --> 00:00:17.519
not particularly well developed. And so I don't think

00:00:17.520 --> 00:00:21.519
there's much we can do about that right now. I think that it's

00:00:21.520 --> 00:00:25.999
unfortunate that most of the development for these type of

00:00:26.000 --> 00:00:31.759
tools is tightly linked to VS code. But even there, I don't

00:00:31.760 --> 00:00:35.719
think that there's much done in terms of interactive

00:00:35.720 --> 00:00:42.359
debugging. So I, yeah, I think this has to be worked on mostly

00:00:42.360 --> 00:00:47.519
on the Julia side first. And then probably Emacs can get

00:00:47.520 --> 00:00:51.239
something out of that. I know that there's development in

00:00:51.240 --> 00:00:55.559
debugger.jl itself for future releases to make it at least

00:00:55.560 --> 00:01:01.839
faster and more stable. But yeah, I think we're not there as

00:01:01.840 --> 00:01:06.879
Julia community itself. So let alone Emacs, integration

00:01:06.880 --> 00:01:11.239
with Emacs. The way I personally debug is mostly using,

00:01:11.240 --> 00:01:15.199
well, debugger and infiltrator with Julia REPL mode in

NOTE Q: Can you call out something that Julia has that Emacs does not, and which could benefit Emacs?

00:01:15.200 --> 00:01:21.679
Emacs. The second question, can you call out something that

00:01:21.680 --> 00:01:26.839
Julia has that Emacs does not and which could benefit Emacs?

00:01:26.840 --> 00:01:31.879
Nothing stands out to me except the usual multi-threading

00:01:31.880 --> 00:01:36.119
and things like this. I don't necessarily see something

00:01:36.120 --> 00:01:42.479
that Julia has going on that DMX doesn't have, but I see some

00:01:42.480 --> 00:01:45.839
differences and approaches that I think are important,

00:01:45.840 --> 00:01:49.759
like the community. I think Julia is a very active and tight

00:01:49.760 --> 00:01:54.159
community. Julia uses Slack and is very, very active. I

00:01:54.160 --> 00:01:56.559
think he might say something like that, but it's maybe more

00:01:56.560 --> 00:02:01.799
on Reddit, IRC. JuliaCon is big and brings together lots and

00:02:01.800 --> 00:02:05.159
lots of people. And I think the sense of community is really

00:02:05.160 --> 00:02:10.479
powerful. It's very easy to essentially meet people that

00:02:10.480 --> 00:02:12.919
are interested in what we're building and interested in

00:02:12.920 --> 00:02:15.999
what we're doing and interested in Julian, our, you know,

00:02:16.000 --> 00:02:21.239
hacker spirit. I think Emacs is a very strong community.

00:02:21.240 --> 00:02:24.279
We're here on a Saturday talking about Emacs, which again

00:02:24.280 --> 00:02:29.679
proves that we are doing this. But I'd like to emphasize that

00:02:29.680 --> 00:02:33.639
the community is a really important aspect in Julia that I

00:02:33.640 --> 00:02:38.159
think we should double down on our side. The next question is

NOTE Q: Is there a way to use lisp syntax with Julia, like hy for python or lisp flavoured erlang?

00:02:38.160 --> 00:02:46.519
about Lisp syntax with Julia, like what we can do in Python.

00:02:46.520 --> 00:02:52.359
I don't think that's, I don't, I am not aware of any package

00:02:52.360 --> 00:02:56.879
that does that. I would bet that there's something there. I

00:02:56.880 --> 00:03:01.519
think that that's possible. Indeed, there used to be a Lisp

00:03:01.520 --> 00:03:08.079
interpreter in Julia itself until the latest release. The

00:03:08.080 --> 00:03:12.039
syntax parsing was done with a Lisp, it was called TemtoList

00:03:12.040 --> 00:03:18.679
indeed. I think this got rid, get rid of this for our more

00:03:18.680 --> 00:03:23.039
Julia-based solution that is faster and with better code

00:03:23.040 --> 00:03:28.599
provenance. I think that it should be possible to use the

00:03:28.600 --> 00:03:33.319
metaprogramming features in Julia to change the structure

00:03:33.320 --> 00:03:38.159
of your syntax to be a Lispy syntax. I do want to emphasize

00:03:38.160 --> 00:03:43.879
that Julia is heavily inspired by Lisp, so I wouldn't be

00:03:43.880 --> 00:03:49.239
surprised if if something like this were possible.

00:03:49.240 --> 00:03:51.239
I have tried Julia Snail.

NOTE Q: Have you tried the Julia Snail package for Emacs? It tries to be like SLY/SLIME for Common Lisp.

00:03:51.240 --> 00:03:54.399
So the next question is about Julia

00:03:54.400 --> 00:03:58.199
Snail. I found Julia REPL to be a little bit easier to set up

00:03:58.200 --> 00:04:02.839
and use. So I just settled on that. I should maybe revisit

00:04:02.840 --> 00:04:05.999
that. In particular, I use the Julia REPL with the vterm

00:04:06.000 --> 00:04:10.959
backend, which essentially makes a companion REPL to my

00:04:10.960 --> 00:04:15.439
scripts. And that works for me. I do think that the tooling

00:04:15.440 --> 00:04:19.239
uh, could be improved. I think there is definitely much room

00:04:19.240 --> 00:04:26.079
and I would like to see improvement in that area. Um, and, uh,

NOTE Q: Is there a data inspector for a Julia REPL available that you can use in Emacs?

00:04:26.080 --> 00:04:31.639
so we have data inspector for Julia REPL.

00:04:31.640 --> 00:04:37.279
I don't think so. I don't, is there any data inspector

00:04:37.280 --> 00:04:40.439
in for, for the Julia REPL that we can use in Emacs?

00:04:40.440 --> 00:04:44.839
I'm not sure. I don't think so.

00:04:44.840 --> 00:04:47.799
I think the way I look at data is

00:04:47.800 --> 00:04:50.519
essentially ignoring Emacs when encoded. It's just using the

00:04:50.520 --> 00:04:56.839
REPL. And again, with Julia REPL. So I'm not aware of any

00:04:56.840 --> 00:05:00.479
specialized tool And again, maybe this is, again, a good

00:05:00.480 --> 00:05:04.279
moment to emphasize that tooling, the Julia community

00:05:04.280 --> 00:05:09.079
clusters around VS Code. And there is tools like the, pretty

00:05:09.080 --> 00:05:14.199
much all the work with VS Code, unfortunately. And while

00:05:14.200 --> 00:05:17.759
there's a very, very decent Julia mode and Julia repo mode

00:05:17.760 --> 00:05:21.439
and Julia snail, there's definitely, definitely room for

00:05:21.440 --> 00:05:24.359
improvement.

NOTE Q: Have you tried literate programming Julia (using Org babel or some other means) in Emacs?

00:05:24.360 --> 00:05:27.759
Next, we have a question about literate programming in

00:05:27.760 --> 00:05:32.439
Julia. I haven't done much of it with Org Babel or

00:05:32.440 --> 00:05:37.079
anything else. I haven't done much of it. I can say that Julia

00:05:37.080 --> 00:05:40.719
has developed a new iteration of notebooks called Pluto.

00:05:40.720 --> 00:05:47.119
Here I'm thinking about Jupyter notebooks. The Pluto

00:05:47.120 --> 00:05:55.359
notebooks for Julia try to remove a bunch of the pain points

00:05:55.360 --> 00:06:00.439
that Jupyter notebooks have, meaning you cannot easily

00:06:00.440 --> 00:06:03.639
commit them to Git or things like this.

00:06:03.640 --> 00:06:09.279
I haven't used them, but I know some people are very fond of

00:06:09.280 --> 00:06:13.559
them. And so I think that that's what some of the Julia

00:06:13.560 --> 00:06:16.879
community would use for notebooks. And I think they can

00:06:16.880 --> 00:06:22.239
interact with Emacs with no problem. And that would be a form

00:06:22.240 --> 00:06:26.879
of later programming. But if you can do it in Python, you can

00:06:26.880 --> 00:06:32.119
do it in Julia. I think there is no reason. And actually, you

00:06:32.120 --> 00:06:35.839
can take advantage of all this just-in-time or

00:06:35.840 --> 00:06:38.239
just-out-of-time compilation by keeping the same

00:06:38.240 --> 00:06:45.199
session. So I think it will be definitely a nice use case. So

00:06:45.200 --> 00:06:49.199
these are the questions that I see here. I'm going to scroll

00:06:49.200 --> 00:06:52.759
through the comments and see if there's something that I

00:06:52.760 --> 00:06:57.319
should say about comments. I'm excited people want to learn

00:06:57.320 --> 00:07:02.519
Julia. I have to say that if I want to do GPU computing

00:07:02.520 --> 00:07:06.399
nowadays, I find it much easier to do it with Julia than with

00:07:06.400 --> 00:07:11.759
CUDA. So I encourage people to look into that. And I do,

00:07:11.760 --> 00:07:19.359
again, I would like to share what makes me excited about

00:07:19.360 --> 00:07:23.799
Emacs, about this being open, being collaborative, being

00:07:23.800 --> 00:07:26.399
respectable with documentation is something that I find in

00:07:26.400 --> 00:07:30.999
Julia. So I think people that are excited about the same

00:07:31.000 --> 00:07:35.279
features will find a little bit of joy in working with Julia.

00:07:35.280 --> 00:07:41.999
I think I addressed what I have here. I don't know if there's

00:07:42.000 --> 00:07:43.559
anything else that I should add.

00:07:43.560 --> 00:07:52.879
It took me a minute to unmute there.

00:07:52.880 --> 00:07:57.519
No, I think that was awesome. And thank you so much.

00:07:57.520 --> 00:08:00.119
I guess I thought it would

00:08:00.120 --> 00:08:06.279
collapse that shared area on BBB, my mistake, on the stream,

00:08:06.280 --> 00:08:12.359
or I would have left it open. But in any case, no, I thought

00:08:12.360 --> 00:08:15.079
that was great. You did a great job of responding to all the

00:08:15.080 --> 00:08:17.839
questions and comments. And thank you again so much for your

00:08:17.840 --> 00:08:23.199
talk and getting us all excited to learn Julia. Thank you.

00:08:23.200 --> 00:08:27.759
Enjoy EmacsConf. And again, thanks so much for attending,

00:08:27.760 --> 00:08:42.400
for being EmacsConf. Thank you.