5 ms·

infinitely more features than Slack and uses infinitely less memory :p

by jcelerier 8y ago

wyldfire 8y ago
Why compare memory consumption of a image editing program to a chat service?
- alias_neo 8y ago
  Perhaps, because arguably, an image editing software should be using a lot MORE memory than a chat service? I appreciated the comment as a light humoured jab at the insane amount of memory slack needs just to send some text to each other (over simplification).
- deleted 8y ago
  [deleted]
- criddell 8y ago
  It's really just a thinly veiled attack on Electron.
  - james-skemp 8y ago
    Sorry, but I think you're wrong. VS Code is based on Electron and runs great. I read it as a comment on Slack's performance, not as an attack on Electron.
    - criddell 8y ago
      Every post about VS Code on HN inevitably contains criticism about it's Electron foundation. e.g. https://news.ycombinator.com/item?id=15599319 https://news.ycombinator.com/item?id=15599319
    - chmln 8y ago
      No, VSCode doesn't run great. Maybe compared to IntelliJ and Visual Studio, but far worse than sublime text and vim. I have ~2ms input latency using vim on xterm. I doubt VSCode can ever achieve this kind of performance, simply due to the poor architectural decision of using electron and JavaScript.
      - aidenn0 8y ago
        I still remember the days when users of various vi clones derided emacs as "Eight Megabytes And Constantly Swapping" and now a single gvim instance with no files open is 37MB emacs is 51MB and atom is 300MB. My actually running emacs with slime loaded in the middle of debugging a lisp application is 127MB, which is still smaller than a freshly opened atom instance.
        jcelerier 8y ago
        > a single gvim instance with no files open is 37MB emacs is 51MB and atom is 300MB. this does not really strike me as odd for emacs and vim - pretty sure that if you load them in a computer with a 640 by 480 screen in a 32-bit OS on IceWM it will be comparable to the olden days. On todays's 4k screens, just opening a window that takes half of your screen will alone cost a good dozen megabytes of RAM - and if your UI widgets do caching (they should, text rendering is expensive), then each of your widgets may allocate a pixmap too. When screens were 72 DPI and a button was 30 by 10 pixels it was fine... but nowadays you have to multiply all the values by at least 4. And the switch to 64bit has instantaneously doubled the size of all the data structures working with pointers - which is generally a lot in GUI apps since most are trees of widgets. In some of the apps I've been working on, the RAM hit of 64bit has been more than 30%, and sadly the world does not seem to accept the x32 ABI.
        loup-vaillant 8y ago
        We could have 32-bit pointers with a bit of hacking: First, re-implement memory management on top of std::vector (or similar dynamic array): have your pointers be array indices; replace the `brk()` system call by the `resize()` method; reimplement `malloc()` on top of that. And voilà, you can have your 32-bit pointers. You can even go down to 16-bits for small enough arenas. (No, I'm not actually serious. Though we could imagine something similar on some new language.)
        jcelerier 8y ago
        > We could have 32-bit pointers with a bit of hacking: We can also have them with zero hacking since there is an existing ABI for 32 bits pointers in 64 bit mode: https://wikipedia.org/wiki/X32_ABI https://wikipedia.org/wiki/X32_ABI ; you get all the benefits of x86_64 mode (more registers, default support of SSE2 etc) for the memory usage level of x86 (and 4gb of accessible ram instead of x86 OSes's 2.something addressable gigabytes). I'm pretty sure that only specialized apps actually require >4gb of ram - most common utilities (e.g. shell, text editor, etc...) should really be compiled in x32 mode.
bachmeier 8y ago
"Krita is a professional FREE and open source painting program. It is made by artists that want to see affordable art tools for everyone." Why would you compare that with Slack?
- jcelerier 8y ago
  For exactly the reason alias_neo provided. It's madness to think that a chat program developed by a company of ~1 thousand employees valuated at 7.1 billion $, should take more memory, more disk space, and be less portable (Krita also works on FreeBSD and Haiku which Slack does not support) and be slower than a full-fledged art software developed at 100% by mostly unpaid open-source volunteers.
  - soapdog 8y ago
    that IMO is not a valid comparison, not even remotely valid, because those two products are built with completely different stacks. Krita is native, slack is webby. Also assuming that just because it is developed by unpaid open-source volunteers it should somehow be slower than something developed by an expensive for-profit company is passing judgement on people who are donating their free time and effort into building this, and that is not cool. We should all just stop comparing native apps to electron based apps, those things are soooo different. Electron/Chrome/Firefox/$browser are doing a ton of stuff behind the scenes, they are basically little virtual machines running the web platform. Comparing that to native is meaningless. You can of course prefer native apps, no one is arguing that, and yes you're correct that native apps will often use less resources, but it is the same as saying that a jumbo jet is much faster than a kickscooter, it might be true but what kind of comparison is that?! people are not building stuff with electron because they want to use less resources, the reasoning behind it is usually something else that those teams think is a valid trade-off
    - lucideer 8y ago
      It's a valid comparison because of all of your points. The question here is: why use Electron as a stack at all. The general arguments are to do with building modern, aesthetic, easy-to-use cross-platform apps with less dev resources. Slack as a company are not dev-resource-constrained, so this makes Krita an exemplary counter-example to anyone who ever defended Electron for these reasons.
drivingmenuts 8y ago
Does anyone who uses Slack actually like Slack, aside from people who work at Slack? I use it at work and church and I have yet to find anyone who likes it (including myself).
- newnewpdro 8y ago
  At my last startup in SF, when slack was really starting to takeoff, most of the business/marketing folks who spent the bulk of their time chatting and sharing memes on slack loved it. They simply didn't know any better, and were enamored with the new level of internal communication vs. previous jobs. Man it was such a time sink. Between the open office floorplan and slack this was the least productive environment I'd ever seen for an engineering company, and it's largely caused me to walk away from the industry.
- petercooper 8y ago
  We use it in our company and I really like it. It's opened up a lot of workflows and data streams that either wouldn't exist or would go ignored. However, it might be relevant data that I am the boss and chose it ;-)
- morganvachon 8y ago
  I don't think "like" is the word I would use. I don't "like" or "dislike" my power drill, but it is more efficient than a screwdriver or hand drill, it gets the job done, and it rarely leaves me wanting for something bigger or with more features. By the same token, Slack fulfills a need and does so adequately; its features are enough to do interoffice communication without having to fall back on email or texting. I'm sure there are better tools out there, and Slack is definitely slower on our Core i3 based workstations compared to our beefier machines, but we don't "like" or "dislike" it.

infinitely more features than Slack and uses infinitely less memory :p

wyldfire 8y ago

Why compare memory consumption of a image editing program to a chat service?

alias_neo 8y ago
Perhaps, because arguably, an image editing software should be using a lot MORE memory than a chat service? I appreciated the comment as a light humoured jab at the insane amount of memory slack needs just to send some text to each other (over simplification).
deleted 8y ago
[deleted]
criddell 8y ago
It's really just a thinly veiled attack on Electron.
- james-skemp 8y ago
  Sorry, but I think you're wrong. VS Code is based on Electron and runs great. I read it as a comment on Slack's performance, not as an attack on Electron.
  - criddell 8y ago
    Every post about VS Code on HN inevitably contains criticism about it's Electron foundation. e.g. https://news.ycombinator.com/item?id=15599319 https://news.ycombinator.com/item?id=15599319
  - chmln 8y ago
    No, VSCode doesn't run great. Maybe compared to IntelliJ and Visual Studio, but far worse than sublime text and vim. I have ~2ms input latency using vim on xterm. I doubt VSCode can ever achieve this kind of performance, simply due to the poor architectural decision of using electron and JavaScript.
    - aidenn0 8y ago
      I still remember the days when users of various vi clones derided emacs as "Eight Megabytes And Constantly Swapping" and now a single gvim instance with no files open is 37MB emacs is 51MB and atom is 300MB. My actually running emacs with slime loaded in the middle of debugging a lisp application is 127MB, which is still smaller than a freshly opened atom instance.
      - jcelerier 8y ago
        > a single gvim instance with no files open is 37MB emacs is 51MB and atom is 300MB. this does not really strike me as odd for emacs and vim - pretty sure that if you load them in a computer with a 640 by 480 screen in a 32-bit OS on IceWM it will be comparable to the olden days. On todays's 4k screens, just opening a window that takes half of your screen will alone cost a good dozen megabytes of RAM - and if your UI widgets do caching (they should, text rendering is expensive), then each of your widgets may allocate a pixmap too. When screens were 72 DPI and a button was 30 by 10 pixels it was fine... but nowadays you have to multiply all the values by at least 4. And the switch to 64bit has instantaneously doubled the size of all the data structures working with pointers - which is generally a lot in GUI apps since most are trees of widgets. In some of the apps I've been working on, the RAM hit of 64bit has been more than 30%, and sadly the world does not seem to accept the x32 ABI.
        loup-vaillant 8y ago
        We could have 32-bit pointers with a bit of hacking: First, re-implement memory management on top of std::vector (or similar dynamic array): have your pointers be array indices; replace the `brk()` system call by the `resize()` method; reimplement `malloc()` on top of that. And voilà, you can have your 32-bit pointers. You can even go down to 16-bits for small enough arenas. (No, I'm not actually serious. Though we could imagine something similar on some new language.)
        jcelerier 8y ago
        > We could have 32-bit pointers with a bit of hacking: We can also have them with zero hacking since there is an existing ABI for 32 bits pointers in 64 bit mode: https://wikipedia.org/wiki/X32_ABI https://wikipedia.org/wiki/X32_ABI ; you get all the benefits of x86_64 mode (more registers, default support of SSE2 etc) for the memory usage level of x86 (and 4gb of accessible ram instead of x86 OSes's 2.something addressable gigabytes). I'm pretty sure that only specialized apps actually require >4gb of ram - most common utilities (e.g. shell, text editor, etc...) should really be compiled in x32 mode.

bachmeier 8y ago

"Krita is a professional FREE and open source painting program. It is made by artists that want to see affordable art tools for everyone." Why would you compare that with Slack?

jcelerier 8y ago
For exactly the reason alias_neo provided. It's madness to think that a chat program developed by a company of ~1 thousand employees valuated at 7.1 billion $, should take more memory, more disk space, and be less portable (Krita also works on FreeBSD and Haiku which Slack does not support) and be slower than a full-fledged art software developed at 100% by mostly unpaid open-source volunteers.
- soapdog 8y ago
  that IMO is not a valid comparison, not even remotely valid, because those two products are built with completely different stacks. Krita is native, slack is webby. Also assuming that just because it is developed by unpaid open-source volunteers it should somehow be slower than something developed by an expensive for-profit company is passing judgement on people who are donating their free time and effort into building this, and that is not cool. We should all just stop comparing native apps to electron based apps, those things are soooo different. Electron/Chrome/Firefox/$browser are doing a ton of stuff behind the scenes, they are basically little virtual machines running the web platform. Comparing that to native is meaningless. You can of course prefer native apps, no one is arguing that, and yes you're correct that native apps will often use less resources, but it is the same as saying that a jumbo jet is much faster than a kickscooter, it might be true but what kind of comparison is that?! people are not building stuff with electron because they want to use less resources, the reasoning behind it is usually something else that those teams think is a valid trade-off
  - lucideer 8y ago
    It's a valid comparison because of all of your points. The question here is: why use Electron as a stack at all. The general arguments are to do with building modern, aesthetic, easy-to-use cross-platform apps with less dev resources. Slack as a company are not dev-resource-constrained, so this makes Krita an exemplary counter-example to anyone who ever defended Electron for these reasons.

drivingmenuts 8y ago

Does anyone who uses Slack actually like Slack, aside from people who work at Slack? I use it at work and church and I have yet to find anyone who likes it (including myself).

newnewpdro 8y ago
At my last startup in SF, when slack was really starting to takeoff, most of the business/marketing folks who spent the bulk of their time chatting and sharing memes on slack loved it. They simply didn't know any better, and were enamored with the new level of internal communication vs. previous jobs. Man it was such a time sink. Between the open office floorplan and slack this was the least productive environment I'd ever seen for an engineering company, and it's largely caused me to walk away from the industry.
petercooper 8y ago
We use it in our company and I really like it. It's opened up a lot of workflows and data streams that either wouldn't exist or would go ignored. However, it might be relevant data that I am the boss and chose it ;-)
morganvachon 8y ago
I don't think "like" is the word I would use. I don't "like" or "dislike" my power drill, but it is more efficient than a screwdriver or hand drill, it gets the job done, and it rarely leaves me wanting for something bigger or with more features. By the same token, Slack fulfills a need and does so adequately; its features are enough to do interoffice communication without having to fall back on email or texting. I'm sure there are better tools out there, and Slack is definitely slower on our Core i3 based workstations compared to our beefier machines, but we don't "like" or "dislike" it.