Live data from Hacker News

Atom 1.20

blog.atom.io

31–40 of 69 posts

Re: Atom 1.20

#31
post #12
post #6

Earlier quoted context omitted.

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.

Re: Atom 1.20

#32
post #6
post #3

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.

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?

Re: Atom 1.20

#33
post #22

Earlier quoted context omitted.

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.

Re: Atom 1.20

#34
post #5

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 (thou…

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

Re: Atom 1.20

#36
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.

Re: Atom 1.20

#37
post #5

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 like VSCode, but the Clojure integration in Atom is top notch. When that catches up I might take another look.

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

Re: Atom 1.20

#38

Earlier quoted context omitted.

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 (thou…

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.

Re: Atom 1.20

#39
post #37

Earlier quoted context omitted.

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

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

Re: Atom 1.20

#40
post #6

Earlier quoted context omitted.

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.

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

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.
Post reply on HN