Hacker News Reader

Comment by t0mas88 | Hacker News Reader

They got themselves into a mess here:

> This turns out to have a lot of complexity lurking within. Slack does not share a common codebase or even runtime; services in the user-facing request path are written in Hack, Go, Java, and C++. This would necessitate a separate implementation in each language.

This sounds crazy. I've seen several products where there is a core stack (e.g. Java) and then surrounding tools, analytics etc in Python, R and others. But why would you create such a mess for your primary user request path?

Sure, they're not "just a chat app" they have video, file sharing etc included and a lot of integrations. But still this sounds like a company that had too much money and too little sense while growing rapidly.

View on HN

"The right language for each job" was one of the heavy advertising points for microservices. Might still be too some extent, even.

The problem is most engineers don't understand the "job".

They see the job as a strictly technical problem looking for the best technical solution. They don't look up and see how that problem fits into the larger organization.

They think things like "I can make a microservice that encodes PDFs 10x faster by using Rust" and give an estimate based on that, never thinking about how we're going to need to hire 2 more Rust devs to keep that running, and we could have delivered twice as quickly if I had used our default Python stack and now our "10x faster" doesn't matter because that feature is old news.

Microservices are such an unfortunate concept because they attract the people least suited to use them: If your team can't handle a monolith, you shouldn't even be looking up what a microservice is.

It even pains me to see they're suffering from so many own goals. And it's unfortunately reflected in the poor experience using the Slack client. Not to mention the multiple deprecated bot/integration APIs with such bad feature parity between all the different ways to integrate your own tooling into Slack.

What do you mean? Slack is one of the most responsive and reliable tools I touch every day.

How slow are the rest of your tools? The Slack client probably performs worse today than it did a few years ago. It has the laggiest interface of any of my tools, you can watch your CPU spike to 60-80% just switching channels. Just do it right now, open up htop/top/atop/Activity Monitor - whatever you want, and just switch channels. Laugh as the Slack client wastes a universe's worth of time just... rendering a DOM with plain text. It is genuinely pathetic how bad the client is.

I hope this is satire. Slack is one of the slowest work tools I've ever used. Every interaction and click visibly lags.

It's a sad state of the world that almost every application now is written in Javascript and deployed with Electron, and massive memory usage and slow UIs have become accepted as the norm.

Try any IRC client and tell me, with a straight face, that Slack is just as responsive.

Very interesting. I have used Slack for work on a MacBook for years, and I have never once noticed any responsiveness issues or lags at all.

So I only use Firefox and the Slack web client and don't experience any lag. I am surprised so many people use the Slack app over a web tab.

Ok genuine question: what other tools do you use?

Slack won’t seem that bad, until you use something that’s actually good.

The loss of performance on commonplace applications has been a real “boil the frog” situation; we’ve lost so much performance and responsiveness, but it’s happened so gradually that most people don’t notice.

Well, status.slack.com says they're currently having an outage, that has been ongoing for multiple days.

There was a time when this was the case (and electron was the punching bag for critics at the time, iirc) but I don’t think this criticism is fair anymore. Slack is quite responsive and performant these days.

The only way you get Hack on that list of languages is that they had a policy of letting lead engineers starting a project to choose the language at will, and they hired enough lead engineers who previously worked at FB/Meta.

I think that Hack might’ve been on that list earlier than you think. Slack started as a PHP application.

Yeah. If they already had a large php codebase, moving to Hack makes complete sense.

What mess? That sounds like a healthy internal language ecosystem to me. You need at least 2 primary languages to avoid accidental lock-in and maintain good developer diversity. That very paragraph is a great example of how the diversity helped them avoid the trap of plumbing it through their RPCs.

Since when is an "internal langue ecosystem" a good idea? Technology in a company like Slack exists to deliver useful features and good performance/stability to users faster than competitors can do it. For an app like theirs it doesn't sound like something that needs several disparate internal platforms that are slowing them down.

How is choosing the right language for a task/team slowing them down?

For large scale, cross cutting initiatives you’ll have some pain. For feature velocity, you’ll see great results. Everything is a trade off.

Standardizing on a single language/toolset is a form of tech debt and has similar up/downsides. Comparable to, for example, how skipping testing will increase your velocity in the short run, but it will hurt it in the long run.

You're suggesting that needing to reimplement the same thing 5 times for every single language in use is a hallmark of a "healthy internal language ecosystem"?

That's the red flag, the thing you are trying to avoid. You don't want to implement things in each language and you always have more than one language even if you standardize (over time). You don't want libraries, you want services. This is why things like Istio are way better than libraries for mesh networking. Using external services for common things keeps you from being locked into a single tech stack and the limitations that entails.

Reply on news.ycombinator.com