K tree is pretty quiet now

2 files changed, 2 insertions, 2 deletions

diff --git a/docs/implementation/kclaims.html b/docs/implementation/kclaims.html
index b00d9ca1..d11de34a 100644
--- a/docs/implementation/kclaims.html
+++ b/docs/implementation/kclaims.html
@@ -6,7 +6,7 @@
 <div class="nav">(<a href="https://github.com/mlochbaum/BQN">github</a>) / <a href="../index.html">BQN</a> / <a href="index.html">implementation</a></div>
 <h1 id="wild-claims-about-k-performance"><a class="header" href="#wild-claims-about-k-performance">Wild claims about K performance</a></h1>
 <p>Sometimes I see unsourced, unclear, vaguely mystical claims about K being the fastest array language. It happens often enough that I'd like to write a long-form rebuttal to these, and a demand that the people who make these do more to justify them.</p>
-<p>This isn't meant to put down the K language! K is in fact the only APL-family language other than BQN that I would recommend without reservations. Its C-based implementations certainly aren't slow, and choosing an array language based on performance is usually a bad idea anyway. And there's nothing wrong with the K community as a whole. Go to <a href="https://chat.stackexchange.com/rooms/90748/the-k-tree">the k tree</a> and meet them! What I want to fight is the <em>myth</em> of K, which is carried around as much by those who used K once upon a time, and no longer have any connection to it, as by active users.</p>
+<p>This isn't meant to put down the K language! K is in fact the only APL-family language other than BQN that I would recommend without reservations. Its C-based implementations certainly aren't slow, and choosing an array language based on performance is usually a bad idea anyway. And there's nothing wrong with the K community as a whole. Go to <a href="https://chat.stackexchange.com/rooms/90748/the-k-tree">the k tree</a> and meet them! (Since writing, most K conversation has moved to the <a href="../community/forums.html">same chat</a> as BQN; Matrix room is <a href="https://app.element.io/#/room/%23aplfarm-k:matrix.org">#aplfarm-k:matrix.org</a>). What I want to fight is the <em>myth</em> of K, which is carried around as much by those who used K once upon a time, and no longer have any connection to it, as by active users.</p>
 <p>The points I argue here are narrow. To some extent I'm picking out the craziest things said about K to argue against. Please don't assume whoever you're talking to thinks these crazy things about K just because I wrote them here. Or, if they are wrong about these topics, that they're wrong about everything. Performance is a complicated and often counter-intuitive field and it's easy to be misled.</p>
 <p>On that note, it's possible <em>I've</em> made mistakes, such as incorrectly designing or interpreting benchmarks. If you present me with concrete evidence against something I wrote below, I promise I'll revise this page to include it, even if I just have to quote verbatim because I don't understand a word of it.</p>
 <p>This page has now been discussed on <a href="https://news.ycombinator.com/item?id=28365645">Hacker News</a> and <a href="https://lobste.rs/s/d3plgr/wild_claims_about_k_performance">Lobsters</a> (not really the intention… just try not to be <em>too</em> harsh to the next person who says L1 okay?), and I have amended and added information based on comments there and elsewhere.</p>
diff --git a/implementation/kclaims.md b/implementation/kclaims.md
index 19cfee02..8a16a853 100644
--- a/implementation/kclaims.md
+++ b/implementation/kclaims.md
@@ -4,7 +4,7 @@
 
 Sometimes I see unsourced, unclear, vaguely mystical claims about K being the fastest array language. It happens often enough that I'd like to write a long-form rebuttal to these, and a demand that the people who make these do more to justify them.
 
-This isn't meant to put down the K language! K is in fact the only APL-family language other than BQN that I would recommend without reservations. Its C-based implementations certainly aren't slow, and choosing an array language based on performance is usually a bad idea anyway. And there's nothing wrong with the K community as a whole. Go to [the k tree](https://chat.stackexchange.com/rooms/90748/the-k-tree) and meet them! What I want to fight is the *myth* of K, which is carried around as much by those who used K once upon a time, and no longer have any connection to it, as by active users.
+This isn't meant to put down the K language! K is in fact the only APL-family language other than BQN that I would recommend without reservations. Its C-based implementations certainly aren't slow, and choosing an array language based on performance is usually a bad idea anyway. And there's nothing wrong with the K community as a whole. Go to [the k tree](https://chat.stackexchange.com/rooms/90748/the-k-tree) and meet them! (Since writing, most K conversation has moved to the [same chat](../community/forums.md) as BQN; Matrix room is [#aplfarm-k:matrix.org](https://app.element.io/#/room/%23aplfarm-k:matrix.org)). What I want to fight is the *myth* of K, which is carried around as much by those who used K once upon a time, and no longer have any connection to it, as by active users.
 
 The points I argue here are narrow. To some extent I'm picking out the craziest things said about K to argue against. Please don't assume whoever you're talking to thinks these crazy things about K just because I wrote them here. Or, if they are wrong about these topics, that they're wrong about everything. Performance is a complicated and often counter-intuitive field and it's easy to be misled.