Really gave atom a hard try. Back to notepad after a few months. The add-ons are the only advantage, but are grossly overshadowed by the resource consumption this behemoth requires.
Yeah, someone complains about the resource usage in every Atom post.
I feel likes it's a rehash of emacs vs vi debate from 30 years ago. Emacs needed many megabytes more than vi so people wouldn't use it.
As time goes on the resource usage becomes less of a problem. My 4 year old laptop has 16GB of RAM and I don't really worry about it. I'll get 32GB or 64GB in my next computer. I never liked quibbling over memory. My time is much more important to me and I want the best tools. I also want them to swim in RAM.
Yes, Emacs stands for "eight megabytes and constantly swapping". How silly this sounds today.
I wonder why do those people even care.
The only time I look at my resource usage is when apps start to behave funny. Or when it's an app that I am developing. Other than that, why should one care?
One argument could be made that they are using memory wastefully. Not sure that's the case. The baseline memory consumption is higher, so what? It's a tradeoff. It's easier to build a better editor using browser-based tools, as much as I like Elisp. Over time Atom and VSCode will close the gap.
Now, if there is a memory leak, or memory increases non-linearly with the workload, than it could be a problem. VI and Emacs are pretty great with large files (Emacs not so great with long lines), browser-based editors usually do not work as well. But there is no reason they shouldn't, it just takes engineering effort.
"Yes, Emacs stands for "eight megabytes and constantly swapping". How silly this sounds today. I wonder why do those people even care."
Well, because if an application you're using is constantly swapping, it'll slow that application down to a crawl. This was especially true back in the day when disk was slow (and expensive.. as was RAM).
People today are used to being awash in resources. RAM is fast, plentiful, and cheap. Disks are relatively fast and cheap.
You have to imagine what it was like to live in a resource-constrained environment where you actually had to care about how much memory and disk you used, and how you were using it. These decisions had severe, immediately apparent practical consequences.
What I meant to say was that "eight megabytes" sounds silly today. Who cares if an app uses 8MB today? The extrapolation is that it will be the same for Atom or other editors (I'd argue that it already is).
I created my first programs with a computer which had exactly 28815 bytes free when it booted up (out of a possible 64k). If you plugged in a floppy drive, the free memory dropped further.
Personally I don't mind RAM usage that much. I'm more concerned about excessive CPU usage resulting in unnecessary battery drain on my laptop or annoying fan-spinning.
Atom for me consistently sits at 0-0.1% (mostly 0) CPU usage when idling. You may want to investigate some of the extensions you're using if the numbers are different for you.
It was the lag (and at the time, struggling to open "large" files) that stopped me giving it more than a cursory check a year or so ago. No idea if it's worth looking into again? Would be hard to beat sublimes snappiness doing almost any task.
For certain definitions of 'high-end', maybe. You've been able to configure workstation-class laptops with 64 gb for a few years now.
And most mid- high-end laptops will happily accept 32GB, again going back a few years.
(Broadwell removed the density limitation that made 16GB DIMMs a no-go; anything that takes DDR4 should support 16GB SODIMMs, excepting the very low end Atom, Celeron etc.)
You really aren't. Atom runs fine on a Macbook Air. There are definitely performance issues, but we're addressing them; it's just that our team is small and our initial goal at launch was to produce the most hackable text editor possible.
I had to drop Atom when it began launching white flashes when scrolling on a 2011 MBA. I saw that this was a recurring problem. Is that an issue that is being addressed?
"I feel likes it's a rehash of emacs vs vi debate from 30 years ago. Emacs needed many megabytes more than vi so people wouldn't use it."
The thing is, this was in fact a valid critique of Emacs back in the day, and it cost Emacs users. I know I stopped using it back then partially because of its resource use (and because it was a lot slower than vi and because of its finger-twisting keyboard shortcuts).
If Emacs was as light on resources as vi was back then, it would have more users today.
I've been using Atom since 2015 and it's only getting better on each new version.
I tried going back to Sublime which has objectively much better performance but that doesn't make the whole experience better. It's like sitting in a Formula 1 car with no cushion and no AC.
I really want to create a public-facing roadmap that's specific to this issue. Unfortunately, our resources are limited so we often don't focus enough on blogging/publicizing our planning... but in the meantime, here's something of a brain dump:
In terms of our actual data structures and algorithms, we're already starting to be in really good shape. We've dropped a number of components of our core TextBuffer to C++, ensured that most of our algorithms scale logarithmically with file size, cursor count, etc, and made use of native threading for important operations.
1. The one remaining structure that we need to drop to C++ is what we call the 'display index' - the thing that stores the locations of things like folds and soft wraps. Once we do that, opening large files (which is already reasonably fast) will be like butter.
2. Our find-and-replace is already pretty good - you can type without almost any lag even when we're storing the locations of millions of search results. But now that we have the ability to easily use background threads, there are some easy optimizations we could do there. The search results could really update instantaneously, we no longer need to wait until you pause when typing in the search box.
3. We have in the works a major change to our syntax highlighting system using my incremental parsing library Tree-sitter. Once this lands, it should eliminate any perceived latency in syntax highlighting (as well as enable a host of great syntax-related improvements).
4. Atom still uses synchronous IO (which blocks the UI thread) in some places. This is because it was created before GitHub created Electron, so node APIs were not available from the outset. Many of these have been eliminated, but there are several Git-related code paths that we still have not updated. This probably kills the experience of editing on remote drives like SSHFS for some users. We need to revisit these code paths.
What are the current plans about Coffeescript? I just looked at the code on Github, it says 85% Javascript, 12% Coffeescript. Is the plan to port the 12% to JS6? (and hopefully not Typescript)
Great work with Atom editor. I successfully conviced my friends to move from VSC to Atom on macOS.
Thanks! Yeah all of the CoffeeScript in atom/atom should be gone in a few months probably. We use plain JS now.
It'll probably take a while before there's no more CoffeeScript in the entire Atom org. We're gradually converting the code to JS as we come upon it for other reasons.
It's like having Leonard Cohen transpiled to Justin Bieber. Now look at it from the Justin Bieber fans point of view, why would they listen to Leonard Cohen in order to hear Justin Bieber ? Even though research says Leonard Cohen makes better music! From Leonard Cohen fan's point of view it doesn't matter as they only hear Leonard Cohen, not Justin.
On the Atom.io website https://atom.io/ it reads "A hackable text editor for the 21st Century". Well I can code in JavaScript 5 and 6. I love love it when a project sticks to web standard, and not have to worry about slangs I don't care about.
> Typescript is great at catching bugs
The same with JavaScript. Google Closure compiler and anyway most IDEs "understand" JavaScript too and catch bugs. JavaScript is dynamically typed not typeless.
I was surprised to see someone who cared what style of javascript a program is written in, especially if they aren't an active contributor. Maybe you are?
As did I, but I just couldn't get over how slow it was.
Startup time on windows was rough, meaning I had to remove it as a default editor almost immediately for most filetypes. Worse off, opening large files would grind Atom to a halt and usually lock the editor up.
Beyond the performance, I thought it was a great text editor. The problem is I just have no use for a slow-to-start editor when I can just DL vscode and get the same features with considerably better performance.
A little bit of both. I make sure my LinkedIn profile has the necessary keywords.
I respond to every recruiter that works for a local, reputable agency where I don't have a contact and input them in my contact list.
Three scenarios:
I'm not looking at all - my response is "I'm not looking for a job right now, but let's keep in touch, send me opportunities that match my skill set and pay at least $x. For the right opportunity, I might be able to pulled away or know someone who is looking." This keeps me knowledgeable about market salaries and popular technologies that I need to focus on.
I'm "passively looking". Almost the same as above but usually by now, I'm looking to change jobs within the next three to six months, I've been invited to lunch by one or two companies, and actively preparing. My response then is, "I'm passively looking for a job. Here is my resume, I'm looking to leave in the next three to six months. My salary requirements are $X"
I'm actively looking. By now, I'm proactively sending my resume to recruiters, I've spoken to, telling them what I'm looking for, etc.
Notice, I'm not waiting for my status to change to "actively looking" to start preparing. By that time I've been priming the pump for six months to a year.
Find and message them on LinkedIn. Pay for the messaging plan; it is way more effective than stuffing your message in the connection request. Also, be prepared to talk salary and have a resume on hand.
LinkedIn is their tool of choice these days. StackOverflow Careers is another popular option for them. Facebook Jobs might pick up steam, so I'd experiment with that too.
Simple, yet seemingly effective. As long as the hash the browser is checking matches the hash the server produced, the only options to beat this that I see are hash collision and bypassing the mechanism.
