HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
meta
hhvm
C++2010–2025
meta / hhvm

hhvm

A virtual machine for executing programs written in Hack.

Systems & Infrastructure
Explore on GitHubRead Hacker News discussions
65Distinct people
75Mentions
0Explicit recommenders
18.7KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A virtual machine for executing programs written in Hack.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year75 dated mentions

Observed mentions: 2010-02-03 00:23:26 UTC to 2025-01-02 20:28:29 UTC.

0510152010-01-01 00:00:00 UTC to 2011-01-01 00:00:00 UTC (exclusive): 5 mentions; 2 submissions, 3 comments20102011-01-01 00:00:00 UTC to 2012-01-01 00:00:00 UTC (exclusive): 9 mentions; 1 submissions, 8 comments2012-01-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 10 mentions; 0 submissions, 10 comments2013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 15 mentions; 1 submissions, 14 comments2014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 15 mentions; 0 submissions, 15 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20102010-01-01 00:00:00 UTC2011-01-01 00:00:00 UTC523
20112011-01-01 00:00:00 UTC2012-01-01 00:00:00 UTC918
20122012-01-01 00:00:00 UTC2013-01-01 00:00:00 UTC10010
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC15114
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC15015
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC404
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC101
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC202
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC202
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC110
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC303
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC413
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC211
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
HHVM HHVM page | HHVM documentation | Hacklang page | General group | Dev group | Twitter HHVM is an open-source virtual machine designed for executing programs written in Hack. HHVM uses a just-in-time (JIT) compilation approach to achieve superior performance while maintaining amazing development flexibility. HHVM should be used together with a webserver like the built in, easy to deploy Proxygen, or a FastCGI-based webserver on top of nginx or Apache. Installing If you're new, try our getting started guide. You can install a prebuilt package or compile from source. Running You can run standalone programs just by passing them to hhvm: hhvm example.hack. If you want to host a website: Install your favorite webserver. Proxygen is built into HHVM, fast and easy to deploy. Install our package Start your webserver Run sudo /etc/init.d/hhvm start Visit your site at http://.../main.hack Our getting started guide provides a slightly more detailed introduction as well as links to more information. Contributing We'd love to have your help in making HHVM better. If you're interested, please read our guide to contributing. License HHVM is licensed under the PHP and Zend licenses except as otherwise noted. The Hack typechecker is licensed under the MIT License except as otherwise noted. The Hack Standard Library is licensed under the MIT License except as otherwise noted. Reporting Crashes See Reporting Crashes for helpful tips on how to report crashes in an actionable manner. Security For information on reporting security vulnerabilities in HHVM, see SECURITY.md. FAQ Our user FAQ has answers to many common questions about HHVM, from general questions to questions geared towards those that want to use. There is also a FAQ for contributors to HHVM.
Read the full README on GitHub

What Hacker News says

75 sources
throwitaway1123·Aug 14, 2024
This looks pretty cool. One issue I have from just a cursory glance is that the IO capability includes things like `print` and `echo` [1]. If the context system can't differentiate between `console.log` and `fetch`, then it's a little less useful for me. If there was a way for users to define their own coeffects then you could sidestep this issue, but I saw this quote in one of the design documents: "Runtime will have a native knowledge of each co-effect. We will not allow co-effects to be defined in user-land code [...] An important aspect to note here is that certain co-effects that need deep support from runtime such as io and pure will need to be implemented in the runtime" [2]. [1] https://docs.hhvm.com/hack/contexts-and-capabilities/availab... [2] https://github.com/facebook/hhvm/blob/master/hphp/hack/doc/H...
In I avoid async/await in JavaScript (2022)
mgraczyk·Oct 27, 2021
The answer to your first question is yes. Your second question is based on an incorrect premise. Hack is internally built, but it is also open source: https://github.com/facebook/hhvm I joined Facebook in 2019 and left this year. Prior to FB, I worked mostly with python, javascript, and C++. Even at FB, I worked mainly in python (instagram backend), but spent a lot of time in the Hack codebase. My experience was that FB's Hack + HHVM stack is much easier to work with and felt more productive than any other backend stack I've used. It's important to consider that a huge portion of Facebook's backend is one giant HHVM monorepo (called www). The consistency and uniformity has allowed FB to build lots of tooling and developer productivity on top of this one stack. For example, when you add feature flags, the tooling will automatically create
Read the rest
a diff (PR) to remove the feature flag once it has been fully rolled out for a few weeks. There are rough edges and weirdnesses, but HHVM is pretty actively being improved. Old mutable builtins are being (or have been) removed, the type system has gotten better, better error and warning messages all the time. FB is very responsive to data on developer productivity. EDIT: Another anecdote, when I first joined I was working on both the Instagram python codebase and the Hack API codebase (some of Instagram's APIs are in Hack/HHVM). I constantly wondered why we didn't migrate the Hack code to python, and talked with various people about proposals and potential paths to do the migration for the APIs I worked on. After a few months of working in both codebases, I completely flipped. After witnessing insane bugs and horrible architectural contortions designed to mitigate python performance issues, I wondered why we didn't just migrate the python codebase to Hack. Python (on cpython/cinder) is just not ready for large scale web services, and Hack is a much more productive environment than Java/C++/Rust for backend. Typescript may be an even better option, but has some issues of its own.
In Ask HN: State of PHP at Facebook?

Showing the 15 most recent of 75 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.