Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Slack client for the terminal

github.com

Post reply on HN
Print view View original

171–180 of 184 posts

Re: Slack client for the terminal

#171

Post by vbezhenar »

tachyoff wrote: post #122
vbezhenar wrote: post #54

Earlier quoted context omitted.

Current software stacks are incredibly bloated. I recently wrote a simple Java web server. I took care no to use unnecessary memory, I didn't use a single library for it, yet it can't do even basic functions without OOM unless I'm giving it 16MB RAM for heap (and it eats even more for other things). So almost 20 MB RAM for hello world. And that's for relatively efficient VM. I guess, similar web server written with C…

That's such an unfair comparison, though (and really, with 8+ GB of RAM being the norm, 20 MB is still pretty svelte). Java has an entire virtual machine and runtime, whereas a C program is just a binary that gets loaded straight into memory.

Java theoretically taking a lot of care not to use excessive memory. It loads classes on demand, it compiles bytecode only when this path is really hot. I don't really see why it's necessary to use 16MB RAM. Golang has GC and doesn't that much memory. Lua has an entire virtual machine and runtime and doesn't use that much memory either. It's not a valid argument. I still believe that current JVM developers just don't care that much about memory consumption which is a valid decision, but I don't like it anyway. Not everyone has 8+GB of RAM. I have 256 MB VPS which runs quite a few of network services and has half of memory free, but I don't think that I could afford Java if I want to run something there, even if my load is tiny.

Re: Slack client for the terminal

#173

Post by sincerely »

zimpenfish wrote: post #170
LocutusOfBorges wrote: post #10

Earlier quoted context omitted.

Eul seems like it might fit that requirement: https://eul.im/

I tried the latest Mac version. Crashed instantly I tried to log into Slack. Maybe in a few revisions it'll work but for now, it doesn't seem to.

Yeah, I'm looking forward to checking in with eul in about six months, the idea seems promising but it's nowhere near usable (for my personal value of usable) yet

Re: Slack client for the terminal

#174

Post by [deleted] »

Karunamon wrote: post #53
drb91 wrote: post #51

Earlier quoted context omitted.

This ignores the fact that if you don’t respond to people contacting you you’ll get fired. As a salary you have no voice. The market simply optimizes for whatever is easiest for a ceo to install and maintain.

How is this Slack's fault, again? Or is the argument that messaging systems should be hard to install so they aren't misused? Seriously, what even is this comment chain getting at? If you work somewhere where always-on is a hard requirement, it doesn't matter what messaging system is used. Any place that would fire you for muting notifications would just as easily fire you for turning off email notifications. In shor…

[deleted]

Re: Slack client for the terminal

#175

Post by u801e »

arghwhat wrote: post #28

I miss the days where people recognized that using using 20MB of RAM for a trivial task is obscene. (Great tool, much better than the awful official client, but 20MB is actually a lot of RAM.)

There's an old joke about emacs standing for eight megabytes and continuously swapping.

But I think it's more useful to think about the percentage use of RAM for a given application. If you're running on a machine with 32 MB of RAM, then using 20 MB for a single application is obscene. But if you're running 32 GB, it's insignificant.

Even so, a single application shouldn't be using a significant percentage of system RAM on an average consumer grade laptop/desktop (4 to 16 GB of RAM).

Re: Slack client for the terminal

#176

Post by u801e »

jethro_tell wrote: post #134
QasimK wrote: post #82

Earlier quoted context omitted.

I know someone who uses the gateway but it was a long while before we (I) found out that he didn't receive edits or emoji reactions, which may or may not have caused significant miscommunications.

when did correcting your message become so hard that we needed editS? *edits

I've always used the sed style edits over the IRC gateway. Then someone let me know that they don't work. I always thought that people just read them and parsed the correction manually rather than relying on their client to do it. It's not like I use very complext sed substitutions.

s/complext/complex/

Re: Slack client for the terminal

#177

Post by aidenn0 »

arghwhat wrote: post #168
aidenn0 wrote: post #139

Earlier quoted context omitted.

Because the engineering costs have not gone down so it may not make sense to spend the effort to reduce memory usage.

I suspect you might think I demand that every byte is used absolutely optimally. I'm sure some crazy chap out there could write this application with only a few hundred bytes of memory, but that's beside the point.

For a lot of my projects I use SBCL. The runtime for SBCL is 50MB. That would be a deal breaker for me in 1995, but it is a reasonable tradeoff for the increased productivity I get from it compared to slimmer runtimes.

Re: Slack client for the terminal

#178

Post by ergothus »

chubot wrote: post #135
ergothus wrote: post #121

Earlier quoted context omitted.

Slack addresses some of the problems, but not all: > The lack of conversations/threading is really annoying. Slack is arguably worse - they recently added threading (really comments that can go on a post - there is no nesting), but this has made me much more likely to miss any follow-up because messages are less visible than otherwise. > By default there seems to be a lot of leave/join spam. I used IRC for a year bef…

I'm responding to the parent, who was questioning the existence of Slack, because IRC already exists. That's not reasonable, as I explained in the comment you're replying to, and even more in another reply. IRC doesn't work "perfectly fine", at least in the context of the problems that Slack solves. I think we largely agree on technical matters; it's a matter of what relevance this has to the OP -- a Slack client for…

> If your stance is that IRC is irrelevant to this thread because Slack and IRC solve different problems

I was saying you are comparing Slack to IRC-when-used-to-solve-a-different problem. You haven't described IRC as it could be configured to handle the same problems as Slack, only when you've encountered it in the admittedly more common case that it's intended for drop by traffic.

Re: Slack client for the terminal

#179

Post by arghwhat »

aidenn0 wrote: post #177
arghwhat wrote: post #168

Earlier quoted context omitted.

I suspect you might think I demand that every byte is used absolutely optimally. I'm sure some crazy chap out there could write this application with only a few hundred bytes of memory, but that's beside the point.

For a lot of my projects I use SBCL. The runtime for SBCL is 50MB. That would be a deal breaker for me in 1995, but it is a reasonable tradeoff for the increased productivity I get from it compared to slimmer runtimes.

Huh, I very rarely hear about people using Common Lisp these days. Or Lisp at all, outside of Emacs Lisp (stories of Emacs Lisp often being tied to their nasty core dump hack).

What are your reasons for sticking to Common Lisp?

50MB "runtime" sounds quite extreme, even in this day and age. That's 2.5x the consumption of a fresh Node.js instance on my machine. :/

Re: Slack client for the terminal

#180

Post by arghwhat »

u801e wrote: post #175
arghwhat wrote: post #28

I miss the days where people recognized that using using 20MB of RAM for a trivial task is obscene. (Great tool, much better than the awful official client, but 20MB is actually a lot of RAM.)

There's an old joke about emacs standing for eight megabytes and continuously swapping. But I think it's more useful to think about the percentage use of RAM for a given application. If you're running on a machine with 32 MB of RAM, then using 20 MB for a single application is obscene. But if you're running 32 GB, it's insignificant. Even so, a single application shouldn't be using a significant percentage of system…

If you have 32GB of free memory, then 20MB is insignificant. Installed RAM is not an interesting number.

I'm currently on a 16GB machine, where I only have a terminal, a text editor and a browser with few (mild (wikipedia, hn, ...) tabs open. That gives 351 processes using a total of 8.7GB memory (2.11GB of which is unswappable, and about 1 gig of already compressed memory). My 3GB of disk caches go on top of that, and 0.5GB has already been swapped out.

I sure have room for a 20MB binary right now. However, on an 8GB system, I'd be in the red. I would already be swapping several GB, and any allocation would either evict (useful!) caches or swap out the memory of another process.

Any memory allocated in that state reduces the performance of some other component of the system.

Of course, 20MB is much better than the status-quo of casually burning a few hundred MB (or even a few GB) for simple tasks, and the situation of being out of memory with a whopping 8GB is caused primarily by the other "bad citizens", but the point here is that 20MB is indeed a quite big chunk of memory in real-world use-cases.

Post reply on HN