Hacker News new | comments | show | ask | jobs | submit login
Atom 1.20 (atom.io)
138 points by gisenberg 7 months ago | hide | past | web | favorite | 66 comments

I was a fan of Atom until I tried VSCode. Call me a shill, if you will, but it is an all around better experience and I haven't looked back.

I tried it, liked that it was faster than Atom at the time (though the gap has shrunk, as I understand it), but couldn't deal with it having an "only one open project" model. That was a deal-breaker for me. All of my stuff is broken out into many small projects, and I'm trying to go further in that direction rather than toward more monolithic codebases.

That one factor was a deal-breaker and I went back to Atom (though I still use vim just as often as Atom, since I don't have every project open in Atom at any given time, and sometimes I just need to edit one file really quick and check it in).

VSCode is very good. But, as long as it's got a one-project model, I can't do anything with it.

That's changed in the latest insider build - you can now have multiple projects open

Cool. I'll give it another go when I have some time to play. But honestly, most of the stuff I didn't like about Atom is resolved lately. It's fast enough, small enough (for my 16GB laptop), and reliable. And, has a gazillion features, most of which I never use.

Does it still choke up on any file that is either larger than 20,000 lines or has a single line that's longer than 20,000 or so characters?

I used to use Atom a lot but being that I regularly am pulling and investigating large files that was a deal breaker.

I've never used it for anything quite that large. I have three windows open on my first virtual desktop: Editor, terminal, and browser. When I want to poke around in log files or other really long files, I'm using grep, tail, awk, and Perl (and vim), in the terminal.

The biggest file I regularly work with in the editor is 10,631 lines long (I just checked, and it's longer than I thought). Atom works fine with it, including syntax highlighting, and cutting/pasting/typing/etc.

Actually...out of curiosity, I just opened up a ~110,000 line file (a log I had laying around). It seems to work fine. It took a little longer to open than it would in vim (which is effectively instant), but not as long as I would have expected. It was well under a second, and within my comfort zone for opening files. Switching tabs seems maybe a little more sluggish with it loaded, but not uncomfortably so.

I think I have to accept Atom into the category of editors that can work with pretty large files. I can't imagine having a source file any longer than that 10,000 line file I work with regularly (and I would never make a file that large, but historic codebases sometimes have weird things in them), but it seems like it'll work even if someone did.

I think it is less the line count that I have problems with lately than line length. It's quite a specific use case, but I work with geographic data and occasionally deal with absolutely enormous wkb's that can be in the hundreds of thousands of characters. Couple that with writing in Hadoop typically going to one line per JSON representation and now I am regularly opening files to review that consist of a single line of text that might have upwards of 80,000 characters on average. Even beautified it still is problematic. VS code seems to be able to do it reasonably so the software stack cannot be blamed.

What do you use now?

VS Code mostly and if it's a big one even VS code cannot handle I will use Vim. See the sibling comment for my somewhat pointed use case.

Tried VSCode. Thought Atom was still a cleaner experience.

Package system doesn't get much better than Atom. I think my code looks better on Atom (still not better than Sublime). I also ran into setup problems with VSCode git support on Linux.

This has been my experience as well. I really wanted to like Atom, but then I tried VSC. It's an incredibly well done editor, and it doesn't feel nearly as laggy as the average Electron app.

Why shill. It's just great tool. I love lots of what MS does. I still consider C# best language I ever learned.

I loved c# 10 years ago but have a few issues with it these days:

* functions not really being first-class citizens * great collection methods with LINQ, but why did they give them such weird names? (map = select, filter = where, reduce = aggregate?) * took them a while to come up with a great async model (async/await), so legacy c# asynchronous code can be hard to figure out at first

Just my opinion but it seems like more recent languages like Swift have done a better job implementing ideas from functional programming. It's still light years ahead of Java to me though.

>but why did they give them such weird names? (map = select, filter = where, reduce = aggregate?)


C# is a great language no doubt (been using it professionally since the early 2000's) but it always felt sluggish when creating complex forms and handling events in those forms where Delphi, C++/Qt and even Lazarus feel much faster.

> I still consider C# best language I ever learned.

Thus you clearly have not learned F#, nor any other (superior) Standard ML descendant (e.g. OCaml or Rust).

(Why is F# inferior, you ask? CLR interoperation requires using types and datastructures defined in C# code, which overall mean that you will use an unidiomatic style. Hence, F# is basically "a usually-less-annoying C#", unlike other SML-likes. Except Scala, whose best description is "F# on the JVM".)

> I love lots of what MS does.

Does this include the Embrace+Extend+Extinguish strategy?

And how does anyone, other than via sheer forgetfulness, think that Microsoft doesn't have similar nefariousness on today's drawing board? The revelation of the 3E strategy showed they are inherently and absolutely untrustworthy.

They said "lots of," not "all" or even "most."

It's a big company, and they are not 100% evil because no company is 100% anything.

And honestly, I believe any company with a stranglehold on any market will behave badly. Rather than being salty at Microsoft in particular, let's make sure no company ever has such a stranglehold on computing again.

I didn't claim that Microsoft was unique in anything but the 3E strategy itself.

Actually, what with Google duplicating more and more of Android's core open-source functionality into their proprietary apps and then leaving the open-source code to rot ... Microsoft isn't unique in that way, either.

But more importantly...

> let's make sure no company ever has such a stranglehold on computing again.

That's a long road ahead, since Google has a monopoly on the average user's very mind. And don't forget that Microsoft hasn't lost their stranglehold either, except among programmers and similar personnel. They may be behind on mobile, but they've held onto largely the same markets+marketshares that they had in the late 90's (plus more, though not at monopoly scale, thanks to Azure), and desktops+laptops won't be dying anytime soon.

try F#

+1, my coworkers always teased me for sticking with Atom and tried to get me to Sublime Text but VSCode was the first thing post-atom that stuck.

Atom just could not handle big files well, and years of waiting sadly didn't yield big enough results.

Yes, big files has always been the major issue for me. I always kept sublime text around for some larger files and ultimately decided I would only stick with a single editor.

I like VSCode, but the Clojure integration in Atom is top notch. When that catches up I might take another look.

One of my co-workers has put together a Clojure plugin for VSCode - https://marketplace.visualstudio.com/items?itemName=jamesnor...

Another co-worker is the one who put together proto-repl for Atom so you'll see a lot of similar functionality in the two. I still use Atom and proto-repl just because I've been too lazy to get familiar with VSCode. But when James has demoed the debugger functionality in his VSCode plugin it looks great.

Your co-workers sound pretty cool. That is a different Clojure plugin than what I tried before in VSCode. I'll definitely check it out.

Out of curiosity, what's your setup like? Also using Atom for clojure.

I’m using proto-repl, bracket matcher, lisp-paredit (mostly disabled, used for better auto indents), and parinfer (simply wonderful).

I based a lot of my setup on this gist [1]. My dotfiles are here [2]. I have it set up so that ‘zc’ connects to an nREPL, ‘zb’ evaluates the top block under the cursor, and ‘zz’ evaluates the entire file.

1: https://gist.github.com/jasongilman/d1f70507bed021b48625 2: https://gitlab.com/jakebasile/dotfiles

+1, VSCode feels way more polished.

Same here the moment I tried VS code I never went back even abandoned my PyCharm IDE.

VSCode is probably technically superior, but I just can't get past the icon. It looks pretty ugly IMO and it's significantly bigger than all the others in my dock so it stands out like a sore thumb.

You can just replace the icon? There are many "fan" made icons out there.

You're a shill.

How about reducing the memory footprint?

You were downvoted to oblivion, but honestly this is a huge issue that somehow feels like people are just OK with.

Honestly, work with Atom open for a day or two on the same project, that's not uncommon right? Prepare yourself for some serious type lag.

Full disclosure, I run a Linux desktop with 32GB of RAM. I'm not accustomed to type lag. Judging by your downvotes it's an acquired taste.

I downvoted paule89's comment because it felt like a cheap shot at an established product with well-known pros and cons.

Yes, Electron apps consume a bunch of RAM. Yes, Rust needs you to deal with data lifetimes. Yes, Go still doesn't have generics. Yes, Haskell has a steep learning curve if you learned imperative languages first.

No, restating those facts on HN at every opportunity is not constructive.

Rust is built on lifetimes, Go is designed to not have Generics, Haskell will always be weird. A UI toolkit has no inherent reason to use a large amount of resources, so there is some value in noting that they either don't care or haven't managed to fix it yet.

Rust is built on lifetimes but the compiler could definitely infer them better. Not only from my experience, but all attempts to introduce coworkers / anyone else to Rust usually meets a "this 'a thing is ugly and awful and I hate it".

Really it was more a design decision on the language part than something it was "built" on. In 99% of cases the compiler can identify where exactly you need to annotate lifetimes to sate itself. They are only there for explicitness. Tagged lifetimes will help a lot with this, because it is much more intuitive for anyone using any other language to say "ok I need to say result R lives as long as argument A that makes sense" vs "stick an 'a on everything" and have functions that have nothing to do with generics looking like generics to the average joe.

I know I personally have written function signatures to take (or return) owned data in Rust just to avoid having to lifetime annotate the whole thing. It is just a chore that most of the time is just boilerplate to "make it obvious" to readers of code, despite almost every situation I see lifetime annotations I can straightforwardly understand that the & in the return is lifetime bound to the & in the arguments or the struct field it comes from.

Perhaps not but not all of us follow such things as closely as you might so the assumption that it's common knowledge is not necessarily accurate.

You're absolutely right that not everyone seeing this comment tree knows the details of Electron's memory usage. But I don't think that GGP's original comment was aimed to educate those people about the issue. To me it just sounded like a quip aimed at getting some cheap points from the choir.

Yeah I could see how if you are used to seeing such posts it would come as more of a slight but from my perspective it's good to know people's gripes about a product having not followed much about this before - especially if some people might be trying it out as a result of the article. The ambiguity of purpose is the bane of internet comments.

It's a hugely beneficial visual when they are deciding what to prioritize on the roadmap going forward.

It's input directly from their user base about what they want in their work environment.

Do you think this thread is the best place for that input? Or that the input is valuable enough to post at any opportunity?

For the record, I disagree with both of those statements.

Yes, I do think this is the best place for that input. People post things on HN, and there is a comment section where we talk about the thing. What else would be in a thread about a thing?


I wish that I could upvote this twice.

>Honestly, work with Atom open for a day or two on the same project, that's not uncommon right? Prepare yourself for some serious type lag.

I dunno, I have the same Atom instance open on Linux for weeks with 20+ files open, I haven't experienced any noticeable lag. Maybe I'm just not as sensitive to the sort of lag you're experiencing.

> Honestly, work with Atom open for a day or two on the same project, that's not uncommon right? Prepare yourself for some serious type lag.

iMac with 32GB RAM here, and I routinely work with 10+ tabs open with files of 1000-2000 lines of code, and never really noticed and lag or crashing in Atom?

I leave Atom open and running 24/7 for days at a time. In fact, this morning was the first time I remember restarting Atom in over a fortnight because I installed 1.2.

I use Atom in a couple of places

1) Old Linux laptop with 4GB of RAM which I leave open for days on end without issues

2) Linux VM on virtualbox on my 8GB Ram desktop. I went for months leaving Atom open in the VM (saving it day to day) without issues

I'm not even using an up to date version of Atom? I know Atom is not great with very large files (it warns you before you open them) but for me this is only things like logs which I read from the command line with tail and grep. I have no need to open large files in my coding editor.

To add another anecdote, I tend to have an Atom window open with a couple dozen projects and a dozen or so open tabs for days or weeks at a time. I haven't noticed this problem. I'm on a Fedora Linux laptop with 16GB of RAM.

Atom is big, but I haven't noticed any lag or seemingly memory-leaky behavior. Maybe one of the plugins you use is causing it?

If you have 32gb of RAM and you're getting type lag after 2 days, it's probably not a RAM issue, right?

it can still be an issue with memory even if it isn't as blatant as "out of memory".

The easy example being a datastructure growing over time and getting slower to manipulate and query. This is a problem where being cavalier with the amount of memory you allocate and use will hurt you, even if you've got lots of memory to spare.

We'd need to know how much memory Atom itself is using after that time. Perhaps GP has found a memory leak, perhaps he's on an Atom processor; we don't know unless he tells us about resource use by Atom itself.

You might be right. At any rate it felt like an Atom issue, as I've not experienced lag like that on Bluefin, Geany, and other similar editors.

I'm on a MacBook Pro with 16GB RAM and I usually have Atom running ~5 projects with multiple tabs of source code open on each. I've left them open for days or even weeks and have not noticed any type lag.

I wonder why you get type lag, maybe you're working with really large files?

As long as it's Electron-based, that's basically impossible.

I'm really impressed with the tick-tock of Atom development. Their turnaround time on releases with major new features in each release is really something to see.

And, it's a pretty decent rebuttal to the questions folks raise about the decision to build on Electron in Javascript. The tradeoffs are big (memory, startup time, performance), but the benefits are maybe bigger (huge dev community, tremendous resources being thrown at the biggest problems in the form of work on the JavaScript engine and language, easy-ish entry for new developers, etc.). Even with all of its flaws, it's still a better experience enough of the time for enough of the people that it's become one of the most popular editors almost overnight.

Still prefer Sublime over Atom. I can't stand software that wastes Memory like Atom does.

Then again Atom has a nice UI. Maybe in the future...

Atom 1.21 features support for the language server protocol

Wow, that's a big one! I'm eager to try Atom out again after being burned by speed issues years ago.

Those aren't gone.

Every update I hope there won't be lag, but sure enough there always is. Leave it open for a whole day and text input + browsing a project tree will freeze periodically. I'm on a maxed out Mac too...

You could try running it with no custom plugins. If it still happens I would report the issue at their GH repository.

As others above have said, me included, never experienced what you describe.

I've tried all the editors, when it comes down to it I always end up going back to some combination of Sublime + Vim. I prefer to do most things on the command line rather than set up IDE configurations, so a plain text editor suits me just right.

I like the customization of Sublime, and I've got it setup just how I like. In a way, Vim is similar... once you get it customized perfectly, there isn't going to be another text editor that beats it.

VScode is nice, but I don't really see any pros to it that would make me switch from Sublime, other than the Debugger maybe (which I never use).

"I prefer to do most things on the command line rather than set up IDE configurations, so a plain text editor suits me just right."

For me, the killer feature of editors like Atom and VS Code is zero-hassle setup of linters and code formatters. The integrations with Go tools will not only tell you what is wrong with your code as you work, they will automatically manage your imports directives and reformat the source.

Periodically I think about switching to Vim. I am sure that I could set up Vim to have the same features, but I feel like I might have to find a big chunk of time to learn how to manage Vim plugins and the appropriate key combinations to get the same effect.

What's your combination of Sublime and Vim?

I've recently switched from VSCode to Vim and have really started to like it. I try to use Vim keybindings in everything I do, including browsing on Chrome with the plethora of Vim-like extensions.

I still use Sublime, mainly for its multi-cursor editing power. I don't there's an editor that can really match Sublime's multi-cursor feature. I know there's a way of doing in in Vim, but I'm still learning this language, and it seems like a difficult concept for me to grasp right now

I just meant that I use Sublime and Vim as my primary text editors. I do use the "vintage" mode in Sublime also, which mimics some of Vim's functionality.

By how has the performance improved? The last I checked Atom was way too slow as compared to other editors even VSCode.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact