Something I learned awhile ago is that most people that I consider "celebrities" really aren't that famous, and as such are generally pretty happy to respond to emails.
In ~2014 I sent an email to Joe Armstrong (one of the creators of Erlang) asking some questions about concurrency because I still didn't fully understand why Erlang was supposed to be better for it. I expected him to just point me to an FAQ or simply not respond [1], but instead he wrote a very long, detailed explanation about the rationale of Erlang's design. It was well-written and it made a lot of things "click" in my brain.
That simple act by Joe was extremely instrumental in my career, I think for the better. I became very interested in Erlang, but also just concurrency theory and distributed systems, and I would like to think I almost understand it now :)
He and I would exchange emails occasionally over the next few years and he seemed genuinely enthusiastic about programming, Erlang, and people using it, and despite me barely knowing the guy, I was genuinely pretty sad when he passed away in 2019.
I think about that a lot; if I hadn't sent a dumb cold email my entire life would likely be very different.
[1] Which, to be clear, would have been perfectly fine!
I can’t speak for other startups, but I applied to the most recent YC batch with my idea for making AI proactive instead of reactive, and pre-being selected I’ve published a paper on recursive self-improvement mapped to the Epoch AI data.
I contacted a professor from a university in the UK and he responded since he was working on similar work, then asked me if I wanted to meet with him. We talked for about an hour since we had overlapping results and different methods, specifically different assumptions.
I say all that to say, as a physics student getting my undergrad, simply doing independent research and speaking to experts about it enabled me to network with someone I otherwise likely wouldn’t know. For young people getting into any business, research is a great way to meet new people.
I had an argument with Steve Jobs about pie menus at the Educom conference in Washington DC, October 26 1988 -- right after he finally shipped NeXTSTEP (people had been teasing it as vaporware with "NeVRSTEP" t-shirts).
I was demonstrating the work I'd done at the UMD Human Computer Interaction Lab on a color Sun 3/60 that Sun lent me to use at their booth, which happened to be right across from the NeXT booth.
Ben Shneiderman dragged Steve Jobs over to the Sun booth, and I gave him a NeWS demo for about half an hour: HyperTIES, UniPress Emacs, pie menus, PostScript windows in arbitrary shapes — the Hubble Space Telescope in orbit, Bill Joy's head popping up when you pointed at it, that kind of thing. Jobs has RELIGION about UI, and he argued wonderfully. He also has volume. On the show floor, in a suit and tie, he was jumping up and down yelling:
"That sucks! That sucks! Wow, that's neat! That sucks!"
Not discouraged, I figured one neat to three sucks was a good score from Steve Jobs. When I explained how flexible NeWS was -- programmable PostScript in the window system, malleable windows, extensible UI, transforming all menus of all apps into pie menus, etc -- he told me:
"I don't need flexibility -- I got my window system right the first time!"
Okay, agree to disagree. Then I gave him a free NeWS "NeRD" button, which he gracefully accepted, then he departed leaving my reality intact and undistorted.
So empthought's joke isn't far from the design philosophy. NeXT was world-class software, but malleability for the user was exactly what Jobs was proud of not offering. That's a big part of why the Emacs / NeWS / PostScript / Smalltalk / Self / Oberon / JavaScript / AJAX branch of computing and the Mac / NeXT / Display PostScript / Objective C / Cocoa branch diverged.
Also, during the conference I was giving essentially the same rolling demos to anyone who walked by, and some scruffy looking dude was hanging out and watched the whole series until it looped back to Emacs, then he finally remarked "I used to use EMACS on ITS." (i.e. the original TECO version)
...I said "Wow, what was your user name? Mine was A2DEH@AI!" and he replied "WNJ".
Only then did I realize I had been giving demos to Bill Joy, the author of VI, of UniPress Emacs for NeWS, and of HyperTIES embedded graphical pop-up links demo with his own inflatable pop-up head. I didn't recognize him because he'd shaved his beard!
When I was in grad school, I had the opportunity to take a course from my adviser in which he discussed his current research and some open questions. It was a relatively accessible subject area and the questions were sometimes easy enough that we could meaningfully contribute.
On one particular Friday afternoon, he stated a conjecture that he hoped was true, and invited us to try to help him prove or disprove it. It was the sort of thing that he really wanted to be true; he liked things smooth and beautiful. I, on the other hand, hoped it was false as I like the weird and exceptional in mathematics. It was also the case that I had absolutely no command of the sort of machinery that one would use to prove such a thing, but I could certainly look for a counterexample.
I learned on Monday that he had spent the entire weekend trying and failing to prove it. I, on the other hand, had put all my energy into finding a counterexample and had one within an hour.
My single (quite small) contribution to mathematical research was a counterexample because it was all I could do. The story does illustrate that it can be helpful to have people with different tools, hopes, and motivations working on a problem, though. I was not, and will never be, even a shadow of that great mathematiciam I studied under, but on that occasion, I had reason to look in a different direction than he did.
Interestingly, Yitang Zhang of the twin-prime-conjecture fame spent 7 years working on the Jacobian conjecture under the advisor Tzuong-Tsieng Moh at Purdue. A key step in his thesis used a corollary of Moh's. It turned out that the corollary was incorrect. As a result, Moh refused to write any recommendation letter for Zhang, and Zhang couldn't find any teaching or research job and ended up spending years working at a Subway[1].
Imagine Zhag had ChatGPT in 1986 when he started working on the Jacobian Conjecture.
[1] Of course now this has become an inspiring story. That said, the story definitely invokes complex emotions. The best way to describe it is probably this Chinese poem, which I have no idea how to translate: 庾信平生最萧瑟，暮年诗赋动江关
If you lay a yardstick from fully desaturated white to maximum perceivable green, you’re effectively seeing #119911 even if you’re looking at a green quantum dot #00ff00 LED, because the color green can also be seen by your eye’s non-green receptors a little bit too.
The green in ProPhoto RGB is shown at a ‘distance’ from the other colors that’s impossible for human photoreceptors to perceive (let’s say it’s #00bb00), because there’s no way to trigger our green receptors at such a severe distance from white — they can’t differentiate greens beyond #009900 — without our perception also mixing in some of the other colors (result: #119911) due to those receptors being analog-curve-blended rather than sharp single-frequency cutouts like quantum dot, sodium lights, or laser emission spectra. So no matter how strong a green you emit in reality, it can never reach when perceived the depth of green that ProPhoto RGB represents, because the eye can’t perceive #00bb00 green as being different from #009900 green, and it can’t perceive any intensity of green as #00gg00 rather than #11gg11 without optical illusions or other fun tricks like shooting your green ‘M’ receptors with pinpoint laser beams: https://news.ycombinator.com/item?id=43741013
So, the upside of having three overlapping curves is that we can distinguish different shades of similar colors with much higher accuracy, but the downside is that we cannot see undiluted green or blue. Human tetrachromats, theorized to have a fourth receptor at +/-yellow, would in theory be able to differentiate colors even more strongly, peaking at that +/-yellow versus red/green; but, perhaps, they might(?) lose a bit of the ‘imaginary’ three neon CMY colors that we synthesize from that overlap (for example #ffff00), in exchange for gaining six? new ones (#00ff00ff?). I need to consider 4-D rhodopsin interactions for longer than this comment’s edit window to be more certain of that implication :)
DxO created a wide color space a while back that they fit better to human receptor sensitivity than ProPhoto, and while I’m not qualified to judge whether it’s Better or Worse, their explanation of how they constructed it around Pointer’s Gamut — someone sampled actual real world objects to see what the strongest colors we can see in earthly reality are! — provides some very precise images showing ‘the strongest color distances we can find from white on real life objects’ versus ‘the strongest color distances from white that sRGB and ProPhoto RGB can represent’:
This post also does help explain in depth why having ‘impossible’ color spaces is helpful for digital processing: It lets you manipulate photos without color truncation (do your intermediate math in double-float), and then when you’re ready to ‘land’ the photo back into reality — either on sRGB, or Dosplay P3, or HDR10, or Kodak film negatives — you can control how that inevitable rounding-off of the impossible colors occurs (store the final result in half-float). Do you want to prioritize eye-searing color or preserve the fine gradients of hue, in your photo of a flower petal? There is no single correct answer, but if you do your work in ProPhoto, you’ll have the option to preserve those gradients (or to convert them to luminosity gradients!) that you would lose if you’d done your work in a more limited colorspace.
Hex code nitpicks: Colorspace pros, I acknowledge that RGB hex codes are wildly incorrect to use here, not the least of which because they encode luminosity and hue when I’m just using them as hue above, but also because they’re wildly incorrect to mix with modern color spaces. This is done solely for analogy purposes and supports the curiosity basis of colorspaces 101; those who wish to learn more are welcome to — and join us in being grumpy about web hex codes and colorspaces :D
There is the famous case of dropping the NOAA N-Prime weather satellite on the ground. They were trying to turn it from vertical to horizontal and they forgot to bolt it to the adapter. Worse: multiple people signed the paperwork attesting that they verified that it was bolted down correctly. Pictures and details here: https://spaceflightnow.com/news/n0410/04noaanreport/
Or the famous “space aligator” event. There the original plan was to launch a manned space craft and an unmanned module to do a docking test between them. But the shroud protecting the target module didn’t deploy properly. If i remember it right because the man who usually assembled that part had to leave during assembly because his wife was giving birth. Someone put it together but appearantely not correctly. The half opened shroud reminded the astronauts to the jaws of an angry aligator hence the name. Pictures: https://www.nasa.gov/missions/gemini/gemini-ix/gemini-ix-cre...
Or to not only list American failures: this russian satelite launch failed spectacularly because the IMU was installed upside down. https://youtu.be/ycRVAcZC5R4?si=LRTS7sutKSp6HnGs This was designed to be impossible to do, but someone bent and forced the component to stay in place in the wrong orientation. Then someone else whose job was to check it just signed the paperwork without climbing into the location where he could have checked it.
I love these cases. Because it shows to me how even though the trappings of high-tech we are all fundamentally just occasionally lazy, occasionally distracted monkeys banging rocks together.
Hi, I'm Robert Standefer, the guy who made this happen, with lots of support. I'm excited to see the enthusiasm about Comic Chat being open sourced. How this came to happen is a very interesting story that spans a six-year period with success that hinged upon being in the right place at the right time, literally.
I want to point out that, while I (along with Scott Hanselman) made the Comic Chat open source release happen, I am not the original developer. That is DJ Kurlander, and he was very supportive of this project. He was even enthusiastic about it.
I worked on the ARPANET project under Steve Crocker at UCLA and met his bud Vint there (with his ever-present 3 piece suit, briefcase, and hearing aids) ... what a great guy.
An anecdote: I wrote a program (in Sigma-7 assembler I think) to play Jotto--a bit like Mastermind but with 5 letter words. Vint loved to poke around in people's directories to see what they were up to and found my program. He played it a few times, and then collared me to ask me a couple of questions: 1) It seemed to know some of the words he entered but not all -- what was up with that? 2) What sort of AI algorithm was I using for the program to make guesses? (It usually beat the human player.)
Answers: 1) I didn't have a digitized dictionary (it was 1969!) so I hand-entered the five letter words from a pocket dictionary but got tired halfway through so it only knew words starting with a-l. 2) The program would eliminate any words that didn't fit the responses to its guesses so far and then pick a remaining word at random.
Upon hearing my answers Vint walked away in disgust! But years later he gave me a recommendation when I interviewed with Google (it didn't work out for other reasons).
I also shared a cubicle wall with another Van Nuys High alumni, Jon Postel, aka "God of the Internet". Sartorially, Jon was the complete opposite of Vint--long scraggly beard, blue jeans, forever barefoot--but those weren't the things that mattered. Man, those were the days.
I interviewed him a few times, when I was a tech journalist in the 90s - a very impressive man.
However I never forget my surprise, Idly flicking through TV one evening and coming across Earth Final Conflict - and there was Vint in a fairly substantial role
You may be relived to know that Unix epoch time does not have this problem. But you may also be horrified to know why.
First, epoch seconds are not the numbers of seconds since 1970/01/01. This is a lie we tell to children. Rather, epoch seconds are the number of days since 1970/01/01 * 86400 plus the number of seconds since midnight.
Leap seconds, to epoch time, don't exist. Or maybe they are double counted. Or maybe we smear them over 12 or 24 hours (but which 12 or 24 hours depends on whether you are Google, Microsoft, or Oracle; I can't even make this stuff up). The point is, it's not defined, and this means implementations do it differently.
A negative leap second might be easier though. The spec suggests (though lack of speaking) that a correct implementation will just skip it since number of seconds stays less than 86400 for that day. But of course the smear-organizations still smear it.
So what if you really want to know how many seconds were between two different epochs? Subtracting epoch seconds is wrong because you need to correct for the number of leap seconds between the two times.
I grew up on a farm on which the apiary and all connected with it was a major part of the farm's output. Honey, beeswax, nukes (a queen and 10K or so worker bees as a starter colony, sold to other apiaries in the spring if they'd had too many winter losses), fertilizing services (drop a couple colonies off at a berry farm after dark, pick the colonies up two weeks later, profit!) and other products.
It's been over ten years since I spent any serious time with bees, but the bees themselves did a great job on the varroa mites. Sentinel bees at the hive entrance would pick the mites off the incoming bees. The problem was if the colony had a solid floor the mites would just climb back onto the next bee that passed nearby. If the solid colony floor was replaced with a mesh, the mites would fall through to the ground below while the bees could still go about their business.
We would still sometimes treat for varroa, but making it easier for the bees to handle varroa how they had evolved to was the first line of defence.
This was Canada, regular Italian bees, hard winter kills of whatever wasn't properly winterized.
The cartridge heads have a super curious digital protocol - the cartridge electronics have no power supply. There is no power rail internally either.
Instead they use the fact mosfet gates have capacitance, and can therefore store 1 'bit' of information. Through a network of hundreds of MOSFETs, the right bits can be put on all the nozzle gates as needed, and then a 'fire' pulse is sent which for around a microsecond turns on a tiny heater (or not, depending on mosfet gate state). The heater boils some ink, making a pressure wave which travels down a pipe and makes a drop of ink fly out towards the paper. That heating and cooling again can happen around 10,000 times per second per nozzle (and there are ~300 nozzles).
I suspect this decision is because the custom silicon process needed to manufacture these nozzles is cheaper if they only have n type MOSFETs - and without p type MOSFETs you can't make a typical push pull logic gate.
The nozzles themselves are quite a lot of silicon - perhaps 100mm^2, with deep etched holes, and are effectively disposable, so I assume huge efforts have been taken to reduce costs - including this curious electrical design.
The protocol also is hugely irregular, which I suspect might be to avoid any wires on the chip needing to cross eachother.
I'm not a handgun expert at all but I've caught a few of these, like the guy who racked the slide on his revolver. The author who really impressed me, although not with his handgun knowledge, was Tom Clancy. I was in the anti-submarine warfare business in the 1970s and some of what he wrote in Red October I only knew from classified sources.
I built one of the connected tools included in this launch (the Biomni HPC [1]), and I have spent an inordinate amount of my life working on this problem. (I also worked at Anthropic, but not on this product.)
As other comments have pointed out, this is for data science – but it's capable of more than making plots and writing papers [2]. It has integrations with many databases and computational tools, including a researcher's institutional cluster.
That alone is valuable. I founded a startup after struggling with this problem at a bio startup; integrating these tools and databases is hard and time consuming. If the only outcome of this product is that great APIs are built for LLMs, it will be a massive positive impact. Many databases used in computational genomics are still only accessible through FTP!
LLMs are particularly good at navigating these tools and databases. It's often very specialized, but straightforward, work that benefits from in-context skills. Seeing an early glimpse of my former customers – bioinformaticians – using LLMs to solve this problem is what led me to join Anthropic in 2024.
Also, this pattern isn't fundamentally constrained to data science: you can also integrate with a wet lab or a CRO for some kinds of science. This is what I'm spending my time on now.
This type of science doesn't solve everything, but it's useful in some niches. For example, progress on many rare diseases is bottlenecked by researcher attention rather than a fundamental breakthrough.
I know less about the airframe differences across the -400 and -8, but I can say the 747-8 represented a major upgrade in Flight Management Software.
I re-wrote the Central Maintenance System (portion inside the FMS) in C from scratch because no one had the original detailed design documents. The original -400 code was written in Pascal if I'm remembering correctly. I gleamed what I could from the source and relied on unit tests to get the rest of the way there based on what I knew of the protocol itself.
The entire FMS software was completely re-written in C++ and using modern object oriented patterns (at the time). Probably the most fun I've had over my now 20'ish year career. Of course Boeing was pissed with the delays this caused because the airframe wasn't a major change. I'll quote a Boeing (from MD originally) executive as saying "Meeting this project deadline is more important than your child dying."
Sadly this was also the time I remember Boeing's engineering ranks began to thin out. Personal opinion, this was a large part of what led to the MAX situation.
About 11 years ago, I cold-emailed Om for his guidance. I was an absolute nobody, living thousands of miles away. Not only did Om patiently explain how I should think about my career, he kept in touch over the past decade checking in on how I was doing. I left journalism last year to do something else -- coincidentally, again, following Om's footsteps -- and had been meaning to write a long email, sharing so much. I deeply regret missing the chance to have another conversation with him.
Om has been deeply impactful to my journalism career and beyond. He was way too kind and leaves a big vacuum.
I used to work at two (UK) telcos. There's a historic reason and a modern reason.
The historic reason was, just like the Internet, the international phone network was built on gentlemen agreements by engineers who largely trusted each other.
A big national telco is unlikely to attack its peers, so there was little need for safety measures. As smaller telcos came in to the mix via deregulation, that understanding changed - but it was hard to retroactively fit controls.
The more modern reason is outsourced call centres. You want outbound calls from your Philippines based staff to show as if they were calling from a local number. When large and reputable entities were doing this it was fine. Just like showing a different reply-to address on an email.
If you were designing a modern network, it wouldn't be like this. But international telephony is over a hundred years old and has a huge amount of legacy technology and legal agreements.
When I was in highschool I started writing a game in Qbasic. Along the way, I wanted it to have a console (like Quake) where you could enter commands and modify the game as you were running it. This lead me to create a scripting engine in Qbasic, and long story short, I’ve been on a yak shaving epic quest now for almost 30 years now. No game, but I have a hybrid C / Lua game engine/general purpose application platform. Still tinkering and still no end in sight. I’m having fun though!
I had to take down two absolutely enormous Douglas Fir trees on my property (> 36" base), and asked them to leave the wood rounds for me. I knew it was going to be a lot of wood, but even then, I was not prepared. I spent about a fair bit of my free time over the next 1-2 months just out there slowly working my way through the pile, and you're absolutely right - you get substantially better at it. For me, it looked something like this:
Stage 1: At first, I could chop essentially nothing, probably 60+ minutes per round as I mostly puzzled about how to make progress and got lucky from time to time with a round that split easily (fortunately, I had a nice splitting axe)
Stage 2: Then I bought some splitting wedges, and I used a handheld sledgehammer to drive them in to what I thought were the weak spots, and then ultimately pried open the log, to pieces that I could split more readily.
Stage 3: I bought a massive demolition sledge hammer (essentially a two-handed battle hammer) and used that to drive the wedges in after getting them started, and made a bit more progress on actually splitting the rounds.
Stage 4: After doing this countless times, you just a knack for reading the wood, and where it will / won't split. I reverted back to using just the splitting axe, since if you hit the wood in the right spots, it really just splits on its own.
Here's where I ended up, if it helps any of you:
- Start by establishing the fracture line that will be used to split the round in half. I would eyeball any existing line on the round towards the center, and use the axe head to mark a line, away from any knots , from the center to the edge. These two center-to-edge didn't necessarily need to be inline. They could be slightly offset, like hands on a clock.
- With moderate force, just repeatedly strike that line, working from the center outwards. You'd be shocked out how quickly repeated strikes widen the line, and eventually the wood's own weight almost causes it to fall apart.
- Recursively do this with the two halves: Draw the line from (what was the center), radially out to the edge. Repeatedly strike until these pieces have been halved.
- Continue this process until you have proper pizza wedges. At this point, it's pretty trivial to just chop the pizza wedge, from the wedge to the base, into 4 or 5 smaller firewood-sized logs.
I know y'all probably didn't care to read this, but this was quite honestly weeks of my life in learning this, and I couldn't find a great guide on YouTube or anything, especially for rounds this big.
Back in 1984, I wrote the original "obvious password detector".[1]
It just checks whether a password has English language trigram stats. This prevents dictionary attacks.
- 3000 rubrics on code quality. First benchmark to measure: "would this code get actually merged?"
- 20+ expert open-source maintainer created tasks on their own repos to capture their opinion & taste.
- total 1000+ hours of real life software maintainer work captured in dataset. ON TOP of that, 40+ hours of real human work to turn that real life work into well validated and structured tasks with rubrics (even more work to turn tasks/prompts from devin-infra-specific to pluggable coding agent)
- results in 81% lower false positive rate than SWE-Bench Pro
- High quality bar: many QA stages & each task manually reviewed by Cognition researchers (examples in post)
Opus 4.8 scores 13% on FrontierCode Diamond.
one of my goals was also to datamine interesting stuff even on the easy tasks. for example, if you squint you can see the answer to "WTF Happened in late 2025" with coding models: https://x.com/swyx/status/2064081945567580323
This never made it into prod since the scale was small, but one of the favorite leaks I found when working on bot detection was browsers which generated the same random numbers. Presumably because they were being init to the same VM snapshot and therefore the same random number state.
Optical engineer here. This is what they don't tell you about continuous/transition/progressive bifocals: optically they don't work. The lens design is an overconstrained optimization problem and the solutions they come up with end up compromising a lot on everything, to the point that it is practically useless.
I helped train some of the first "magic" models at OpenAI[1] and it was a wild ride. We were a pretty sane + skeptical team and we weren't totally convinced the models were as general as they seemed, but the query that convinced me (and later got included in the paper[2]) was "Why is it important to eat socks after meditating?" (something that almost certainly did not appear on the internet before).
An interesting follow up would be when did you realize GenAI wasn't as good as you thought in that "oh shit" moment
Related story, while applying a firmware update to my Kawai CA49 piano, I bricked it due to flashing the wrong file (The process was broken, and I got desperate and tried something stupid, which bricked the piano). Claude walked me through looking for signs of life, and since OTA from the phone app wasn't working for me, it downloaded the Kawai Android APK, decompiled the Java, figured out the hardcoded key used for encrypting the firmware update. Extracted the piano firmware update, decrypted it, and then wrote a flashing script to program the piano from my laptop via bluetooth. My piano was back to working within an hour.
As with all things, the horror stories just get the most attention. People love to rage. There are plenty of boring (good, even!) VCs out there. They just work more quietly, professionally.
I'll share a story, but its about a close friend and not me so I won't name any explicit actors and I'm going to round out the numbers. You either trust me or you don't, but this is a very direct relationship I have to both the founder and VC.
The story is this: the founder started their company outside of SV, so the lawyers weren't super familiar with startups and messed up the initial incorporation and stock plan stuff (actually super common: use Stripe Atlas or pay a startup-aware lawyer!). Went under the radar through years. This company ended up being bought for nearly $1B (with a B) after many rounds and a large board.
During the legal work to close the acquisition, they found out this messed up stock plan. Without going into the details, the effect was that instead of taking home $200M, the founder would take home ~$75M. The mistake the lawyer made almost a decade earlier was about to cost him $125M.
Most of the board basically said "too bad so sad, law is law." But one VC (the one I know, the one I'm talking about) basically strong armed and politicked the whole thing and eventually convinced everyone around the table to give up an equal share of their own holdings to make the founder whole.
Letter to the law: they didn't have to.
Spirit of being founder friendly: this VC went to bat hard and got everyone to yield to make things "right."
Also, look, you might argue $75M vs $200M is just "rich vs rich." Who cares? Sure. That's not the point.
You don't hear about stuff like this because honestly its not a big enough deal and feel good stories get way less clicks than pitchfork stories.
There is a fundamental minimum amount of energy needed to desalinate: you can't take less energy to do it,than you could gain back (from osmotic pressure) if you allowed the desalinated water to expand a cylinder containing the residual brine. This is large. This paper is a thermal method, so it doesn't have an electricity input, but to justify their efficiency claim, they should really compare against what you could do by using the same surface area for solar panels, driving a conventional setup. My (limited) understanding is that conventional reverse osmosis is not far from the theoretical optimum, energy-wise, the main difficulties being operational (the membranes need declogging). And of course RO is more expensive than rain.
This paper is interesting, however, in directly producing crystalline salt, which is lower volume than brine and easier to dispose of, maybe even valuable.
There was a FidoNet clone in Turkey called HitNet (short for “Hi Türkiye Net”). Its node addresses were like “8:103/119”.
İ developed a Netmail server for Hitnet called HitBase in 1995 or so. It allowed people to discover others around their city to meet. Possibly the earliest thing that resembles Facebook. Similarly, it was a privacy nightmare too, luckily short-lived.
HitNet introduced me to great people some of whom I still see today. It was such a tight-knit friendly community.
The advent of Internet killed it but some communities are still active on other platforms.
In ~2014 I sent an email to Joe Armstrong (one of the creators of Erlang) asking some questions about concurrency because I still didn't fully understand why Erlang was supposed to be better for it. I expected him to just point me to an FAQ or simply not respond [1], but instead he wrote a very long, detailed explanation about the rationale of Erlang's design. It was well-written and it made a lot of things "click" in my brain.
That simple act by Joe was extremely instrumental in my career, I think for the better. I became very interested in Erlang, but also just concurrency theory and distributed systems, and I would like to think I almost understand it now :)
He and I would exchange emails occasionally over the next few years and he seemed genuinely enthusiastic about programming, Erlang, and people using it, and despite me barely knowing the guy, I was genuinely pretty sad when he passed away in 2019.
I think about that a lot; if I hadn't sent a dumb cold email my entire life would likely be very different.
[1] Which, to be clear, would have been perfectly fine!