Yes — see my recent article https://slack.engineering/hakana-taking-hack-seriously/

We use a few languages to serve client requests, but by far the biggest codebase is written in Hack, which runs inside an interpreter called HHVM that’s also used at Facebook.

I really like the writing style in that article:

> PHP makes it really easy to make a dynamically-rendered website. PHP also makes it really easy to create an utterly insecure dynamically-rendered website.

Hi Matt

Thanks for Psalm!

Curious, if Slack was built today from ground up - what tech stack do you think should/would be used?

That’s a simple question that’s hard to answer.

A slightly different question that’s a bit easier to answer: “if I could wave a magic wand and X million lines of code were instantly rewritten and all developers were instantly trained on that language”.

There the choice would be limited to languages that have similar or faster perf characteristics to Hack, without sacrificing developer productivity.

Rust is out of the question (compile times for hundreds of devs would instantly sap productivity). PHP, Ruby, Node and Python are too slow — for the moment at least.

So it would be either Hack or Go. I don’t know enough about JVM languages to know whether they would be a good fit.

I like your question way better than mine :)

Some follow-up …

A. isn’t PHP on par perf wise to Hack these days? Re: “PHP is too slow” comment.

B. have you ever looked into PHP-NGX? It’s perf looks impressive, though you lose the benefit of stateless

https://github.com/rryqszq4/ngx-php

https://www.techempower.com/benchmarks/#section=data-r21

> isn’t PHP on par perf wise to Hack these days?

No. But I don't have any numbers, because it's been years since the two languages were directly comparable on anything but a teeny tiny example program.

Facebook gets big cost savings from a 1% improvement in performance, so they make sure that performance is as good as it can possibly be. They have a team of engineers working on the problem.

PHP doesn't have any engineers working on performance full-time — it's impossible for the language to compete there. Hack has also removed a bunch of PHP constructs (e.g. magic methods) that are a drain on performance, so there's no way to close the gap.

But that should in no way make you choose Hack over PHP. Apart from anything else, the delta won't matter for 99.9% of websites.

Yes, Hack is for Google or FB scale stuff. But to be honest, Slack is probably up there also, so it makes sense

PHP served by an nginx (never saw the abbreviation NGX to be honest) server is standard procedure in PHP land.

Other alternatives are Apache, Caddy, and more…

Not erlang?

But Discord uses Rust to improve performance bottlenecks in OTP ;)

Thank you for being brave enough not to suggest Rust.

PHP has some excellent ideas that other languages can't replicate, while at the same time having terrible ideas that other languages don't have to think about. Overall a huge fan of modern PHP, thanks for this writeup.

Which excellent ideas does it have that other languages can't replicate?

Perhaps more precisely: the defacto Apache-as-runtime + PHP model simplifies a ton of things. Namely your request state is created and destroyed all within the context of a single process, and you don't have to reason about shared state with other in-flight requests (unless you explicitly choose to go this route). It makes some bad programming patterns workable, because your state doesn't linger over a long-running period. Deploys are also super fast, you just have to swap the application code on disk and it'll get picked up on the next request (in-flight requests will keep processing with the old version IIRC). It's productive if not necessarily pretty. Also it has a type system now!

As a related thought, a lot of the modern serverless stuff feels like it's reinventing the ideas of Apache + PHP, or perhaps CGI?

I noticed that the hack blog (https://hhvm.com/blog/) basically stopped posting updates since the end of 2022. As downstream users of hacklang development have you folks noticed a change in development pace or ambition within the hack development team?

I too am super curious about this.

Plus, it seems telling that Threads was developed in Python - not Hack.

(I’m aware IG is Python & it’s the same team)

You answered yourself there, Hack is still very widely used inside meta, just less so in IG.

If anything from what I’ve heard hack is slowly taking over IG and WhatsApp. But it’s an incredibly large codebase to move

Kinda makes sense you would use PHP, even though I'm sure many people are shocked by it. PHP was pretty much born in a web context. The language was created with servers and request/response in mind and it shows.

from the article:

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

Man what a mess. Meanwhile, everyone else can extend a library used by their common services in a common language trivially.

Let me guess, they should rewrite everything in Javascript?

Woe is us if they actually did.

Nah, Excel. /s

Almost everyone embraced polyglotism and microservices together.

Meh. As long as you’ve got a good, typed interface for passing messages between them and for having a common understanding of (and versioning system for) key data structures, that’s fine for this sort of thing where it’s largely processing steams of small messages and events.

… but it’s probably JSON and some JSON-Schema-based “now you have two problems” junk instead of what I described. In which case, yeah, ew, gross. Unless they’ve made some unusually good choices.

There are tons of approaches to align on service contracts for JSON based API calls. There’s also libraries like gRPC which help make contacts explicit. Neither are really uncommon

What are some of those approaches? Are there formal methods and/or tools for doing this?