Hacker News Reader

Comment by solipsism | Hacker News Reader

Again, a product that advertises being built on Go as if that's a feature. I have nothing against Go, but that's weird -- no one cares what Slack is written in.

View on HN

Personally I care about the security of the server (is it written in a language that historically has a good or poor track record), and I care a great deal about the client.

The Slack client regularly pauses for me while I am typing, randomly refreshes, and generally feels sluggish. Those aren't things I associate with Go. That said, I think this particular implementation's client is also written in Javascript, so I don't know that it will have a particular advantage there. But an open source implementation at least won't block alternative clients (e.g. https://www.kickstarter.com/projects/2137936555/taut-the-fas...), in a way that the Slack Terms of Service would seem to do.

The desktop clients are built on Electron [1]. I've been using it for about 3 weeks and there's been a few times where performance issues were noticeable but not bad enough for me to start digging in the code to find the issue. Overall I think it's a well put together app, but people who hate anything built on Electron will probably have bad things to say about it.

[1] https://github.com/mattermost/desktop

Slack's performance also depends a ton on how much your teams are using it, and how many teams you're on.

"reactjis" are one of the worst offenders -- I've had a channel open with some people messing around with them, and it'll be casually consuming 30% of cpu and 3 gigs of ram on my top-of-the-line macbook.

I would have long since deleted an IRC client that was such a poor performer, but unfortunately there's not any good/complete 3rd party slack clients.

Lots of poorly written webapps give Electron a bad name. Slack, unfortunately does have it's performance issues, but there are other popular chat apps written in Electron that are very performant, even on large teams.

You can just use an IRC client and the IRC bridge...

Hey - i made that kickstarter! Unfortunately it doesn't seem there was much interest so it went nowhere. I still think it's regrettable how resource-hungry the official client is, but doesn't seem that too many people share that opinion.

I audited Mattermost 1.x through 3.x a while back. Had some issues but everything was fixed smoothly and from 3.x it is actually really good. Slides from my talk on it here: https://speakerdeck.com/addelindh/hacking-mattermost-an-asse...

Thanks @addelindh! Really love your work. You helped us a ton, highly appreciated!

Thanks yourself, you and your team is a pleasure to work with.

I believe you host the product yourself -- so if you are going to have to deploy it, modify it, etc., you'll want to know what stack it's built on.

Yep.

I still hesitate to even consider deploying rails or node.js applications.

It's just too many things to learn and keep up to date with.

Of course if you already develop in rails or node.js or run some other services already that might not be an issue.

But to me - unless it is apt-gettable - a standalone binary (typical go), war or jar file has a huge advantage.

Mattermost actually is apt-gettable if you install it alongside GitLab CE with GitLab's omnibus package¹.

1: https://about.gitlab.com/downloads/

And it's written in golang, not rails or node.js

I disagree. The language the app is written in speaks a lot about the culture of the software. If it was Java, I would expect something very different than if it was written in PHP.

If you think they're all the same, then maybe you need to get some more real world experience.

Slack is written in PHP, I guess people care more when they have to host it themselves. I wonder whether the stories of Slack's codebase being a hot mess are the real reason it's still not available to self-host.

Its realtime server is Java though.

That's just a throw away sentence in the article to emphasize its open source nature. All the main points of the article are bolded subheadings.

This is a really good question, I'll try to answer from different perspectives (and hopefully others can chime in with what I missed).

1) For End Users and Developers, Golang can mean fewer bugs

Golang is a "type-safe" language, meaning that all the programming code is written to be explicit and consistent, versus "untyped" languages like PHP or JavaScript, where programming is more implicit with many different ways to say the same thing.

It's easier for software tools to automatically analyze type-safe languages and find bugs. And those languages are also easier to read and review--since there's only one way to express something--and that helps too.

2) For System Administrators, Golang means easier install and management

Golang is a "complied language", meaning that after the programming is done, a single file is produced. So a System Administrator just installs one file and Mattermost works. To upgrade, they just change that one file. Easy!

Languages like PHP and JavaScript are "interpreted languages", meaning that a System Administrator would need to download lots and lots of files, install one or more programs to interpret those files, and hope that nothing breaks. When it's time to upgrade, she's got to make sure all the files and interpreters on her server are exactly the right version. It can be a nightmare to maintain.

3) So what's the trade-off?

The trade-off with Golang is that it takes more work to learn than PHP and JavaScript. The programming language isn't as forgiving to new programmers. You need to say things exactly the right way or the program won't even start, whereas PHP and JavaScript if you say things "kind of right" and things will "kind of work".

Does this help?

Implementation details can be important features of open source products.

Reply on news.ycombinator.com