[_eht]

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.

[dmit]

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.

[yjftsjthsd-h]

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.

[zanny]

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.

[methodin]

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.

[dmit]

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.

[methodin]

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.

[_eht]

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.

[dmit]

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.

[_eht]

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?

Noted.

[sjellis]

I wish that I could upvote this twice.

[wjoe]

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

[cyberferret]

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

[jimnotgym]

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.

[SwellJoe]

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?

[krainboltgreene]

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

[alloyed]

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.

[yjftsjthsd-h]

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.

[_eht]

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.

[anonfunction]

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?