4 ms·

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 t

by _eht 9y ago

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 9y ago
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.
- _eht 9y ago
  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 9y ago
    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 9y ago
      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.
- methodin 9y ago
  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 9y ago
    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 9y ago
      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.
- yjftsjthsd-h 9y ago
  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 9y ago
    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.
- sjellis 9y ago
  I wish that I could upvote this twice.
krainboltgreene 9y ago
If you have 32gb of RAM and you're getting type lag after 2 days, it's probably not a RAM issue, right?
- yjftsjthsd-h 9y ago
  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 9y ago
  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.
- alloyed 9y ago
  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.
wjoe 9y ago
>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 9y ago
> 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.
SwellJoe 9y ago
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?
jimnotgym 9y ago
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.
anonfunction 9y ago
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?

by _eht 9y ago

dmit 9y ago

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.

_eht 9y ago
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 9y ago
  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 9y ago
    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.
methodin 9y ago
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 9y ago
  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 9y ago
    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.
yjftsjthsd-h 9y ago
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 9y ago
  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.
sjellis 9y ago
I wish that I could upvote this twice.

krainboltgreene 9y ago

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

yjftsjthsd-h 9y ago
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 9y ago
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.
alloyed 9y ago
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.

wjoe 9y ago

>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 9y ago

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

SwellJoe 9y ago

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?

jimnotgym 9y ago

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.

anonfunction 9y ago

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?