Is Julia's Juno IDE going to be affected by this?
Sunsetting Atom
511–520 of 880 posts
Re: Sunsetting Atom
#512Re: Sunsetting Atom
#513Earlier quoted context omitted.
Very much so. As the first Electron app we were so excited about people being able to do anything they imagined. It was cool but ended up really constraining us. This time we really want to drive our API based on the most important things people actually need to extend. We need to navigate the trade-offs more intelligently.
This is interesting. I wonder how Emacs solves that, given that it's one of, if not THE most, extensible editor out there. I'd think that is a good thing, but never considered the drawbacks, besides performance and plugin interop that is.
Design-wise, Emacs is less an editor with an API and more a set of core editing concepts (buffers, strings with properties... etc) embedded into a flexible language. The core concepts have a native implementation that's hard to change, but they're simple and flexible enough that you can put them together to do all kinds of text-editory (or even not-so-text-editory) things.
Everything on top of the core is written in an open style, with Lispy features that make it easy to hook into or modify anything. Adding a small feature to Emacs doesn't feel like calling APIs from an existing application, it feels either like writing my own code with text editor stuff available as a library or, alternatively, like tapping into and fiddling directly with existing code in the system.
This way of seeing Emacs explains both why it's so flexible and why certain things (better performance on long lines, concurrency) are so difficult: you can express a lot using the core concepts and you can easily change other code that's expressed with these concepts, but making fundamental changes to the core itself is far more difficult. Partly it's more difficult because it's an old C codebase pretty separate from the Lisp world but, more importantly, it's difficult because substantial changes to the building blocks will change or break existing code in ways that are hard to control or predict. It's the very flexibility on top of the core that makes the core itself hard to change, since the higher-level Lisp code is using the core concepts in all kinds of ways.
Re: Sunsetting Atom
#514Founder of Atom here. We're building the spiritual successor to Atom over at https://zed.dev . We learned a lot with Atom and had a great time, but it always fell short of our vision. With Zed we're going to get it right. Written in Rust, custom native UI framework, engineered to be collaborative. Just starting our private alpha this week, so the timing of this announcement feels quite fitting. Here's a talk I gave l…
Please make zed capable of running in a terminal. If I could have a modern editor that can run in the terminal and had a nice GUI, I would definitely pick it up. There's still many instances where I'm working on a remote dev machine, on my iPad, over a serial connection, inside of tmux, where a terminal based text editor is a necessity.
Does a single text editor exist that supports both a TUI and GUI mode?
Re: Sunsetting Atom
#515I know a lot of people love vscode but are there any people who have tried something like IDEA/WebStorm/PHPStorm/etc that then went back to vscode? I had to help a developer setup deploys to a dev server from vscode the other day and I wanted to pull my hair out. I'll admit it's at least in part due to not using vscode myself but I was a heavy Sublime Text user which is very similar to vscode when it comes to how you…
I switch back and forth between IntelliJ products and VSCode. As a pure editor I prefer VSCode. It's fast and has a great plugin ecosystem. Another great feature is that it's config is just a JSON file that I can put into git and push it to my dotfiles repo making it easy to share config on all of my machines. However, there's just some functionality in IntelliJ that I miss in VSCode like running tests. Of course the…
Depending on the language (I've seen it in Rust and Deno), VSCode has inline buttons that appear over individual tests to run them
Re: Sunsetting Atom
#516Earlier quoted context omitted.
Atom practically invented the kind of extensions that VSCode had, and even several years into VSCode's life Atom far outstripped it in Extensions. Perf became the biggest problem however, which VSCode took over.
Sublime, TextMate, …
I love Sublime, still my fave
Re: Sunsetting Atom
#517I know a lot of people love vscode but are there any people who have tried something like IDEA/WebStorm/PHPStorm/etc that then went back to vscode? I had to help a developer setup deploys to a dev server from vscode the other day and I wanted to pull my hair out. I'll admit it's at least in part due to not using vscode myself but I was a heavy Sublime Text user which is very similar to vscode when it comes to how you…
Totally agree, if I'm gonna put effort into building my IDE it's gonna be vim or emacs. I use nvim most of the time and intellij on occasion for debugging.
lol, I jump between Vim and NetBeans almost on a daily basis! So it seems I'm not the only one who follows a similar pattern after all.
Re: Sunsetting Atom
#518In other news, the Atom One Dark color theme is alive and well in the VS Code marketplace. I've used it for 5 straight years. https://marketplace.visualstudio.com/items?itemName=zhuangto...
Re: Sunsetting Atom
#519I held out for a year or so after VSCode was released. It felt scummy how MS had swooped in and tried to hijack this new category of editor that GitHub had invented (this was before they'd been acquired, I believe) But once I tried VSCode... man, there was no going back. It was infinitely more performant and cohesive. Atom (with IDE-like features installed) felt so sluggish by comparison. I think the main improvement…
> Atom extensions could have dependencies on each other
This. This always has been and always will be a critical ecosystem mistake.
The principle of one msi/exe installing everything you need on Windows, one click downloading an entire app from a store on Android or iOS is seamless and almost always error free. Or in your example with VSCode having self contained encapsulated plugins that install with one click.
Meanwhile I'm having issues installing things and resolving dependencies with pip in python, apt in linux, npm, etc. basically all the time. It's a shit system that only pretends to be elegant and it's time we fucking admit it to ourselves. Designed by elitist morons for elitist morons and everyone else is paying the price.
Re: Sunsetting Atom
#520Earlier quoted context omitted.
I looked into that plugin but we don't run any special daemon/server for editing on our servers (nor do we want to).
Maybe don't edit on a server. Have you heard of git?
+1 for remote ssh. If you can SFTP to the box you can use this feature.
The only possible wrinkle is the developer box needs the build toolchain. If you're writing python, your remote box obviously already has it to run your app. But if you're writing Rust or golang, it's very possible the remote machine doesn't have the compilers.