Example:
Obviously, I did not run both editors at the same time.
Is there a noticeable difference when ctrl+enterāing Julia code, or is it mainly about opening files and advanced editing snappiness?
While I do notice lags from time to time in VS code, it is hard to identify their source.
And, it isnāt easy to measure.
My main concern is the use of resources: the more resources consumed by the editor, the less is left for actual computing.
vim with slime plugin and tmux with tmux-resurrect plugin is my ide. tmux can resurrect all vim states and location of files and directories that you are working on even after reboot. it also resurrects your panes and windows and sessions. slime allows vim to cut and paste block of codes or line of code whatever in the vim cursor to julia running in different pane or window. and slime can redirect to any window or pane running any interpreter or jit so it is a good system for R, Python, and Julia.
The Electron ecosystem is annoying for sure, I donāt care much on a good desktop computer but on laptop itās not great ; on a recent MacBook Pro just having VS Code + a browser opened is enough to make the fans spin.
i really like emacās Julia mode.
my guess is iām working somewhat inefficiently having to go to the doc page to look things up that might be present in some sort of IDE.
The only thing I conciously miss is not being able to jump to a function definition in some module that iāve created. my guess is that proper set-up with etags could get me there but i havenāt tried to do it yet.
the biggest productivity improvement iāve experienced lately was Revise. I was very late to the party on that. lol. What was more interesting is that it changed the way I write the code for the better. i tended to modularize stuff after writing it in a script-like fashion. Now i think a little harder about what a module should look like and start with a module to begin.
p.s. iāve written a lot of embedded code and a debugger is essential. Desktop code though Iām fairly happy to write without one, and never felt like I just had to have it. Thatās because in embedded code the interrupts, memory management, and other various hard to debug things are really hard to debug without watchpoints and break on condition. I suspect if I wrote āreal timeā code in Julia i would have much the same problem, but I donāt
For what itās worth, this is the functionality eglot provides which I find most indispensable. I hardly use it when working on small projects, but itās super nice to have proper working xref-find-definitions
just an M-x eglot
away.
I really like VSCode, but Iāve switched back to Atom/Juno because I wanted to be working in the same IDE that Iām recommending to my coworkers (so I can help them debug things) but I canāt recommend VSCode because of the telemetry issue. Itās kinda frustrating because now weāre all going to be working in an unsupported IDE, but it is what it is, I guess.
You could try VSCodium to avoid telemetry.
Thanks for the recommendation. Does that stop the julia language extension from requesting telemetry, though? Thatās where the issue is because he julia extension is producing the telemetry pop-up.
And herein lies my problem with VSCode. Itās not as snappy as alternatives so Iām not going to use it for quick edits. On the other hand, when I do a long and intense analysis with visualizations it consumes so many resources that it gets bogged down. Greatly reduces the times when VSCode is the convenient option.
I have bumped into the conflict between reactivity and mutability. In one case, I was progressively adding columns to a DataFrame, with explanations about why interspersed, so a cell of markdown and a cell mutating the dataframe, and that messes up the reactivity. I think the answer is to make a new DF or do all the mutating in one cell.
What are all those processes under Sublime doing? Is that the language server for Julia? If so, do you know of a guide or website that explains how to set that up. Thx
No, I donāt use LS. I use the autocompletion built-in into Sublime Text.
In version 4 it is quite general, fast, and robust.
Probably will not. Itās a sign of the times, more memory used. Before Emacs was blamed as resource hungry, for similar reasons:
Chrome (or some other slightly better web browser, like Firefox), is not fully to blame Websites are now more resource-hungry, as JavaScript is used and itās a Turing complete language (ok, Googleās V8 JS engine made it really practical to use JS to a large extent), so you CANāT limit memory without killing tabs, or, in case of IDEs, extensions. Windows 98 had ā16 MB of system RAMā requirement and famously came with Internet Explorer 4, so web browsers necessarily do not need much memoryā¦ (w/o JS). Older Windows was limited to 2 MB and had IE available.
Weāre never going back to small, e.g. as modern browsers with fast JavaScript need MORE memory to be faster as they compile (just like Julia, we shouldnāt be throwing stones in a glass house).
Since the IDEs are really web browsers, with all those capabilities, I foresee videos in some ads for extensions (or built in tutorials)ā¦
I see Theia works, but some issues, and link from there to an issue:
A lot of the related CPU and RAM usage goes to websites spying on you or displaying ads. You can mitigate that to a surprisingly large extent with plugins like UBlock Origin and NoScipt (and many other similar ones). Also, browsers are getting smarter about these things by default.