Sunsetting Atom(github.blog) |
Sunsetting Atom(github.blog) |
So end result is only editors exist are feature complete long time back/ or maintained by companies who could just give it for free, compensating it with cloud revenues. Besides a couple of paid editors with insignificant market share of course.
Idea stuff is just way too bulky for me. I don't like using any of them, sacrilegious as that may be, and don't feel the need to use them for since I don't use java. Paying for Sublime is just not worth it with its far poorer plugins and API and their release cadence is atrocious. I checked Nova from Panic out and it looks promising but it's VERY far from being a replacement for my current setup
So I see almost no reason to switch from vim and VSCode, both of which are free and have extensive plugin support and are great at what they do. If something comes along that is faster, has good language support and good list of extensions, I would have no trouble paying for it
> It’s worth reflecting that Atom has served as the foundation for the Electron framework, which paved the way for the creation of thousands of apps, including Microsoft Visual Studio Code, Slack, and our very own GitHub Desktop.
This is so true! Atom spearheaded a new generation of exciting apps and set them up for success. That is a huge achievement on its own - so thanks Atom team for everything you have done!
But when VSCode came along it was over for my time with Atom. Wish the best for the new spiritual successor though zed.dev.
It was just such a nice editing experience.
Also never got on the vscode train and opted for neovim instead (been using vim and bindings since 2012)
Really expected and unsurprising.
The situation now is:
* Sublime for the Williamsburg corpo-hipsters
* emacs and vim for the wizards and furries
* VSCode for all the normies who just want to get on with doing their job and don't feel a need to express their identity or politics through choice of editor
* WebStorm for the chads with the monster rigs to run it
It's also noticeably slower than Sublime, which makes switching hard.
But "Williamsburg corpo-hipster" feels off the mark. To me Sublime aligns more around the "JS minimalist" camp, which overlaps a lot with the "bootstrapped and profitable" crowd.
I mean, just that phrase sounds very "Williamsburg corpo-hipster" to me. Minimal, artisan javascript.
Apple would try to switch everything towards their walked garden, no questions asked. Google would shut stuff down every two years. Oracle... I'm not even going to bother.
Amazon and Facebook could be interesting. Facebook is a bit shady, see the Oculus Facebook account debacle, but they're decent as stewards of dev tools. Amazon is also quite reliable for dev tools.
Would anyone really big be a better steward? Did I miss someone?
Right now I am using a very stripped down VSCode, which is.. fine. It works. I don't love it but it gets the job done usually.
Any other good editors on the minimal side? I need a bit more than vim/emacs, but I don't want or care for autocompletion or anything that alters what I have written. I don't need vcs support. I don't need a built in terminal. Just a good, simple and fast code editing experience with modern ergonomics and syntax highlighting that works across every language.
Seems like just another kind of identity: The self-titled "normie" who glances over at the "corpo-hipsters" and "wizards and furries" and smugly pats themselves on the back about how they're so much better because, unlike everyone else, they just want to "get on with doing their job"...
This entire time I thought I used Sublime because it was a fast enough, full of features, battle tested editor, that also wasn't a bloated IDE nor an exercise in self flagellation (i.e. choosing to use an command line editor with a high learning curve like Vim or Emacs).
The conflict between Catholics and protestants in northern Ireland is not actually about subtle differences in religious doctrine.
I have to say that I built so much muscle memory in those years that it is kinda hard to realized I'm not using Vim, and there is always something not-quite-like-vim in VSCode-vim that usually gets in my way.
(To be honest, the only editor that I found that is really close to Vim without being a Vim-thing was GNOME Builder.)
I'm pretty sure Sublime has a plugin that uses an actual NeoVim instance to process all inputs with all your configuration. Never tried it, I don't use Sublime. But I can confirm the feature works well in Firefox via FireNvim.
…respectively? TIL I’m a furry.
Facebook/meta seems horrifying. Some of their tools are indeed great, but I can just imagine having to use a facebook login to push code to GitHub or to download VSCode plugins.
Amazon is problematic for similar reasons as MS: since they are one of the biggest application hosts out there, bad incentives exist in terms of potentially allowing biases in their tooling to preference their own platform.
I'm reluctant to use VSCode because of M$ pushing for its tooling, but it looks like I will have no choice on the long run.
Is there anyone in the same boat? Which highly configurable text editor can be use for this?
https://www.reddit.com/r/AMA/comments/8pc8mf/im_nat_friedman...
Not surprising. When this stuff happens is always lies because you plan for people to forget about stuff as times goes by, which usually happens.
I think Electron is an amazing legacy to leave. Like many I would like it to use less resources, but it is still a grest idea.
If VS Code were not exceptionally good, Atom might have had more of an opportunity. But "yet another good option" is not enough to drive investment, sustain a community, and spin an ecosystem.
Edit: Fixed typo (thanks torstenvl!).
Perhaps you meant impetus?
There's nothing competing about Atom. Its fate was sealed when VSCode started gaining traction, and that happened before GitHub acquisition.
I will not be switching to VsCode just on principal. Yes, I'm still using Github, so I guess I'm a walking contradiction.
I also understand the economics of this situation why keep Vscode and atom IDE can't co exist, i'm surprised it took so long.
This is the second software application that Microsoft has ruined, remember the incredibly awesome wunderlist?
Sometimes it feels like I live all alone with my hate for Microsoft/Gates, but I'm glad I'm not alone.
It's legacy the minute we don't feel like adding any more features to it.
I'm being snarky for the sake of clowning on corporations who do this.
I'm sure the choice of Rust was made on the shoulders of many existing issues in atom. However, it bothers me incredibly when a product advertises itself as being built with a specific language. If that's your main selling point (it's in the headline for zed.dev), maybe you're about to build something utterly irrelevant.
But technically, as far as I know, they are both pretty similar.
So where is the difference? Are these just small details which VSCode got better? Or are there bigger things?
Or why else did VSCode actually won?
I have used both in the past. VSCode seemed a bit snappier, which is an important aspect for an editor. But I'm not sure if this was really the case actually. Or also, why there would be such a difference. Both used Electron, and I assumed both would use similar techniques for the editor.
https://code.visualstudio.com/blogs/2021/11/08/custom-notebo...
https://code.visualstudio.com/docs/datascience/jupyter-noteb...
The second big innovation was the language server protocol.This allowed any language to be supported by VS Code.
It also sounds like VS Code took a much more measured approach to extension APIs than Atom did. In Atom nearly every part of the product was an extension, which is a great approach to dogfooding extension APIs and making sure everything including the kitchen sink has an extension API, but getting that performant is tough. Whereas VS Code was very careful in the early days in what extension APIs they declared and started from a place of performance first. In many cases if only a single extension doesn't perform well in VS Code you almost don't notice because it's mostly isolated from the rest of application performance. Atom had a lot more situations, from what I heard, where one badly performing extension brought everything to a crawl.
On the topic of performance - one of the architecture decisions that VSCode nailed was the 'extension host' (https://code.visualstudio.com/api/advanced-topics/extension-...): all VSCode extensions are sandboxed in a child Node process, and can only communicate back with the main IDE process via the VSCode API. This has huge benefits for performance:
(1) extensions can never block editor startup. this was a huge problem for Atom as package loads were startup blocking and it wasn't uncommon to have multi-second startup times with lots of packages installed - especially due to the fact that JS packages typically repeat dependencies, resulting in tons of bloat. Also extension authors are rarely performance-conscious
(2) extension code can never block the core rendering thread, another huge problem in Atom - you'd often have stuttering/frame drops if extensions were doing blocking work on character or cursor changes, which was more often the case than not..
The tradeoff of course is that VSCode extensions are very limited in the set of UI customizations they can make but MS did a very good job of designing their APIs to be sufficiently extensible in this aspect (i.e. having APIs for extensions to hook into all core IDE features). Atom's extension ecosystem was much more fragmented resulting in dependency/versioning hell.
As a side note, another benefit of the extension host model is how it enables extensions to semi-magically work on remote filesystems (including inside WSL) without needing complete rewrites.
Reminds me of how Adobe killed off FreeHand (the only competitor to Illustrator at the time) by buying the parent company and then halting development.
Of course, Microsoft likely gave zero shits about Atom as a competitive threat since it was effectively dead at the time anyways, but I still think it’s interesting to see the similarities to the Adobe situation.
> Microsoft likely gave zero shits about Atom as a competitive threat since it was effectively dead at the time anyways
How can Microsoft both give zero shits because it was effectively dead, while also still being the primary reason it died? That seems to be a chicken-egg problem.
It seemed to me that there would always be an endless cycle of boom and bust with editors. It was a cycle with more in common with fashion than craft, and I wondered if I might end up wasting an inordinate amount of time switching editors throughout my career without any upside. So rather than switch to Atom, only to switch again a few years later, I set about with adopting Vim.
The choice seems to have been correct as there will always be a new editor (that's more or less the same as the old editor) that catches hold, but I wanted stability. Vim gives me stability, and the only other editor I'd consider would be Emacs for similar reasons.
If you are coding: Unless you are using IntelliJ (which a ton of of my colleagues do, and love) - it's a vscode world. Everyone at every company I've seen bangs away using that. It's kind of amazing how much inertia it's picked up (currently).
If you are working with text: 90% of the time if I have a couple gigabytes of text I need to do a lot of work with - it's Sublime Text. Actively Developed. A really solid text plugin architecture. The other 10% of the time I still use vim - mostly because it's in my finger DNA. Emacs is the obvious alternative which lots of smart people I know use.
I'd be interested in knowing if there are people who have used all five of these for > 100 hours that would recommend something else - (I haven't used Emacs that much - but I have well over a couple hundred hours on each of intelliJ/vscode/vim/Sublime. Probably close to 1000+ hours on the last three). (okay, small fib - close to 5,000+ hours on Sublime. I spend almost as much time in that tool as I do bash).
vim -> Sublime -> Emacs -> VSCode -> Emacs
^^^^^ I am here.There are three nice things about it: it flips vim's <verb><motion> into a <motion><verb> (like kakoune); it's got tree-sitter support out of the box (including for navigation); it's got LSP support out of the box.
Its keybinding is perhaps in "uncanny valley" of vim's. Overall, it still feels well thought out.
vim -> Sublime -> vim -> Emacs -> vim -> VSCode -> vim
^^^ I am here.Sublime -> Atom -> Vim -> Emacs -> Emacs -> Emacs -> Emacs
But realistically? A significant majority of developers use Visual Studio Code; Atom is still only being used by absolute diehards. Visual Studio Code's complete supplantation of Atom (with which it competes for resources in the same organization) is why we're having this discussion.
But I do think Emacs will be fine. I don't think VSCode is an existential threat to Emacs in the same way Toyota is not a threat to Lamborghini. VSCode boasts impressive numbers, but it does so by consolidating in a target demography that was never a stronghold for Emacs to begin with - partly due to some level of indifference on its part. On the other hand, there are things Emacs is uniquely suited for, and for that reason it will continue to attract a particular type. I think in terms of absolute numbers Emacs userbase is still increasing, and I think falling numbers in terms of total percentage doesn't mean much for its survival.
Also totally subject for discussion: I suspect VS Code will see more innovation in years to come.
I think I’ll try it again after seeing the news about Atom.
[1]: https://nova.app/
"Atom community involvement has declined significantly"
Probably because it works well enough, some tools don't need endless enhancing
Every time I try to go back to Sublime, this annoys me right off the bat and I'm back in VSCode by the end of the day.
I used Brackets too back then and tried Atom a few times but it was always too slow and laggy. I was so glad when VSCode came out and that it was actually good. I was in the midst of switching to VIM but it was just too much of a bother.
If you use your text editor professionally, they more than worth the investment.
And if you want to build a text editor for your own needs, Emacs and Neovim are your friends.
It's hard to find anyone who'd say they overall like Microsoft as a company. VS Code is one of the very few things Microsoft has made that people actually like.
I recall reading a comment here recently that they've actually create an entirely new generation of children who hate them by recent changes to Minecraft. Supposedly they forced everyone to migrate their accounts to Microsoft accounts, and in the process wiped a bunch of save files.
Microsoft happens to every generation at some point!
Would it have survived if Microsoft didn't acquire Github? It's possible, however unlikely. But after the acquisition? Not a chance.
And the reason I went back to Emacs is because of elisp and M-x. Those are the true killer features of that editor, still unrivaled.
Now I just need to install keymapper and convert all my M-w and C-y inputs to Ctrl-C and Ctrl-V.
Just found this. It’s a shame. I donno why but I just liked brackets interface.
The entire editor being easily tweakble is the killer feature of web-tech based editors.
Sublime may have opened up more customizability since then...
It's amazing how much a minor annoyance can drive someone to a completely different solution.
Or through the Gui - "Preferences --> Package Control"
In VSCode, I can browse info about packages without having to remember a thing aside from "one of the six big icons on the left is 'Extensions'". One mouse click, start typing, click anything that looks like it might be good, get a ton of info and an "install" button. There are filters! So I can simply sort by "most popular" if I want, or by name, or a bunch of other things, all without having to remember anything for this somewhat-infrequent operation, because it's in the GUI.
It's mainly the integrated package exploration that's missing. And the auto-suggestion for plugins—in fact, I rarely have to do any of the above, and just click "OK" to whatever VSCode suggests, and everything's fine.
Sublime has (I just checked) a "package discovery" command, which... opens a web browser, to the exact same page you'd have ended on if you'd started by just googling it (which is what I do). So you have to find what you want on there, then go back to Sublime and find it again.
The result is that in the best case it takes me 1% as long to install what I need on VSCode (just click OK), and worst case it takes me perhaps 50% as long, compared with Sublime. I'm also way less likely to go poke around and see if there's anything that might be useful, in Sublime.
[EDIT] "Why aren't you way more familiar with the command palette?" ephemeral shells as anything more than dead-simple launchers make me really uncomfortable. I hate using them. Apple spotlight? I use it extensively—only for launching programs, period, nothing else. I'd much rather have a persistent shell environment I could attach from any terminal and leave open.
I do love the fact that, with Sublime, that 75%+ of the time when I want to do something, say, pretty-print a JSON text document, it's just:
Ctl-Shift-P, "json" (Don't see anything obvious)
[hit backspace to clear json] "Install Package", "json"
See the "Pretty Print" option, install it in 2 seconds, and on my way.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 last month: https://youtu.be/wXT73bBr83s
Please don't forget about accessibility. Getting this right from day 1 will make your life a lot easier in the long run. If I remember correctly, I was never able to use Atom with a screen reader. Hearing custom UI already makes me nervous and I'm pretty sure I won't be able to use Zed with a screen reader either.
Blind developers exist. Please don't forget about us. It's one of the few areas where we can actually make a meaningful difference together with our peers on an equal playing field.
I'm not blind so for sure I won't really care about accessibility but honest question why not use an ide developed for blind people instead of using the same as non blind people?
Our goal is to make Zed fast, stable, and collaborative first, extensible second. We'll be taking a more conservative approach with our APIs to ensure we can preserve our core values even as users add extensions.
Our goal is for Zed to have the lightweight and snappy vibe of Sublime with the power of a more full-featured IDE. These objectives are obviously in tension, but I think we can build something that balances them well. A collaborative IDE that feels fast and powerful.
Perf became the biggest problem however, which VSCode took over.
I started using atom pre-1.0, a long, long time ago. I immediately jumped to vscode when I realised it existed.
The reason is a bit weird; it's the find-in-files/project (c-s-F/Ctrl+Shift+F) sidebar search/replace feature. Compared to the Atom (and from what I can see in the youtube talk, zed has the same "problem") which opens c-s-F results in the main window, vscode opens them in the sidebar and doesn't clutter the main view with it.
The reason this is powerful to me is that I code mostly in domain-specific, esoteric, private languages that have no API documentation, no stdlib or docs, and no online resources to learn from. So the only way to learn is by example, or talk to someone who knows. Learning by example is usually much faster than talking.
So what I do is any new project is just a subfolder in a workspace that contains all known code in the language and the way I find out how to do something is c-s-F.
When the results cover the main view, or even parts of it (which is also possible with atom), it's just way too intrusive. The sidebar file list is useless to me at this point - where the result comes from is irrelevant. So why not use that space?
Also of course the fact that vscodes cross-file search was blazingly fast was an upside as well (I believe they used ripgrep for that since the start?)
Another thing I want to mention is (and you highlight the keyword search in that youtube talk around 18:54) the power of the command palette search method that is available in vscode: first-letter-matching. I don't know what the proper name of it is, but essentially "ps" matches "pub struct" for example. Obviously it matches it with a lower score than something that starts with "ps", but it's very powerful for matching in the command palette.
Thanks for listening.
Jesus, who are you?
vscode _has_ added an non-sidebar find interface somewhat similar to the atom one -- but its not as good ... for one thing it doesn't support replace (find only)
* Do you already have a working editor I could test or is this merely an announcement?
* Is this an open source project or a proprietary product? Does it cost money? If yes how much?
- It's in closed alpha, so yes they have a product, no they don't have a product.
- It is a closed project. It probably will cost money, it is not decided how much.
"Real-time collaboration produces better software." At design level, ok. Programming is in most cases not a co-op operation. If it is, then you are probably creating solutions while writing code which is the best guarantee for bad solutions.
“Conversations should happen close to code.” Agree to some degree, this is a big flaw with GIT. It is also a flaw with many programming langs and tools. Even if I use collaboration features in VS and VSC many langs are simply not designed for presenting code to people not highly familiar with the specific code base. So, an editor may not solve the problem here.
“Your editor should disappear.” I mainly code in VS and what I can do in VS in 10 mins takes me a couple of hours in VSC. A tool should aim to be the default of a problem. The amount of time I have seen wasted over the years with people trying to master VIM or git from a prompt is just ridiculous.
Cool project, but this is clearly a contradiction.
wxWidgets? That offers a native UI. Wherever possible it uses the UI controls from the underlying OS/system to render the interface.
Looking at the project page it describes "a GPU-powered UI framework that met our needs."
That's not a native UI. That's a non-native UI compiled to native code, ala something like Flutter.
I've never been impressed with native UIs in any platform, web or mobile. The only context where I appreciate them is accessibility.
Best wishes for Zed's success!
I tried using VScode and Atom. Both were noticeably slow compared to sublime text. I can do silly, bad practice things like open a 50 meg log file in sublime and search for simple regex in the editor. Electron based editors stall and potentially crash.
I routinely (like every day) open 500 megabyte files in SublimeText, and just checked to make sure that it can handle 1.5 Gigabyte files without much difficulty (it can).
Admittedly - once we get into the 5+ Gigabyte file size, startup times become annoying enough that I usually switch over to vim.
So, thank you for bringing this up as an important requirement for modern text editors - they should be able to open up multi-gigabyte text files without even breathing hard.
You should be able to open stupidly big files and shouldn't experience much to any lag. Nathan has a demo he likes to give opening one one of those huge json files and searching, using multiple cursors, etc. It is pretty cool to watch.
Looking forward to its spiritual successor!
Since it's not mentioned on the website, what will be your roadmap regarding security?
I feel that all IDEs have security handled as an afterthought, VSCode made some progress but it's far from being there.
I just want to be able to use a code formatting / language extension without having to worry about it subverting my whole computer in a future update.
vscode is halfway there with containerized development, but apparently they didn't intend that to be security measure and they make it clear to only run trusted extensions. I'm guessing there are ways to access host files through the bridge.
It's obvious that we still have to trust extension authors, but an IDE with the correct security sandboxing can limit the blast zone if it gets compromised (leaking a source file vs getting a rootkit installed and ending up releasing compromised updates to production)
What will undo be like for a collaborative editor?
I hope you would have some solution to this conundrum.
I use live share all the time because it's the best thing we have for pair programming, but I often wish for a better solution. We often get disconnected for no reason, editors get out of sync, terminal sharing is near useless.
If you can produce something that doesn't feel like a hack, then I'm all in!
Features I would love to have:
- Terminal sharing should work like tmux with window size "smallest". It's the best solution I've found for having a shared terminal.
- Let us join a collaboration session from the terminal: `zed [URL]`. No annoying website that takes ages to open, or having to open the editor before joining the session.
- Let me start a server on a port and let others join that server. I can forward that port if I need to.
- Let me start a headless server on a shared dev env, and let me and others connect to collaborate
I'm asking because I like to use my laptop Acer Aspire One most because of the size and because it the incredibly good feeling keyboard. BUT the system is 32-bit and running Intel Atom which means that before VSCode moved away from 32-bit I could use it, but it would take some time to open and I wouldn't really call it writing in real time, if you know what I mean~ :D
But I love the keyboard shortcuts and the multiple cursor functionality, which is why I stuck with it for as long as I could!
Very excited about where this new collaborative editor goes!
But saying that you’ve decided to “sunset” or “archive” it, telling users to plan for their migration, seems counter to the notion that open source software forms part of a commons - something that Github, of all companies, should understand.
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 was how opinionated VSCode and its extension APIs were; Atom extensions could have dependencies on each other. I remember you had to install an extension for generic IDE hover-overs and such, before installing the actual language plugin, and then there were competing standards for which generic hover-over framework each language wanted to use. It didn't just complicate the user-experience, I'm convinced this was the reason the editor would get so slow; the APIs were too low-level and all the plugins were fighting with each other instead of going through standard channels.
But, Atom will always have a special place in my heart. It blazed new trails in editor customizability (even if the degree ended up being its downfall, quite a bit of that legacy can still be found in VSCode). It invented the entire concept of web apps as desktop apps, which despite what some here would tell you, I think is a very good and important thing. And it always had such a fun, community feel to it that's been mostly lost with VSCode.
It was time, but I will miss it. I'll close off with the very cute and fun Atom 1.0 announcement video: https://youtu.be/Y7aEiVwBAdk
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 find/configure plugins.
I understand that vscode is very powerful and infinitely extendable but I feel like I shouldn't have needed to try 4-5 different vscode plugins (all configured via json) before I found one that worked and did what I needed.
At least 2 of the top downloaded plugins when searching for "SFTP" were read-only/archived on GitHub, the top one had a "reloaded" version which was also discontinued from what I could tell.
I'm comparing this experience to IDEA which has this built in (including support for deploying to multiple servers at the same time) and all configurable in the GUI.
Maybe I'm just getting old and cranky but vscode seems to get unwieldy very quickly (plugin conflicts, not being able to tell what's doing what, writing almost all config in json). The plugin ecosystem seems to be much lower quality that I what I see in the Intellij product line. I guess I'm just not interested in "building my own IDE" and forever tweaking it, I'd much rather buy a product that does almost everything I need in a sane way.
• Atom has not had significant feature development for the past several years
• (thus) Atom community involvement has declined significantly
• (thus) we’ve decided to sunset Atom
Feels a bit weird in that sequence to blame the community. Just say that YOU have abandoned the project since Microsoft acquired Github and get done with it, no need to sugarcoat it or others in the way.
Last blog? 2019.
None of the releases did anything interesting. I work in Vue.js and needed that toolchain to work well, it never did with Atom.
So they're blaming the community for something they decided years ago and kept deciding every week when no resources were allocated.
Also, Zed isn't filling the void Atom left. Rust is interesting. Collaborative editing, not so much. Electron's lack of speed doesn't prevent VS code from fading into my workflow and being the most popular editor. I would still like an alternative because I don't think Microsoft should have the whole market.
Asking genuinely, why not Sublime Text? (I haven't tried it or Atom in several years, but used both back in the day).
But it's still really sad to see. I use it because it was trivial to CSS style it to match my Desktop. It's comfortable to me in a way that other editors thus far have not been.
Are there other editors with this level of customizability? I know VSCode and Sublime support theming but from what I can tell it involves installing pre-packaged themes.
Emacs can go from this: https://emacshints.files.wordpress.com/2013/09/spash1.png
https://code.visualstudio.com/docs/getstarted/themes#_custom...
You have to package it if you want to make it easy for other people to install, but if you just want to play with it, just open settings.json and start feeding it colors.
https://marketplace.visualstudio.com/items?itemName=be5invis...
I still remember the day VSCode was announced, and the binary on macOS (inside ./Contents/MacOS in the app bundle) was literally named Atom.
great fonts, minimal visual clutter etc
For the colors at least, there are VSCode themes that will try to mimic it for you
Your work made more impact than you can possibly know. Atom became my absolute #1 editor. For code, and notes of every possible kind. As an entrepreneur, it carried me through so many adventures. The death of a cofounder, great losses and victories, the madness of 2020, a close friend's betrayal, a subsequent rebirth of sorts, and on and on. And always, this trusty piece of software sat there. Ready whenever calamity struck.
Thank you, folks. You created a wondrous piece of art and greatly impacted this entrepreneur's way of thinking and organization. Many have gained as a result.
Will follow Zed closely!
What I appreciate about Atom is that it is very simple right out of the box and does not get in your way. You cold always beef it up with packages later, but that progression is much more pleasant to me than the VSCode approach.
The biggest selling point of Atom to me as a Python dev was the Hydrogen package. That tight integration of notebook features within the editor is something I have never seen before and a total game changer. Especially if you are working with data that you might need to visualize a lot. Correct me if I'm wrong, but from what I understand there is no Hydrogen equivalent in VSCode? Sure, there are plug-ins that let you run your code through a jupyter kernel and display the output in a second terminal pane, but that is not the same as the ability to simply highlight a bit of code, run that and have the results displayed immediately on the next line below. Having pyplot figures displayed in such a way is also not possible from what I saw, or did I miss something?
IntelliJ has a pretty damn good track record for me, when I import a project it indexes for a minute or so, then it automatically knows the entrypoint to run the project, and has a fantastic understanding of all my code. Cmd+click any symbol and it can show me definitions, usages, implementations, etc. I can hit shift+F6 to rename a symbol, and it hits every usage perfectly (as opposed to every time I've tried to use VS Code to rename something, and it just causes me more problems than if I were to do it manually). I haven't found any other text editor or IDE that works as seamlessly in this regard, and it's a dealbreaker for my productivity.
I see people complaining about the death of Atom, but in the past few years there just hasn't been a use case where Atom was the best choice.
I suspect that what actually killed this is the acquisition of Github by Microsoft and the fact that Microsoft are pushing VSCode very hard. Dev tooling is something Microsoft had a lot of experience (and failures) in and it was always an uphill battle.
It’s not free, but if you’re really strapped for cash you can use it like most people use Winrar, at least until the guilt overcomes you.
I recall reading about typing latency and it seemed to come out as one of the slower options: https://pavelfatin.com/typing-with-pleasure/
I guess it would have occupied a similar place as Brackets, another vaguely similar project? https://brackets.io/
Then again, with how popular VSC has become and with how insanely many extensions there are for it, using any other editor feels a bit... counterproductive at times?
Personally, i'm using the following:
- CLI: nano (vim works too, I just like the simplicity more)
- Simple text editing: Notepad++ or similar (usually whatever is on the system on *nix)
- Some scripting, but nothing too serious: Visual Studio Code
- Development in larger and more complex codebases: JetBrains products (e.g. IntelliJ IDEA, WebStorm and so on)> Atom has not had significant feature development for the past several years, though we’ve conducted maintenance and security updates during this period to ensure we’re being good stewards of the project and product.
Because MS made sure it didn't get any?!
> As new cloud-based tools have emerged and evolved over the years,
Big player being VS Code and Codespaces?
> Atom community involvement has declined significantly.
Because MS made sure the community was NOT backed with actions?
> we are archiving Atom to prioritize technologies that enable the future of software development.
This should be the first sentence. Not last.
The merge conflict resolver is so intuitive and easy to use. I have colleagues who come to me for fixing merge conflicts even though I'm pretty mediocre at git in general :p My secret is I do it in IntelliJ
I typically do this when tidying up / amending >1 commit at a time (anything I can't do easily with git rebase interactive mode), or to resolve merge conflicts.
Sure VS Code has a lot of extensions, but many of them offer only basic features or are poor quality. The extensions which deliver the most value are actually the ones supported by large corporations (like the Go extension from Google or the Python extension from Microsoft).
If another editor could port these powerful extensions I would care very little about the lack of icon themes and snippet extensions.
Definitely is a software you can bet on.
It's not the lisp vm that incidentally happens to edit code that GNU Emacs is.
Or, as he puts it [1]:
> I use this abomination called "micro-emacs", which has absolutely nothing to do with GNU emacs except that some of the key bindings are similar.
[0]: https://github.com/torvalds/uemacs [1]: https://www.tag1consulting.com/blog/interview-linus-torvalds...
Since it is only happening in 6 months, I wonder if the community will try to transition/fork it.
Do you know if there is still enough interest?
VSCode's "Source Control" on the other hand is a such a big UX dumpster-fire that I cannot bring myself to even try using it any more....
Anyone on HN have recs [besides vim slime or send-to-terminal options in other editors, which work but are clunky] ?
I use `#%%` code blocks in the interactive window for this purpose: https://code.visualstudio.com/docs/python/jupyter-support-py
This allows a normal editor workflow, interactive execution, and linear history of executed cells. But the code blocks can still be executed top-to-bottom and exported as a clean notebook for sharing purposes.
I was dreaming of taking Vibe.d and CodeMirror and making something you could install as a daemon on any machine and code from anywhere. When Atom came out I was obsessed with it for a while, it was a whole other approach from what I was thinking of!
Did you ever do a write up on how you came to the thought of just taking a browser engine and turning it into your own sandbox and what that entailed in the earlier days? That seems like a fun story. Because of Atom we got great innovations that followed, for example Slack, Discord, VS Code, and the list goes on... and on... Heck POSTMAN! Which is probably used or has been used by every developer under the sun.
As for lightweight alternatives to Atom, there is also Lite-XL (https://lite-xl.com).
I think it could be interesting to compare notes re GUI frameworks (especially since the Druid community is about to see some overhauls there) but I don't think it would have saved them that much work if they'd done that from the start.
If you can make editor in Rust pluggable or scriptable with JS, Lua, C#, Python and whatever someone knows and is comfortable with you got a winner.
Pairing in VS Code over Zoom has gotten a lot better over the last year or two, to the point that I choose it for simplicity over more purpose-specific tools like VS Code Live Share (which is a bit slow/glitchy but fine, and overall "neat") or Tuple (which is great).
Would I pay money for "VSCode, but faster"? Absolutely. I'm waiting multiple seconds for keystrokes to apply sometimes and don't know why. But the extensions are what make it VS Code – if I just wanted "a faster text editor" I'd uninstall all my extensions and just keep using VS Code (it'd blaze), or switch to Sublime.
I'm excited to see more people working in this space, so I certainly wish you luck!
>When you move the cursor or type a character, you should see pixels on the next refresh of your display—every time. Even sub-perceptual pauses add up over the course of a day to create unnecessary stress.
I remember there were lots of research for this in Next-Generation Atom during the Atom era, before VSCode came along. Having a UI and text responsiveness within 16ms on a 60Hz Monitor is a tall order which I believe even Sublime is incapable of.
Considering 95% if not 99% of developers on HN thinks VSCode is very fast or fast enough, I am not sure this point is worth pursuing. Personally I really want to see it happen. As I hate latency.
I tried Atom for a while, but it didn't cope well with other IDEs renaming files before overwriting them. I tried to fix it, but the response I got from the community was rather dismissive. It was quite irritating to present obviously wrong behavior and be told that it was correct.
My attempts to dive into the code myself lead me down a rabbit hole of dependencies of dependencies of dependencies, to the point that I just gave up. I switched to vscode and it has mostly stayed out of my way.
Is Zed related to Xi in history or as inspiration? Why are you confident that Zed will be able to overcome the issues that blocked Xi's advancement?
Sounds like this won't have that. It's only a successor in the sense that it's built by the same people and tackles some of its challenges.
Looking forward to innovations in UI. Cause otherwise, VIM is comparable if not better in performance than modern text editors.
Interesting. I think a major reason for VS Code's success is their usage of web-stack, which is stable, powerful and well documented, enabling easy access to higher customizations for anyone. It will be interesting to see how much a custom UI can emulate this without html&css.
Of course, they share the problem that I can’t yet use either :)
If there is vscode that was written natively. I'd be so happy. Even if there is a new branch of vscode that is 6 months behind in features but is built in native it'd be huge for me.
For me Sublime seems to hit all the same spots without the web assembly plug in feature.
I know it's not the main point of the DevXConf presentation but I really like the look of that multi-buffer feature.
As a wishlist item, can we get a native vim mode with .vim.rc support? :D
I'm holding thumbs, I have been massively excited about your elevator pitch since your original announcement. Good luck!
Is Zed web-based or not? Would it be able to be hosted in the browser like the web-based version of Github Codespace (Visual Studio Code Online)?
https://youtu.be/wXT73bBr83s?list=PL3TSF5whlprXqwYNIM0X8mBzu...
For Julia, Atom+Juno was excellent. It was the first time I could select+run on a proper IDE (I was coming from python+notebook). To me this was revolutionary. Then I discovered VS Code, so Atom+Juno stopped making sense. You seem to be a very competent developer, so why not just contribute to VS Code?
We need people like nathansobo to try out new ideas and directions. I, personally, am very much looking forward to their WebAssembly-based extension system and Zed being the flagship UI application developed in Rust.
VS code is written almost 100% in JS and typescript, it will always be a nodejs app through and through without a complete rewrite. And even if they wanted to rearchitect VS code all of the extension APIs, extensions themselves, etc. would demand the existing nodejs runtime.
So long story short... VS code is a good editor if you want to contribute to a nodejs and web tech based text editor, but not if you want to explore other architectures or ideas.
No migration, sunsetting, "this is legacy, let s redo it all" will ever fix anything. Fix what doesnt work.
As someone that loved Atom, and have been screwed over by Facebook's Nuclide, and now Github's Atom, I have to think about my options.
(No emacs isn't an option.)
But winding down the project is still a major event, and I think that it is appropriate to call that sunsetting. The existing project organization will go away. The team will presumably dissolve, with any people being paid to work on it going on to other things. I've seen this happen enough times to know that it is, indeed, an end of sorts. "The community" is almost never large and organized enough to keep a project like this vital. At best, they can only slow its descent into obscurity.
Correct me if I'm wrong, but most projects started by some form of organization end up being dead after handing them off to the community. That is, unless they make their code from the ground up to be as most readable and modular as possible.
I remember many projects made by Sun Microsystems that just died when Oracle took over, even if the code is still there.
This is a responsible way to handle the ceasing of maintenance while allowing any and all interested members of the Atom community to fork and maintain versions.
I have a much more optimistic view of development communities than you do, and I expect to see Atom endure in some forms.
The problem, as I understand it, is that Atom’s relationship with electron makes it very difficult to work on the core of the editor. Namely, while VS Code is downstream from Electron, and can get feature benefits just by updating their Electron version, Atom is upstream from Electron, and new Electron features needed to be more manually integrated.
Instead of letting it slowly bleed out and randomly catching stragglers with outdated marketing materials lingering on the web, they give it a swift death. Atom can go into the history books as an open source project that defined the industry for a decade.
It isn't true anymore then saying Slack is rewrite of Atom. While it is using electron, editor and IDE aren't from Atom.
Atom and VSCode projects have always been separate projects. Both using Electron does not mean they share a codebase, not in the normal sense of the phrase.
One should make a difference between (1) access to the source code to look, find bugs, make minor adjustments and (2) everybody with that access to be able to actively participate in the development.
In the sense of (1), open source is "some part of a commons". That's what the license gives you.
In the sense of (2), open source may or not be open to a community approach. It's fully legitimate for some company or other group of maintainers to provide (1) but deny anything related to (2). You are free to fork and make your own community, but there is nothing that guarantees you that your pull requests are accepted or even looked at, bug reports reacted to or anybody listening to wishes, concerns or other opinions about the project. It's nice if that's provided, and one could argue that some part of the spirit of open source is to enable a community, which in turn helps the original creators (and could be a major motivation to open source something), but nobody should be upset if maintainers choose otherwise.
It's nice if it's clearly communicated how maintainers see this though.
1. I need feature X
2. I find library WeLoveX
3. Is WeLoveX a good investment for my larger product?
4. Ambiguity happens here
The ambiguity happens because I have one prominent indicator: release activity. If it's changing lots, does that mean it's active and a solid foundation? Or does it mean it's actually probably not quite ready for prime time yet and hasn't found stability? On the flip, if there's very little release activity, does that mean it's dead, the developers have moved on and maybe there's something better out there? Or does it mean it just does its job really really well and doesn't need a constant stream of tweaks?
It's nice to have a general statement of disposition towards the product by the original authors.
Honestly, it kind of sucks that at this point you might as well call a project sunset if it has ASF stewardship, and that we seem to practically need the resources of a large company to keep an open source project "truly" afloat.
I vastly prefer the honesty in saying "sunset"; it helps bring more light to this situation, and will perhaps drive new approaches to funding foundations like the ASF.
For the most part, when a different organization picks up the development of the project (if one does) it's a completely new project at this point (there are exceptions, such as a backing organization continuing to back the project, but deciding that it's better supported by an independent trust, and therefore building a transition plan for that).
The best example of this is looking at any Apache supported project today. There are very few projects that were handed over to the Apache foundation that people would want to continue using in their post Apache handover date, even if they were amongst the lucky few that still have active development (OpenOffice, for example).
Sunsetting is absolutely the right term/approach to use.
Especially, if there isn't a dedicated community to maintain it.
I'll take honesty over corp-speak any day.
That said we probably only get honesty, because they want us using vscode instead.
Speaking of packages - of the six featured packages I get offered on atom.io, only one had a release in the last two years, and half have been unchanged for half a decade. Atom's already dead.
Finished is a state more software should aspire to reach. Sadly, with the advent of connectivity in everything, it's getting rare for even firmware to be finished.
We should be counting down the days till they sunset VS Code to focus on VS Code "Pro".
The context of “embrace, extend and extinguish” has kind of been diffused over the years, though; it never meant “buy a product and kill it,” but rather meant adopting open standards and adding proprietary (not necessarily closed, which is not the same thing) extensions to them that end up becoming de facto standards, so your product is perceived as better at the task then the fully standards-compliant original. What happened with Visual Studio Code and Atom isn’t an example of this at all. For a start, they’re just two products that are competing in the same space; they’ve never had the same extension standards, so the idea of “embracing and extending” just isn’t relevant here.
Secondly, Microsoft obviously didn’t buy GitHub to shut Atom down. I’ve seen the arguments that once Microsoft did buy GitHub, Atom was doomed, but Code was already arguably more popular than Atom when Microsoft bought GitHub in 2018: Stack Overflow’s developer survey showed VSCode as far more popular among surveyed users (34.9% to Atom’s 18.9%). If those numbers had been reversed—if Code never made a real dent and Atom kept growing—then I have little doubt Atom would be the one continuing.
Lastly, I suspect the runaway popularity of Visual Studio Code is pretty good insurance against a hypothetical “Visual Studio Code Pro” replacing the existing VS Code. This would almost certainly cause a fork (or more than one!) to be created, and it’s highly likely such a fork would get immediate backing and support from one or more technology companies willing to pay for continued open source development.
However, I don’t think that’s likely, because I don’t think that’s how Microsoft is interested in monetizing Code. It’s not a source of income in and of itself. It doesn’t have to be. If it just so happens to have great GitHub integration, maybe your company will pay for GitHub enterprise features. If you’re used to using it, you may be more likely to pay for GitHub Codespaces. If it has a great story for deploying to Azure, then maybe you’ll be more likely to deploy to Azure. And so on.
My money is on VS Code 365.
Or when they sunset the closed-source PowerShell and created the open-source PowerShell Core?
Like those?
We're basically fucked.
Contingency planning for this could be a small but wise time investment for dependent teams. VSCode could very well go the way of the Do... Docker.
The point of MS/Github announcing that they are sunsetting the project is that they are basically no longer spending time and money on the project. Projects this size have a lot of things that need attention like security fixes, legal stuff, trademarks/branding, etc. Basically, they do the right thing here by giving people some time to deal with this in whatever form they care to do that before pulling the plug.
Anyone interested in taking ownership of atom now has six months to get organized; I'm sure if somebody steps up, Github would end up doing the right thing and e.g. support them by e.g. transferring domain names, and other things they control. But somebody would need to step up for that to happen.
Apache taking ownership of a project would require that there is some community still there to work on it. They have an incubation process for this kind of thing. But there's also a thing called the attic in Apache where dead projects go after they stop being maintained.
It’s not GitHub anymore though. It’s Microsoft and Microsoft must advance the Visual Studio brand.
They use open source as a marketing buzzword, not as a philosophy, and it shows.
I think perhaps TypeScript is the only counterexample.
They are a proprietary software and cloud vendor super house. They are very successful like that. Open Source is 3-4 level down to their main strategy.
fork the code and start a new project with resources to take care of those and many other artifacts if you are so inclined . you have the license to do so
I don't know if it started when MS bought them, but it's when I think the decline became very apparent.
One could imagine a world where strong standards have been established which would allow you to easily deploy lean native applications across a wide variety of platforms.
Instead we ended up in this bizzare world where if you want to maintain a desktop GUI app, you either need a large team to support multiple platforms, or you need to target minified javascript of all things, and run your software on top of a large, arcane compatibility layer.
FWIW: I'm probably one of the most "IT Conservative" people on this site, I still believe in sysadmins, dislike systemd, hate electron etc;
But there is something to be said about developer productivity: if you can build a prototype in 10 days when it would have taken 10 weeks that can be a huge differentiator between companies; it means you can make 6x more prototypes in the same time window, or work through different iterations of the same idea.
That's hugely beneficial.
I think if you treat inefficient things this way (I consider Ruby/Python in the same way) then we all benefit, test your ideas then go for gold on a more efficient platform.
And yet this didn't happen and Electron did. The "free market" of FOSS development settled on Electron as the winner for cross-platform development.
People wrote Java applets that were supposed to be same everywhere. It even had GUI.
Nobody expected that not Java, but _JavaScript_ will be the actual write once-run everywhere.
I may be wrong in the moment, but I base my arguments on trends. Processing power, storage costs and bandwidth are always improving. So human productivity should always take priority over efficiency as time progresses.
I'd vote for a real Web 3.0 based on first principles like declarative and data-driven programming, idempotence, immutability, one-shot scripting (perhaps even a Turing-INcomplete DSL) for initial render without side effects (like CSS variables but for HTML), dynamic element loading with something like HTMX, secure server-side includes, distributed databases using Paxos/Raft, even distributed computing with a real Docker that provides an actual secure sandbox and repeatable builds of untrusted secure/private code (maybe with something like homomorphic encryption). I can go on and on about what real (not phantom) tech looks like. And it looks nothing like SPAs.
Also I think a lot of people recognize the need for this stuff, so ideas aren't the problem. The problem is, always has been, and always will be funding. In fact, my single greatest disappointment about the modern web is that stuff like advertising and eBay got coopted so there was never a viable way to make enough residual income to live on after the Dot Bomb around 2000/2001. The closest things we have are Uber and donating plasma. So we have a generation of highly-effective programmers spending the most productive years of their lives at a day job making rent, which is why rent increases. Hustling without understanding that the hustle itself is the failure when viewed through this lens.
Blah I dunno why I write this obvious stuff anymore. It just ain't never gonna happen. It may as well be impossible. Or I should say, it may take another 20 years to get here, and I just don't think we have that long anymore.
It doesn’t really bring any advantage? You need to package whole Chrome with your app, the few MB you save with minification does not matter??
But people here can enlighten me.
Here is a unified binary format that can run on Linux, MacOS, Windows, FreeBSD, OpenBSD, and NetBSD too. They also boot from the BIOS.
But it doesn't support GUIs (yet?).
Electron clearly means that we end up with a bunch of apps that would be otherwise unavailable, while at the same time meaning that we have a bunch of embarrassingly bad GUI experiences from companies who can afford to deliver better.
Brackets was the foundation of Adobe Edge Code, which was part of Creative Cloud, so there were some bigger plans there.
Spellcheck always works, nothing ever crashes and acts weird I run it for 10+ months without issue. VSCode on my PC the spell check is inconsistent and weird and on a long enough timeline it actually crashes the whole operating system if you leave it open.
Examples for me would be: VSCode and Linear
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.
Any ecosystem has to strike a balance between which things should be opinionated/officially-sanctioned/standardized, and which things should be left open in "userspace". I think Atom made the wrong choice by outsourcing some very standard features to the community, like hover-overs and underlines. VSCode seems to have hit a sweet-spot, offering standard solutions for common functionality but leaving plenty of doors still open for people to build on.
Depending on what you consider the "category" to be, Sublime Text (2) was well-established for years before Atom came out, with BBEdit and TextMate before it.
Not to mention Kate, Geany, and the various other "lightweight extensible code editors" that have been out there for years and years.
Mozilla actually had that in early 2000 or so; their whole UI (before Firefox existed, even) was a webby. Except it was their own weird sort of webby and not normal HTML, most of the time.
Using normal HTML would be around IE4 with their .hta files, I think. Didn't seem to have too much uptake though.
There was prior art in the form of Bespin. GitHub’s innovation was electron and turning it into a desktop app. I think it’s amusing that VSCode has recently come full-circle and introduced a browser-based version.
I've been using VS Code for years to write JavaScript/TypeScript, Python, Go, Terraform, and CSS. My settings file is 60 lines, 42 of which are "for file extension X use autoformatter Y" configs.
When I first switched to VS Code I was frustrated trying to make it conform to random expectations I had. Eventually I learned that it's easier to embrace VS Code's defaults for 99% of things. I just want an IDE that works well (nearly) out-of-the-box and VS Code gives me that
I don't think it's a weird pattern, maybe a slightly legacy one but not out of the ordinary. I've seen this pattern used at multiple places (not implement by me). It makes sense if you have special use-cases where you need to use physical hardware and/or a local stack is too heavy or complicated to run.
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 there are plugins but they are all clunky and don't give you the great UX that IntelliJ does. I want the IDE to figure out where all the tests are and give me an easy way to run a single test/file/suite/feature. IMHO this is the killer IntelliJ feature for me.
I'm kind of surprised you did a deploy from VS Code. I would have assumed there was another tool for that. I do most of my git and ssh/scp stuff from the command line because I'm never quite sure what the tool will try to do to "help me out"
If you can develop 100% locally this isn't an issue but we can't (or haven't taken the time to do so). Think of the dev server as just a VM running locally and it might make more sense.
I strongly recommend everyone spend their first ~5 years coding in vim or some other basic text editor (preferably through the terminal), before leaning on an IDE to solve their problems for them.
That said, VSCode is now my go-to IDE, and I haven't opened WebStorm in probably ~6 months. It's lighter weight than the IDEA suite of IDEs, and gives me ~80% of the functionality, so it's been a pretty good tradeoff.
I actually dislike computer science classes which won't let me just use an IDE.
No one can memorize the .net 7 API
Everyone who uses VSCode has surely used an IDE before. It just turns out they aren’t better in every way, and possibly not in the ways that matter.
VSCode plug-ins just have more eyeballs and work done on them for various ecosystems, for example. Especially for less common languages and features.
I would expect the opposite to be true. I could be wrong but it seems like the free editor that's mentioned in lots of tutorials would be the one newer developers gravitate to over a paid tool like IDEA.
Almost every junior I hire has only used Atom, Sublime or VS Code, especially JavaScript developers.
>VSCode plug-ins just have more eyeballs and work done on them for various ecosystems, for example. Especially for less common languages and features.
The reason to switch to an IDE from something more flexible like VSCode or Emacs is the amount of time spent keeping the editor working.
I was about to give up WebStorm the other day, but eventually got around it.
Jetbrains products are very good, but they feel a little "French" just like Macs: beautiful, but be aware that on some models the handbrake is on the same side as the door so you might end up tearing up your pants or bruising your thigh until you learn to be careful :-/
VS Code by comparison is very straightforward, but not always as sophisticated.
Personally I'd use NetBeans for backend and VS Code for frontend but because of Kotlin (which is great) I'm stuck with IntelliJ anyways.
So I end up using IDEA if I'm working with Scala and Java at a job, Emacs if using Clojure, vim for those tasks that are kind of like using sed and awk but not quite, and for everything else, like Terraform, Python, shell, SQL, there's VS Code.
Also the default editor of the IDEA family is just unbearable (but there's the vim plugin for that, I guess), while Monaco is fine.
The only area where vscode is downright embarassing is interfacing with databases. In pycharm I can have a complete view of the database I'm connected to, run queries, get warnings and errors from inline SQL, and so on. Vscode has... strings?
If the remote capabilities get better, though, I'd admittedly have no reason to stay in the vscode camp.
I used it for a year or so around 2015. It was a huge improvement over Eclipse, which is what I'd been using since this was at a Java shop, but even then I knew it was sluggish. I just assumed back then that you couldn't have IDE features without sluggishness. Now I know better
(To be clear I have no idea how VSCode's Java experience, specifically, compares with IDEA these days; I haven't written Java since 2015)
far better and faster than sftp
But I just can't. My fingers are just too used to vscode, and I can do everything I need to. I feel like vscode is better at everything, and faster, except for the IntelliSense stuff. But lately I've tried GitHub Copilot and that just compensates it sooooo much, to the point I think it is even better than IDEA at suggesting stuff.
Also, working mostly with JavaScript and Typescript makes the difference go away (for me at least) as it is damn good at it.
Being free and open source also is a big plus for using it. And I love also how easy it is to configure... just a JSON with autocompletion for any setting you want to tweak. So much easier than having to mess with a ton of tabs and sections and search for settings, etc, etc.
But, if your language is not well supported in vscode, I agree Jetbrain's IDES are great and probably the best option out there. Specially IntelliJ if you're doing Java/Kotlin etc...
It's funny how we have such opposite feelings on config (you enjoying the json config and me preferring UI). I have nothing against vscode and I'm glad it exists, likewise I've very glad IDEA/Intellij exists for my own uses. Thanks for the feedback.
I know a few people like this. More or less, they all got burned by some technical issue that made IDEA unusable for them one day, so they quickly cobbled together a bunch of extensions in VS Code just to get their work done and stayed.
Java IDEs seem to be living in their own world, but for everything else VSCode works well thanks to LSP. For example rust-analyzer works best with VSCode, and this makes VSCode the best Rust IDE.
But one is free, the other is paid...
Also, as of lately, copilot is saving me an insane amount of time especially when it comes to boilerplate and testing.
I really wish the VS Code SQL/Postgres plugins would get there, but it’s a lot of work so I get that it probably will never happen unless Microsoft puts in the effort.
What does this mean? Setting it up so you can deploy through GUI?
With gopls, vscode is MUCH faster than goland, especially on big repos, and I don’t need to watch the dreaded “Indexing…” all the time.
It misses some features, but honestly it’s so much snappier, so that wins for me.
Yep, I've tried Intellij several times over the past 5-6 years, but I've never really had an experience I liked. It's interesting that you mention SFTP and remote server deploys as a pain point for you in VS Code, because I've actually had a huge amount of frustration trying to do development over SSH in Intellij.. As of Intellij 2021 edition, I was completely unable to get ssh working from my work laptop to an EC2 instance; it could not parse my `~/.ssh/config`, and manually putting in the username, hostname, path to the private key, and even port 22 (because it literally required putting the port manually rather than defaulting to 22 unless stated otherwise), it would just say it failed to connect. The 2022 version has a "remote ssh" beta feature which also required manually putting in info that I felt like it should just be able to parse from my ssh config file, but it did connect and work for a week or two. One day it randomly started disconnecting a few seconds into loading a file continuously, which made it impossible to even scroll down into the file before it just zoomed me back up to the top. I gave up on it and just decided to stick with VS code for everything rather than try to get Intellij to work for the small amount of Java code I occasionally have to write.
Setting up ssh development with VS Code, on the other hand, was a breeze. The first plugin that came up when I searched "ssh" was Microsoft's own for ssh development, and running the command to connect to a server after installing it popped up with a list of my servers parsed from my ~/.ssh/config, which I could just select and it would connect (or prompt for a password if the ssh key required one). From there, I could easily open any project on my remote server, and VS Code even was able to detect which plugins I had installed for use with the project needed to be installed server-side rather than locally (e.g. the `rust-analyzer` plugin was installed remotely since it needed to run the daemon on the machine where the code existed). When I close my VS code window, shut down my laptop, and then the next day boot it up and open VS code, it still has the same files opened to the exact same spot (compared to Intellij's "scroll to the top of a file on connection" I mentioned before). I'm sure there are ways to get Intellij to work like I'd want, and I'm by no means a fan of Microsoft in general (I avoid Windows whenever possible and overall have a pretty negative opinion of them), but VS Code just absolutely nails the UX I want in an editor without needing that much custom configuration compared to what I've tried in the past with emacs/vim.
Bare metal thunder
Not sure if Atom was a fruit that grew into an orchard or a seed that grew into a garden. How about both?
For one, I'm finicky about colors and VS code makes it easy to tweak one or two colors of a theme without getting involved in forking and creating a whole new theme. I may just do it, though.
Also, I recall having some issues getting linting to work and the editor highlighting lint errors in not-very-visible ways (like the first character of the line had a red underline).
Again, it's been a while and these could be issues I had with ST3 and/or I missed the way to fix it.
I have tried tuple, but for me it feels like a step back compared to live share. It has poor linux support, and sharing one screen is not as good as connecting to each other's editors. It just feels worse to watch a video feed compared to something that's getting rendered locally.
I do however believe that tuple can work very well if you are in an environment where everyone has mac computers and similar screen setups.
I like VS Code just fine as a text editor, but as an IDE Visual Studio is so much better, even for CMake projects.
Thanks for the tips! I love HN.
P.S. Any other plugins, tips/tricks you recommend for a vim user jumping into NeoVim/LunarVim?
https://twitter.com/Kristy_Viers/status/1287189581926981634
You can turn on the various accessibility features and try them yourselves. While I was already aware of the 'voiceover' features, I was blown away by the braille keyboard and how quickly she could type with it.
Blind people use TTS set at ridiculous speeds that make my 1.5x podcast playback seem glacial. Even back in the late 80s I remember a blind classmate who had a portable electronic typewriter thing that read her entries back to her at rapid speed.
Just pop open the console with F12, enter the following and hit enter:
$('video').playbackRate = 2.5
Change `2.5` to whatever number you wish.
Press up in the console to bring back your last command faster with the cursor at the end so you just delete the number, type a new number and hit enter.
Adding accessibility for screen readers is much more difficult to add later in the project lifecycle. Thinking about those design considerations early makes a big difference in how accessible it will later. If developers don't think about these things early, most likely the product will never be fully accessible, ever. Blind people have seen this played out before with other software products and know where this path leads.
(I'm not blind but have worked with blind developers. I'm not an expert in accessibility but I know enough to know how important it is to listen to accessibility needs)
You start an editor with extensibility from day one, as well as theming from day one, as well as multi-platform from day one, etc.
Why should it be different for Localization or Accessibility?
Imagine if you can code screenless. Headaches in response to light? Not a problem. Avoiding screens at night to wind down for sleep? Solved. Eyesight deteriorating (a totally normal thing that comes with age)? No new tech or ecosystem to need to adapt to, everything is already there.
I believe I've said this before, but as sad as it is, every time I hear "Custom UI" I immediately think "Oh great, this won't work". In fact, I'm much more likely to give something a go if it's developed using web technologies. While not perfect, at least I know that there's a chance that it might work. It shouldn't be like that.
Approaches like yours are why people who are differently abled feel left out and like second class citizens a lot of the time.
I recently had a scare with my eyes. Freaked me out. I started looking at my developer tools completely differently. You are not out of the woods buddy. Anything can happen tomorrow. :)
It’s also for users with poor eyesight, colour blind folks or folks with motor impairment.
It can happen to any of us and then you’d be glad that developers are taking accessibility standards seriously.
The way it works is that its creator made a TUI implementation of the GUI library he used for the graphical version, so you have the same menus etc.
there is quickjs and some others, some of them are rust-based and all of them can run in wasm host
EDIT: to be honest, I clearly see where you are going with this and I agree :)
As a computer scientist, I can't help but cringe at the massive amount of collective inefficiency in the current state of computing.
But don't get me wrong, I'd rather have the inefficient thing which creates value than nothing at all.
Most real world problems have almost infinite demand for more and better software. The final text editor will be the one that reads the minds of the users and product manager and writes the code for you.
Disagree with this. As a dev you have a huge advantage in that you can bootstrap a Saas or similar business cheaply. With the tooling and services available today you can launch quicker than ever before
If you can get a semblance of product market fit you can generate enough income to live off of. It’s not easy but it’s definitely possible.
An editor will generally not stop working like a car without oil. But, IDEs may stop working due to more complex configurations and disparate use cases.
I'm sure VSCode and Linear are fast, nice, and fine. I just hated the lag/latency compared to my terminal text editor.
Even cases like installing the .NET framework or the JVM or some C++ redistributable are parts of that idea that leaked into the otherwise flat packed environment of Windows for example, and all I've ever seen it is cause issues due to version mismatches or them missing. Just completely self destructive behaviour in order to save a few megabytes... and not even that when in practice you end up with 14 installations of the same thing with different versions for every app ffs.
Android is arguably handling this way better, as such stupidity simply isn't even allowed there (to my knowledge), as are web browsers. Imagine having to install a chrome extension to use a site properly, people would think you're insane!
Even excluding scaffolding, VS can eliminate a lot of the boilerplate that takes time if you need to type it out yourself.
Not saying you can't setup VSC to do those kinds of things also, but VS is a tools included solution out of the box. (I say this as someone who hasn't touched VS in a few years now, but used it daily for a few years before that, and who generally enjoys using good/fast text editors.)
I'm not advocating for people using it necessarily, just saying it is a really high quality IDE if you need or want to use an IDE.
Please check it out — being able to edit / run / debug code on a linux server using a mac desktop over ssh, and having the whole experience be as seamless as edit / run / debug locally, is a huge win — it's pretty much _the_ reason that I’m currently using VSCode 90% of the time despite being a huge JetBrains fan (to the point of paying for their full enterprise pack out of my own pocket)
(JetBrains tools do kind-of support remote file editing, but it’s flaky and slow, and remote run / debug are a nightmare — compare to VSCode, where I sometimes mix up local and remote development because they’re identical except for the hostname in the titlebar when running remotely)
Thank you for developing Brackets! I used it daily as a web dev, it had an awesome live preview feature.
Live Preview in particular is one of the areas I had some fun working on. I worked out a way to do diff/patch to make it quickly and incrementally update the browser[1]
[1]: https://github.com/adobe/brackets/wiki/Research%3A-HTML-DOM-...
- Describing levels in video games, which are primarily data with code mixed in
- Describing transformations of different sorts (e.g. the types of languages used in compilers for specifying a programming language parser, and then optimizations)
- Defining hardware (analogues to Spice, Verilog, and VHDL). Hardware can also include mechanical objects, as well more broadly, wetware (e.g. custom bacteria, a la Ginko Bioworks)
- Run on custom hardware (e.g. SIMD and MIMD platforms, similar to GPGPU)
- Are primarily mathematical (e.g. for describing control systems, neural network architectures, etc.)
... and so on.
Not all of this is a DOD/medical mess. A lot of DSLs are REALLY REALLY FUN.
I have projects where I don't accept patches. "It works for me" and I just don't feel like reviewing patches. Is that not "open source" in spite of being MIT licenced?
"I can do with the code what I want" is the entire and only point of Open Source and Free Software, something Stallman and many others have been pretty clear about over the years.
This is not true at all, as evidenced by http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral.... You are mistaking Open Source for public domain.
MS also competes with GitHub also; Azure Repos are a thing, as is Azure DevOps and those are just two examples. MS has plenty of products that compete with each other.
In some spaces this is a good strategy as you will capture more market share with two products than you will with one and you can avoid to an extent monopoly claims.
GitHub Codespaces is what killed Atom and while MS was probably involved in the decision to develop Codespaces, the decision to sunset Atom likely wasn't explicitly made at that time; its simply a side affect as other things have eclipsed Atom.
I'd be interested in even lighter than VSCode IDE ;)
Like, change a file outside of the editor, open it again, and it’ll sit there stuttering for a bit while it realizes the file is updated and it has to re-index.
It’s not the end of the world, but the experience there could be more fluid. Because you do this often (e.g. every time you switch a git branch)
The revenue generating upsell for VSCode is already here and it IS GitHub Codespaces. They are going to add features you can't live without based off code synthesis (sky's really the limit here) and gate those off saying it can't run locally because it's too resource intensive. They'll charge you (or your company) by the second for all usage.
It would be much harder or impossible for them to do this if Atom and an independent GitHub had been further entrenching in this space for the last decade.
Many of the biggest developer tooling projects big corp are building now existentially threaten smaller developers and apps, by design.
Don't give Microsoft a pass here.
I think a simpler explanation is correct: Microsoft saw that open source developer tools are gaining a lot of popularity and also knew that it could help revitalize/modernize their image, so they authorized the funding for the creation of a (mostly) open source code editor, and it gained popularity because it was good.
This. Microsoft share price depends on the size of their recurring revenue from cloud. They can easily write off a few million on VScode for bringing more users to Azure
> VSCode is basically a rewrite of Atom that reuses a big chunk of the original codebase
They both use Electron as their framework, but that's about where the code similarities end.
One of the main complaints many of the C# developers on my team have when they have to touch languages that aren't well supported by Visual Studio is that they don't know how to work VSCode.
And also why C++ workloads depend on .NET being available.
However I honestly have no idea how much time does JS parser spends on what exactly. Are longer variable names and less tabs that big of a deal? It’s all in memory anyway, no… the lexer or tokenizer or whatever (…I never finished my compiler course…) just goes through that
The product’s source maps are publicly available in a way the debugger understands and the original code is freely accessible so there’s no real downside.
I mean, I tried to become an emacs person several times when I was still coding, and it just never took. My last phase of programming work was on OS X, so I had friendlier yet still capable options like TextMate, which made shifting to emacs a pretty hard ask.
Then my job shifted to a point where my preferred method of tracking activites/tasks/notes was just falling apart. I was all-in on the GTD-inspired Omnifocus, but what I really wanted was a system where I could intermingle notes with Todo items, and then ask the system to collate a list of the Todos for me dynamically.
Which, as it turns out, is pretty much a description of how OrgMode works. And, sadly, almost nothing else that I've found, and so I use emacs all the time now.
My emacs expertise, though, is pretty limited to things I need to know to be productive with Org.
We're also talking about a dev box here, are we not?
Of course I've heard of git and we use it, we just don't use local (on the computer we develop on) dev environments, we have a mix of developer-specific VMs and local physical hardware due to the nature of our business.
I have a few workflow-type things like this that I normally do via the CLI, but now I’ve added them as tasks to VS Code for convenience. I can also create the task at the project level and check in the JSON config so that teammates can use those same tasks.
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.
If you add any delays, any potential chance of forgetting a step, etc then it breaks my programming flow which can kill my productivity.
I mean, hell, just set up gulp/grunt/another task runner to watch your files and run scp if you want it continuously running? Why involve your IDE at all at that point?
Software should allow that. Especially software for writing other software.
VS Code is best when it’s just an IDE. I even have to drop into the terminal for some Git stuff
I don't know if you've just chosen to assume the worst or don't care enough to think about it for more than a second but I've been very clear in all my comments that these are developer-specific machines we are deploying to. It's literally no different from running VMs on your local machine. There is full visibility and feedback, we aren't deploying to Prod or even QA, this is development where each developer has 2 or more boxes owned by them and only them. We also are working with specific custom hardware that our code runs on which is one reason we can't easily do this locally.
To jump in and call that "worst practice" is just lazy and condescending. On top of that, it's completely wrong.
I went back to Sublime exactly to get faster startup and smoother writing than what VS Code was offering. So I'm pretty excited to see how Zed turns out!
I was a massive sublime text 2 user with a living document I would share on how to set everything up just right, but now I only ever use it to open the odd 100+mb sql dump if I want to search for something and have it be syntax highlighted.
3 minutes(the imagined extreme scenario) pales in comparison the hours of time most people waste in meetings, or sipping coffee, or chatting with colleagues.
Just how much do you plan to achieve in 3 minutes?
Why does this matter? What is the point of saving RAM instead of using it?
Decisions were taken with an eye to balance sheets and P&L reports; Electron remains the cheapest option of them all, because the supply of moderately-skilled HTML/JS labor is naturally larger than for any other language - all thanks to choices the Netscape Corporation made in 1995, when they needed interactivity in their product and they needed it quick.
For instance, if Apple had actually kept pace with OpenGL standards, and had embraced Vulkan, it would have been fairly straightforward to to build a native GUI framework which works across platforms.
Electron won because all the platform owners basically had to embrace the implementation of web standards on their platforms. So they couldn't prevent those tools from being used to deploy local software as well.
There literally are cross-platform native GUI frameworks. Even Electron itself is a third-party implementation of a GUI framework - it doesn’t use the platform’s web tech implementation and bundles its own.
All these little wedges add up.
Imagine a world where everything had to be deployed to the JVM and all progress depended on Sun/Oracle. Or god help us, IE/VBScript.
It absolutely was not clear, which is why I checked the website and then pointed out the lack of clarity.
At first my thought was "Wow, nice, another UI toolkit that uses native widgets, that's good!" But, alas, it was not to be.
Eg: Speed? Different UI layout? Fundamentally different design/UX philosophy?
Despite VSCode being an Electron app, I've never had any performance issues with it - really, it's a great example of how Electron can be done right.
On collaboration, I'm not sure what they might add that isn't already covered by GitHub/GitLab/AzDo etc. Again being honest, "collaboration" sounds like a weak Open Source pitch to VCs. I'd be interested in some details though, incase there is something truly novel here.
Secondly when you re-create from scratch you can keep the best features and drop the ones we've learned are not so useful.
Godspeed!
Maybe it's just me but I'd not judge things like that on the first non-public beta.
I never asked for or requested input on how we deploy code/manage our servers. I was asking questions about an IDE vs vscode and gave 1 example of trying to do the same thing in both of them. Had I known so many people would come out of the woodwork to tell me I'm doing it wrong without any idea of how our stack works I wouldn't have mentioned it.
I have no aversion to running shell commands and you are being disingenuous by saying that. I have a problem with manually doing a step that I can automate. I write and run shell scripts all the time for one-off process but seeing the code I've actively writing in an environment that can run it is not one of those cases. In fact, anyone doing that manually is just being silly or obstinate. If you aren't automating something that you do 100's+ times a day then I question your skills.
VSCode/Codium is amazing but it feels the same - sluggish but a feature/extensions-packed behemoth.
I hope Zed is able to establish a nice extension ecosystem as that is priceless!
Thank you!
EDIT Nvm, I see this is our best option for now: https://zed.dev/waitlist
I always cringed at languages like Perl and also Groovy where the pride of the language designers seemed to be that there are so many ways to do the same thing.
LOL, as if Firefox provided a stable API to extensions
If extensions lock down the files they will touch and the urls that can be visited I think sharing them becomes more palatable.
I think WAPM and Wasmer could help a lot on the extensibility using Wasm plugins. I'd love to chat further, please feel free to reach me at syrus[at]wasmer[dot]io!
I think cross-platform plugins would be hugely beneficial for the whole ecosystem, and also generally for new editors since they can potentially benefit from a larger plugin developer community.
Is that something you can see your team collaborating on?
Man that felt a bit like extortion, but I mean well.
I'm not an expert on this at all, I'm just quoting, but Spark is being used rhetorically as if it's an outlandish to consider it to be a descendent
I see this as a compelling feature for something targeting the use cases of, say Google Docs, where multiple people are contributing to an outline document or a business plan at the same time - but for code, I don't quite see the appeal.
That's a very specific example of collaboration. Remote work is exploding. What about, say, integrated, collaborative debugging or code review? Integrations with things like Slack?
Examples:
- VSCode Live Share https://code.visualstudio.com/learn/collaboration/live-share
- JetBrains IDEs Code With Me https://www.jetbrains.com/code-with-me
- Standalone https://www.coscreen.co https://duckly.com
The biggest performance improvement would probably be RAM usage. You don't notice laptop specs get more RAM. The usual options are still 8GB or 16GB. Until 32GB / 64GB is the new default, having a non-electron app will always be an improvement.
Personally I don't think it matters that much in the end, whether it is CPU usage or RAM, but if the editor was just as capable but faster, I'd switch. Code will never be rewritten from scratch and it will always be tied to Electron, starting a new text editor built with faster technologies could give a long-term edge the existing competitors would not be able to use.
It's a pretty clear cut argument that using an IDE as a crutch will inevitably bite you in the ass, and if you want the best possible understanding of the language you're using and all of its related tools you ought not use an IDE as it obfuscates those very things you're trying to learn about.
For now, people pairing/collaboratively writing Rust is our focus, and we are pulling people in that fit that criteria!
To be more precise: 8.0 finally has proper utf-8 out of the box, support for complex replication topologies (including multi-master), window functions, CTEs, etc.
https://www2.computerworld.com.au/article/457551/dead_databa...
>Dead database walking: MySQL's creator on why the future belongs to MariaDB
>MySQL's creator, Michael "Monty" Widenius, is scathing on database's future with Oracle
>It's fair to say that MySQL creator Michael "Monty" Widenius is not a fan of Oracle. When the company announced in April 2009 that it was purchasing Sun, Widenius saw a bleak future ahead for the (still) wildly popular open source database, which Sun had snapped up in 2008.
>The day the Sun purchase was announced, Widenius responded in the tried and true open source fashion — he forked MySQL, launching MariaDB, and took a swathe of MySQL developers with him.
>"Many of the original MySQL core developers, including me, didn't believe that Oracle would be a good owner of MySQL and we wanted to ensure that the MySQL code base would be free forever," Widenius explains.
>Some of the new code by Oracle is surprisingly good, but unfortunately the quality varies and a notable part needs to be rewritten before we can include it in MariaDB
>Widenius and a number of other MySQL developers started a company, Monty Program Ab "to provide a home both for MariaDB — the new MySQL — and for all MySQL core developers".
>"Monty Program Ab is owned by the employees and uses the 'hacking business model' as a way to drive the company," Widenius says.
>Although MySQL is still widely used — Db-engines.com ranks it as the third most popular RDBMS after Oracle and Microsoft SQL Server, compared to MariaDB coming in at #35 — Widenius still believes the database has a bleak future under Oracle's stewardship.
>Oracle's treatment of MySQL and its community since its purchase of Sun has proved Widenius' original fears correct, the developer says. Not mincing words, Widenius says that Oracle has made it clear "that they have no love for open source, working with the community, or MySQL in general".
>Widenius cites as examples of Oracle's disregard for open source principles the September 2011 announcement of commercial extensions to MySQL, the bugs database not being public any more, and a lack of test cases for new code in MySQL 5.5 and 5.6.
>Widenius is also scathing of the quality of Oracle's MySQL development efforts. "Some of the new code by Oracle is surprisingly good, but unfortunately the quality varies and a notable part needs to be rewritten before we can include it in MariaDB," he says.
>He also says that security issues are not addressed quickly enough.
>"Instead of fixing bugs, Oracle is removing features," Widenius says.
>"The MySQL documentation was never made open source, even [though] it was promised in the MySQL conference in April 2009," he adds.
>"Flagship features promised for MySQL 6.0 have never been released, even if they were fully developed and ready to be released," he says, referring to online backup for all storage engines and foreign keys for all storage engines.
>"Most of the original MySQL developers have left Oracle. Without people that can understand and explain the code it's almost impossible for Oracle to develop MySQL further even if they wanted to."
>As further evidence of disdain for MySQL users, Widenius cites what he describes as "sharp" increases in licence and support fees, a lack of an open roadmap and no way for the community to participate in the database's development.
>"Why is the price for a MySQL OEM license higher than for Oracle Express?" Widenius asks.
[...]
I also think the sibling comment is right; TextMate never had the huge collection of plugins later editors did, but you can very much see the seeds of Sublime Text's package system in it, and Sublime is a very obvious influence on Atom/Code. (Although they were smart to have package management fully integrated; Sublime's package management system is a bit clunky by comparison.)
You can also customize Atom easier than VsCode. Why even build on web technologies if you don't let your users change things. For instance you have to have an extension to custom load CSS and it's kind of a hassle. Heck even Sublime has an easier interface to change the text editor in real time. You don't really need to do much as it already looks good though.
fwiw I use Linux and suspect that's a big part of why Macs never appealed to me.
Let me introduce you to Emacs, vim, Sublime, TextMate, ...
I think companies make brand new products whenever that happens. No legacy baggage. If it gets popular enough then the old software gets killed off.
Unlike VSCode, Emacs and Vim have a learning curve. And turning them into full blown IDEs makes their usage even more complex.
> Sublime
Sadly, Sublime is sort of dead.
> TextMate
TextMate: Text editor for macOS
Sublime has ongoing development on https://www.sublimetext.com/dev and the last major release (4) was just about a year ago.
That's not the point, we were talking about plugins.
In Emacs/Vim I can't even escape the program if I don't know a keyboard shortcut.
In Vscode even if I forgot Cmd+W/Q I can simply click the close button. Not to mention that all the shortcuts are just globally used shortcuts in all the other software.
While I respect praising by the community of Vim/Emacs, I really don't think it's beginner-friendly.
So anyone starting a software career virtually picks Vscode, gets used to it, and almost has no reason to switch to something else for now unless they need something extremely specific.
have you seen the extent of available emacs packages? maybe it is a learning curve for a person who just learned how to power on a computer but i find emacs soo much more approachable
Atom was made to be infinitely customizable by using web technology. You can dynamically change everything you want with custom HTML, CSS, and JavaScript. Nothing is off limits. Want to shrink the size of the tabs? Just throw in some CSS, everything is changeable.
Code on the other hand runs plug-ins in a separate isolated thread where they are left to communicate with the editor through an extension API. Every customization "hook" that a plugin has access to needs to be explicitly added in that extension API. The things that the devs didn't think (or want) to add are simply impossible. Want to shrink the size of the tabs? Tough luck (except for unsupported hacks).
Code is awesome, but I think Atom should get more credit for what it tried to do. It is arguably the most customizable text editor ever.
What I, and almost everyone else wants is extensions which provide real utility like language packs, linters, git tools, etc. All of this works well on VS code.
I actually use VS Code as well, but more like an IDE with tons of extensions, and Sublime is my 'basic' text editor.
[0] https://www.construct.net/en/blogs/ashleys-blog-2/simple-sof...
The writing was on the wall for a long while now, and was one of the reasons why the JuliaCommunity stopped advocating Juno/Atom as a platform and instead switched to VSCode
Atom is inferior in every aspect to Visual Studio Code. Atom was on life support for too long.
> We should be counting down the days till they sunset VS Code to focus on VS Code "Pro".
I don't think it would serve their interests, so I'm not worried about it, but who knows? This cynicism is directed towards Microsoft because they've earned it.
They harvest an astonishing amount of data from it.
I'd actually worry if the engineers I work with couldn't pick up a new IDE/text editor, etc. pretty easily and quickly, if and when something like this happens. And I'd say the risk of it happening in the next three to five years is pretty minimal at this point.
Once you start making full use of your editor, switching to a new one and reaching the same level of proficiency takes a long time. I can edit code even in notepad, but I can't ever be as fluid in it as my main editor. I've changed my editor multiple times and it's a huge pain every time.
I doubt that switching an editor requires a disaster-recovery plan.
I guess they have lots of "solutions" to "design and implement".
the normalization of this behavior within the industry makes using emacs or vim even more satisfying.
it's nice to having an unchanging cement foundation to stand upon once-in-awhile.
They maintain a trademark on the name Visual Studio Code and some other bits. And it is maintained by a Microsoft team.
But the code itself is MIT licensed. You can build it yourself. I have. There are one or two forks of it out there.
https://news.ycombinator.com/item?id=9872976
https://thenextweb.com/news/microsofts-cross-platform-visual...
I set it up to deploy on save of the file or when the editor loses focus (when it auto-saves). So while you are correct I have to do “something” to make it deploy that “something” is either a hot key or me clicking out of my editor into the browser to refresh the page (talking about PHP here, all my frontend Vue work I do locally with a watch script to rebuild on changes).
The real problems with MySQL are:
- the bugs database is not public (as he's said)
- all development is going behind closed doors; MariaDB is more open to the public
That's it. Quality-wise it's better than MariaDB IMHO. And they pay more attention to low-level stuff that doesn't add too many new features but greatly improves things like reliability (such as rewriting the underlying InnoDB storage format). Although that one did introduce a significant feature (transactional and fully atomic DDL, which MariaDB implemented only partly and recently).
MariaDB has its share of problems. For example, they have exactly the opposite issue of what he's describing: in their first releases they've imported mountains of code from other MySQL forks without much testing (especially from Percona), things like Cassandra and TokuDB that went practically unmaintained for years and are now in the process of being removed. All to toggle as many feature checkboxes as possible ("look at how much shiny new stuff we ship!")
I personally don't use new MariaDB releases until at least their 5th or 6th patchset.
I also don't really understand this question:
> Then explain MariaDB?
Monty didn't want to work under Oracle. He left and started a competitor. What else to explain?
For a time it did seem MariaDB would replace MySQL. But your link is almost 10 years old and since that time MySQL has seen it’s biggest release (iirc ever) in terms of features and bug fixes. Meanwhile MariaDB and it have diverged and aren’t really 1 to 1 replacements as they were in 2014.
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.
This is a sign that emacs has too much extensibility (or, to be more accurate: too little isolation). It's been observed before that emacs really is the antithesis of the alleged Unix philosophy of "doing one thing and doing it well". It is an inner platform.
Causally linking glaring deficiencies (long lines, concurrency) to overriding virtues (extensibility) is a weak but common snow job aimed at emacs's critics who know nothing of emacs's internals. For this emacs critic who knows quite a bit about emacs's internals, I call you out.
There's only one reason for emacs's many wtf frailties. No one's paying to fix them.
There are pros and cons of course -- these weird shims can be troubling from a performance point of view, but on the other hand a plugin environment can grow, reach popularity, and then fall apart, and not take Vim down with them.
I ended up purchasing the upgrade to Sublime 4, definitely worth the price.
While Vscode is my IDE now, I definitely love the instant-opening of Sublime.
Ironically, it's even launching faster than TextEdit.
IntelliJ IDEs feel similar — sometimes I’ll open them up and after upgrading several plugins and dismissing a bunch of popups and “what’s new” dialogs, I don’t even remember what I was trying to do in the first place.
Installing an extension on vim (never done emacs) is something that does not just happen easily. There is no intuitive search for extensions built in, you likely have to install software that manages your plugins.
VSCode on the other hand rarely requires more than a single click through a built in interface.
The plugin ecosystem exists for command line editors, but it definitely has a learning curve
I personally do not use any of these package managers and instead use my systems package manager on Gentoo to manage everything. Gentoo has most of the popular projects in the ::gentoo repo under app-emacs, and packaging your own is only a few lines of bash.
On the other hand, it looks like Rust is only moderately more popular than Dart: https://www.tiobe.com/tiobe-index/
But I can see why they'd steer away from a language controlled by one company, especially one notorious for killing off projects.
I'm still rocking SLT 3, and it's my go-to for large file handling or just as a simple scratchpad, but development (of SLT) feels like it moves at a snails pace.
Everything works just the same, and I don't get the purchase pop-ups.
This is how it's always been I think; their model.
I don't think ST needs to move fast. It's a good quality editor. It doesn't need a bunch of new features every couple of months. Just getting a major update once a year is fine imo.
there is a close button in emacs. however unlike vscode, emacs can also run in the terminal
> So anyone starting a software career virtually picks Vscode, gets used to it, and almost has no reason to switch to something else for now unless they need something extremely specific
can be said about windows too. i started off on windows and jetbrains. today im on minimal linux, stumpwm as window manager, and emacs for everything except browsing. i find it very liberating having cut down my dependencies without having cut down functionality
Or, you know, you could just click on the File menu and click on Quit.
When I run Emacs with a blank config, the default display has this:
Get help C-h (Hold down CTRL and press h)
Emacs manual C-h r Browse manuals C-h i
Emacs tutorial C-h t Undo changes C-x u
Buy manuals C-h RET Exit Emacs C-x C-c
Activate menubar M-`The rare time I use vscode instead of neovim I always end up with a lot of random characters into the code and have to close it without saving for fear of having broken something. You call that user friendly?
User friendly is what most users find it easy to use.
Your argument is more on the lines that you are a legacy user who does't want to move.
The whole idea of using vim/emacs was when intellisense/autocomplete was in its infancy. And programming general required using typing skills as a autocomplete mechanism. The only real use of all that edit-commands-as-a-mini-language philosophy of vim is to write keyboard macros. Which again was needed because people lacked decent autocomplete features. Besides typing fast itself isn't connected to coding productivity these days.
Macros, substitutions and search commands are useful for many things and an editor like vim/neovim/emacs is not only used for code.
Nobody ever talked about typing fast.
With emacs this is a feature, not a bug ;)
I'm not making that comparison.
GP's post was in response to the complaint that Emacs/Vim are hard to exit. They said that "Or, you know, you could just click on the File menu and click on Quit."
And I'm just saying you can't do that in the terminal.
Not sure what you're going on about.
and in Vim, there is no such display.