A vision of a multi-threaded Emacs (2022)
coredumped.dev
coredumped.dev
I just went over all my packages - I'm not using a single one which does make use of the threads API. I used to use lsp-mode, which _does_ create a thread in one situation - which also could've been solved by doing async calls.
A lot of the stuff that should've used async, but didn't got fixed, plus there's an external library to move some other stuff along. I've moved gnus (which used to be notorious for blocking everything) into my main emacs process years ago - and last year even tried setting up a new notebook without the local imap, and made it directly go to upstream servers. Turns out, so much improvements landed in the imap code over the years that doing this works so well now that I've dropped the local cache from all my existing systems by now.
Do you not use it any more? Have you switched to Eglot or something?
I use lsp-mode, was going to switch to eglot, but it doesn't have the features that lsp-mode has, like lsp-ui (as far as I can remember), and the last time a compared (last year), the performance impact was somewhat noticeable.
I work on a huge codebase with eglot+clangd and the few times where it gets slow is where there are tons of flymake warnings. Like when you enable all the clang-tidy checks.
I officially started with .NET back in 2008 and, at the time, you really had to use Visual Studio. I knew emacs was not an option at that time. Since .NET Core I knew I was getting closer and closer for emacs becomming an option.
Then comes Visual Studio Code.
I have experiemented with C# development in emacs for a few years, now. I cannot remember now but it was likely with lsp-mode. When I found out eglot is in v29, it was time to revisit it. It has been positive so far.
I actually forced myself doing .net development in emacs this weekend. I am 90% there! Need to see if I can debug in emacs, now. I hope so!
Once I am happy, I will continue to add more interactive functions, saving me typing 'dotnet cli..' commands. I also need to revisit yasnippet to make coding more effecient in C#.
Getting started with eglot and C# was pretty painless, thanks to this link:- https://www.johansivertsen.com/post/emacs-29-csharp/
This was also the Visual SourceSafe days. How I do not miss that!
C# wiggled its way in eventually.
Back in 2008, I was pretty much using Emacs for most programming languages. The only exception was C# and Javascript.
As the years pass to now, I rarely use a programming language outside of emacs. I have enough years in my career to not tell me what I can and cannot do to get things done.
That was also the project where I tested if git reached the point where you can have "normal" people work with it as well (which worked pretty well). I never accepted any project where they'd have me work with idiotic proprietary source control, unless the project was "migrate away from that".
Since around 2014 -- It has been Git all the way.
Well, until recently. Codebase at my current job is all contained in a single Subversion repo. It is difficult to maintain and branching takes GBs!
One of my first goals is to move over to Git, and into smaller Git repos. Of course, I have Magit to get it done. :-)
I like how people think I am purposely being different or difficult because I do C# development in emacs. Many have never heard of it. If they have its from forums or youtube videos.
Think of their mindset -- Its not like I have moved away from Visual Studio to Visual Studio Code. I am using Emacs. They must think I am trying to be difficult or special.
I have also swapped my L-CTRL key with CAPS specially for improving my emacs experience.
Regardless, when we do pair programming (or something) on my screen and they watch me use Emacs on a C# project, they soon understand. :-)
> Languages where parallelism is memory safe, but can still lead to data races.
> This includes Java and Go.
Despite this common misconception, parallel Go is absolutely not memory safe: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...
I has gotten better over this past year, I've noticed many improvements with Nativa Compilation and Tree-Sitter, not sure if it can get even better; I sure hope so.
Multithreading and parallelism is my hobby, so I'm curious how emacs implements this. I imagine it would be really difficult to migrate the entire ecosystem from code that is not designed to be accelerated by multicore.
I feel that if you just add a mutex, the code will fall very short of expectations of Amdahls law because:
* you cannot accelerate any single memory address mutability rates/performance by adding threads * to accelerate write/read performance (to get up to theoretical memory bandwidth) you need no-locks and multiple threads with DIFFERENT memory addresses
You need a different model to programming that is efficient.
One thing I can think of is that each thread owns a few buffers and you load balance that way.