Development resources for VSCode Julia extension?

Tooling VS Code
1

Given the central role of the Julia extension for VS Code, I believe that the resources devoted to this project should be considerably increased. There is a commercial entity to promote Julia: Perhaps it should chip in? Devote one person full time to making this extension work so that newcomers are impressed. At this point, newcomers seem to be distinctly underwhelmed, given their experience with Matlab IDE or R Studio or Spyder.

PS: This is in no way a reflection on the efforts of @davidanthoff and @pfitzseb and the other fine contributors. It is just too big a job to do in a couple of hours on a weekend when there is some time to spare…

33 Likes
2

And likewise, but to nth power, for the debugger usability.

2 Likes
3

I could not agree more! The resource allocation right now is really off, there are defacto two people working at best part time on the extension, when the extension is probably one of the most crucial pieces in the Julia ecosystem.

I think the two biggest areas are the language server and the debugger.

For the LS we just need some folks that really make it “their” project. Right now it is sort of limping along, because the main person that worked on it moved to other things years ago. I started a bit of a renovation of the core architecture, but overall it just is not one of my core interests, and I think @pfitzseb might be in a similar situation.

For the debugger the situation in my mind is largely unrelated to the VS Code extension, the core problem there is just that the underlying debugger engine is not at a stage where it can power the kind of smooth debugging experience that users want.

43 Likes
4

Shall we start a dedicated thread to discuss this important issue? What is the role of JuliaHub with regards to the open source community? Does JuliaHub have a clear roadmap to support the ecosystem and open source tools that make up the Julia experience?

I feel that these questions are not officially addressed anywhere. It is good to see other people with similar concerns.

5 Likes
5

Seems to me we have enough here already for Juliahub to start paying attention.

image
image1381Ă—1033 104 KB

Perhaps we will hear from someone soon?

3 Likes
6

Are you qualified to speak on behalf of JuliaHub? If you have intel on the company’s size, financial resources, then many of us will take your words on that.

My impression is that this is not about lack of financial resources, specially when you consider the hub in its entirety (i.e., JuliaHub, MIT, PumasAI, …).

7

This is not really true. The problem with language server is that it is not really documented, therefore it is very difficult for new open source developers to work on it. Perhaps we could get a “Google summer of code” like project where a student creates a stand-alone language server and documents it well?

2 Likes
8

I know nothing about the language server, but regardless of employment (JuliaHub employee, grad student, random person, etc), someone will have to sit down and do the hard work of learning its internals. So I don’t really see this as an argument for a paid position by necessity.

I think this would be a great idea, possibility through the Julia Summer of Code (if that’s still going on), but that still requires someone knowledgeable with the language server to volunteer to be the mentor.

9

Well, there are exactly two people who could do that. If they do not find the time, then only a fork and starting from scratch would help.

10

It isn’t so difficult to work on the LanguageServer, you can even use Revise. I have 30+ merged PRs without any prior knowledge of LanguageServer or the LSP protocol. While LanguageServer might not be fully documented it is pretty simple: it gets requests, and handles them. That’s pretty much it. For example, the request handler to remove an unused variable is just a couple of lines. The language server protocol is very well documented though, so that is very useful. If anyone wants help setting up the development workflow feel free to message me or, better yet, ask in the #vscode-dev channel on Slack.

To give some specific pointers on how to implement some new functionality:

To give a concrete suggestion for someone, it would be cool to support inline local variable and the inverse extract variable.

11 Likes
11

Positron, and Cursor.AI are VS Code-based, so I assume VSCode Julia extension already works there, and all the other VS Code forks.

Other options are Zed and Pulsar editor I just discovered, both I believe based on Atom (the Zed people made Atom). Julia’s Atom-based Juno IDE is barely on life-support, merged into VS Code Julia extension. I think the extension is written in JavaScript, and Atom, and presumably Zed, use it too, and might have similar (but different) extension mechanism? Before spending a lot of money on the extension, I would want to know if needs or can support other IDE/editors, like Zed, and what would be the ideal to support if you has a choice?

This seems most up-to-date for Emacs: GitHub - gdkrmr/lsp-julia

Julia support for the =lsp-mode= package using the LanguageServer.jl package. For information on the features lsp-mode provides see their git repository.

12

How is the relationship between LanguageServer and Linter?

One issue I find annoying (I cannot find the issue in the moment, there are more than 900 open issues in julia-vscode) is that goto-definition does not work for examples of a project that I checked out with git.

Is that a LanguageSever issue or a Linter issue?

1 Like
13

LanguageServer depends on StaticLint (which does linting) but what you describe isn’t really a linting issue, but maybe a SymbolServer/LanguageServer issue. I don’t know why people keep having problems like that though – I never really experience them :man_shrugging:.

1 Like
14

Not to derail the thread too much, but I think there are a couple things to keep in mind here.

First, JuliaHub is still a comparatively small company, so it may not be the case that there is an “extra” full time employee to dedicate to the VSC extension. Same goes for hiring a dedicated developer, is it worth using $100K (salary + benefits + etc) to improve it? Which leads to…

Second, JuliaHub is a company, and the purpose of a company is to make money. “Look how good our VS Code debugger is!” will not convince anyone to buy into JuliaHub as a company, or else their financial team would already have someone dedicated to the project.

Considering that many of the “core Julia devs” work directly for JuliaHub in some fashion, I would say that the company already plays a huge role in the community. As for the ecosystem, I would go back to my first two points, for a small company its not as easy as just “hire a new person”. The alternative to that option would be to make one of the other devs do it. So, then its a matter of priority. Better language server or static compilation? Better debugger or work on core language bug fixes? I’m obviously not privy to the internals of JuliaHub, but I can very well imagine that it is a zero-sum game where every hour spent on the VS Code extension is an hour not spent on something else.

I’ve been on this forum for a while and whenever a person comes by and says something like, “language X has this package, someone should implement this in Julia”, the overwhelming response is, “Julia is open source, YOU can do it!”. I think that applies here, folks who want the language server to be better, or the debugger to be better, YOU help, YOU contribute. Or, sign up for JuliaHub (the product) and pay them to hire a VS Code dev.

And for me personally, I am happy with the extension (a big thank you to all the devs!) and would much rather have JuliaHub focus “extra” resources on things like static compilation, TTFX, etc.

(some of this may come off as more combative than I intend, so please don’t take it that way, I just don’t know a simpler way to make my points)

7 Likes
15

Maybe @gdalle or another mod could split the VSCode Extension maintenance question to a new thread?

2 Likes
16

Maybe I’m cynical, but these “Julia should get more resources” threads are not really actionable and never go anywhere useful.

There are some resources that are relatively easy to get (e.g. a NumFocus small development grant, a summer student at a university, …) but are also fairly small and short term … and they still require nontrivial effort from someone (making a grant proposal, supervising a student…). They can be useful to add individual features or fix specific problems.

6 Likes
17

My opinion of the LanguageServer changed significantly when I set it up in Neovim. Before that, I would occasionally open VS Code to see whether it had any useful linting advice on my code base. It was always full of false positives, and totally useless. With Neovim, it works almost flawlessly, and is extremely useful. I think it really comes down to setting up the project_path correctly. With VS Code, that was a black box (or maybe my lack of experience). In Neovim, I can set it up exactly the way that works for me.

With the obvious drawback that I have to set it up exactly the way I want it, so there was a learning curve.

2 Likes
18

No, no. The Atom people made Zed, but it’s definitely not based on Atom or Electron. They were taking lessons from making Atom, and decided performance was a major factor.

They decided to make the fastest editor possible, built from scratch in Rust. It’s pretty promising.

2 Likes
19

My comments were moved in the wrong order in this thread. My second comment should come after @mihalybaci 's comment.

20

I may be wrong, but I thinks at least some of the people who work on Julia releases are paid. My second assumption is that the more people program in Julia, the better for Juliahub (and the community as a whole, of course).

I’m pretty happy with 1.10.4, but I understand at this point 1.10.5 and 1.10.6 are both out, and 1.11 is imminent.

I don’t think a newcomer to Julia will much appreciate the difference between these 1.10 releases. I certainly don’t care, I see no advantage in switching to an incrementally improved version.

What the newbies will consider crucial is a reasonable way of interacting with Julia. VS Code is usually recommended to such programmers, but often with the words “there are some things that don’t work so well” (debugger, for one). This is obviously not going to impress the newbies.

So, I don’t see a huge disadvantage to having a discussion among the pursers about what the tradeoffs are, only potential advantages: do we fund the development of a plethora of releases, or do we fund someone to make really usable and shiny IDE?

This is obviously just an example: There might be other targets for such a discussion.

2 Likes