>> It will not all go well. The fear and anxiety about AI is justified; we are in the process of witnessing the largest change to society in a long time, and perhaps ever. We have to get safety right, which is not just about aligning a model
The question is what are they doing about "getting safety right" and are they doing enough. To me it seems like all the focus is on hyper growth, maximum adaptation and safety is just afterthought. I understand its competitive market, and everyone is doing it, but its just hollow words. Industries that cares about safety often tend to slow down.
> I told my GF over dinner tonight that historians in 1000 years will look back to Nov 2023 as a pivotal fork where humans lost.
Yes, because no one listened to me. It was early-mid 2024, and here as well as on other places, people kept saying "oh well the cat's out of the bag now, nothing can be done, it can't be stopped". I pointed out that only 4 or so planes being made to collide with TSMC, NVIDIA and ASML would be enough to give at least a decade of breathing room while we try to figure out how to keep this technology safe. I'm almost certain there were people who read it on here as well as elsewhere who could have made it happen.
Claude has really helped me improve my Emacs config (elisp) substantially, and sometimes even fix issues I've found in packages. My emacs setup is best it has ever been. Can't say it just works and produces the best solution and sometimes it would f** up with closing parens or even make things up (e.g. it suggest load-theme-hook which doesn't exist). But overall, changing things in Emacs and learning elisp is definitely much easier for me (I'm not good with elisp, but pretty good Racket programmer).
I used Emacs for about a decade and then switched to VS Code about eight years ago. I was curious about the state of Claude Code integration with Emacs, so I installed it to try out a couple of the Claude packages. My old .emacs.d that I toiled many hours to build is somewhere on some old hard drive, so I decided to just use Claude code to configure Emacs from scratch with a set of sane defaults.
I proceeded to spend about 45 minutes configuring Emacs. Not because Claude struggled with it, but because Claude was amazing at it and I just kept pushing it well beyond sane default territory. It was weirdly enthralling to have Claude nail customizations that I wouldn't have even bothered trying back in the day due to my poor elisp skills. It was a genuinely fun little exercise. But I went back to VS Code.
Came to post exactly this, except it’s got me using emacs again. I led myself into some mild psychosis where I attempted to mimic the Acme editor’s windowing system, but I recovered
Yeah, and all the little quirks here and there I had with emacs or things that I wish I had in workflow, I can just fix/have it without worrying about spending too much time (except sometimes maybe). The full Emacs potential I felt I wasn't using, I'm doing it and now I finally get it why Emacs is so awesome.
E.g. I work on a huge monorepo at this new company, and Emacs TRAMP was super slow to work with. With help of Claude, I figured out what packages are making it worse, added some optimizations (Magit, Project Find File), hot-loaded caching to some heavyweight operations (e.g. listing all files in project) without making any changes to packages itself, and while listing files I added keybindings to my mini buffer map to quickly just add filters for subproject I'm on. Could have probably done all this earlier as well, but it was definitely going to take much longer as I was never deep into elisp ecosystem.
Hooking up Emacs to ECA with emacs-eval MCP is fantastic - Claude can make changes in my active Emacs session, run the profiler, unload/reload things, log some computation or embark-export search results and show it in a buffer; It can play tetris and drive itself crazy with M-x doctor - it's complete and utter bonkers. I can tell it to make some face color brighter/darker on the spot, the other day I fixed a posframe scaling issue that bugged me for a long time - it's not even about "I don't know elisp", this specific thing requires you to sit down and calculate geometry of things - mechanical, boring stuff. AI did it in minutes. VS Code, IntelliJ, any other shit that has no Lisp REPL? What are you even talking about? It's like a different world.
>> recently I realized that I read code, but almost never write it.
I think most engineers are reading code than writing it. I find it very hard to not use Emacs when reading large codebases. Interestingly, its mostly because of file navigation. I love using ido/ivy for file navigation, quickly filtering through buffers, magit.
Emacs in terminal is not an ideal experience though. So I can imagine it being multi-fold worse with phone keyboard.
it has never been my explicit goal. but i have certainly enjoyed the rewards of recognition (e.g. i was able to lean on a successful project of mine to help land a nice consulting gig) and it would be silly to ignore that.
(edit: the comment i replied to was edited to be more a statement about themselves rather than a question about other developers, so my comment probably makes less sense now)
I don't dispute your own personal motives, but if it's never been a goal for most people, then CC0 would be more popular than the BSD or MIT license - it's simpler and much more legally straightforward to apply.
I worked on several open source projects both voluntarily or for work. The recognition doesn't really need to be financial. If people out there are using what you are building, contributing back, appreciating it -- it gives you motivation to continue working. Its human nature. One of the reason why there are so many abandoned projects out there.
Emacs is my editor/IDE of choice and consider myself power-user. However, I'm no expert in its internals or elisp. I understand that things are built with single-thread execution in mind over decades. However, I think things still can be more async, where you can offload heavy stuff to separate thread and stream results. E.g. Magit status doesn't need to block my entire editor. It can run what it needs to do in separate thread, send the results back to main thread just for rendering when its ready. Same with say consult-ripgrep / consult-find-file / find-file-in-project etc -- doens't need to wait for it in main thread and block the render / event handling until entire result set is ready (e.g. in this case things can be streamed). As in maybe there is a way around to make this much better by message passing/streaming instead of sharing state itself?
I love Emacs, but it really just fails to be effective for me when I work on monorepos and even more so, when I'm on tramp.
Probably all true, what you say about magit and so on. Message passing values would be an idea, but with the current situation, when 1 concurrent execution units, a process, finishes its job, how does its "private" potentially modified state get merged back into the main Emacs global state? Lets say the concurrently running process creates some buffers to show, but in the meantime the user has rearranged their windows or split their view, but the concurrent process doesn't know about that, since it was after its creation time. Or maybe the user has meanwhile changed an important Emacs setting.
I think the current solutions for running things in separate threads are only for external tools. I guess to do more, a kind of protocol would need to be invented, that tells a process exactly what parts of the copied global state it may change and when it finishes, only those parts will be merged back into the main process' global state.
Maybe I understood things wrong and things are different than I understood them to be. I am not an Emacs core developer. Just a user, who watched a few videos.
Tramp can be sped up a bit. I remember seeing some blog posts about it. I guess if you need to go via more than 1 hop, it can get slow though.
Yes, totally agree that its not always applicable. But I think there is still lot of scope to offload some operation (e.g. magit operations like status, commit, streaming search result into minibuffer in ivy-mode). Having a dedicated protocol would of course be best (VSCode Remote works flawlessly for me).
>> What is the problem with mono repos?
If you use things like that depend on something like ivy/vertico/... find-file-in-project, projectile-find-file, ripgrep gets super slow (I think the reason is that they usually wait for entire result to be ready). LSP/Eglot gets slower. Similarly, will have to disable most of VC related stuff like highlight diff on fringe. Git will be inherently slower, so magit will hang your UI more often. Of course you can disable all these plugins and use vanilla emacs, but then if you remove enough of them you're likely going to be more productive with VSCode at that point.
Just to clarify this is experience with monorepo + tramp. Also not sure how much of its just plugins fault. Somwhat better if you use emacs locally where the monorepo is, however that often means using Emacs cli -- which usually means lose some of your keybindings.
From 2022. Funny that soon after that we figured out how to automate the Tactical Tornado programmer and collectively decided that they're the best thing ever and nobody needs other kinds of devs anymore.
I think people want multi-user because most people still need their laptops for work (or hobbies sometimes). Otherwise, I'd be on my phone (for casual messaging, media consumption). iPad is mostly just sitting around most of time, so it can be quite easily shared b/w people in same household.
>> some teams are just not permitted to contribute to OSS in any way
My understanding is that by default you are not allowed to contribute to open-source even if its your own project. Exceptions are made for teams whose function is to work on those open-source project e.g. Swift/LLVM/etc...
I talked to an apple engineer at a bar years ago and he said they aren’t allowed to work on _anything_ including side projects without getting approval first. Seemed like a total wtf moment to me.
I have never had a non wtf moment talking to an apple software engineer at a bar.
I can recall one explaining to me in the mid 20 teens that the next iPhone would be literally impossible to jailbreak in any capacity with 100% confidence.
I could not understand how someone that capable(he was truly bright) could be that certain. That is pure 90s security arrogance. The only secure computer is one powered off in a vault, and even then I am not convinced.
Multiple exploits were eventually found anyway.
We never exchanged names. That’s the only way to interact with engineers like that and talk in real terms.
Every programming job I've ever had, I've been required at certain points to make open source contributions. Granted, that was always "we have an issue with this OSS library/software we use, your task this sprint is to get that fixed".
I won't say never, but it would take an exceedingly large comp plan for me to sign paperwork forbidding me from working on hobby projects. That's pretty orwellian. I'm not allowed to work on hobby projects on company time, but that seems fair, since I also can't spend work hours doing non-programming hobbies either.
No, as far as I know, at Apple, this is strict - you cannot contribute to OSS, period. Not from your own equipment nor your friend's, not even during a vacation. It may cost you your job. Of course, it's not universal for every team, but on teams I know a few people - that's what I heard. Some companies just don't give a single fuck of what you want or need, or where your ideals lie.
I suspect it's not just Apple, I have "lost" so many good GitHub friends - incredible artisans and contributors, they've gotten well-payed jobs and then suddenly... not a single green dot on the wall since. That's sad. I hope they're getting paid more than enough.
The question is what are they doing about "getting safety right" and are they doing enough. To me it seems like all the focus is on hyper growth, maximum adaptation and safety is just afterthought. I understand its competitive market, and everyone is doing it, but its just hollow words. Industries that cares about safety often tend to slow down.
reply