antics

One of the things I like about this paper is the pristine, crystal-clear English it uses to describe things I thought I knew extremely well:

> Processes are the software analog of processors. They are the units of software modularity, service, failure and repair. The operating system kernel running in each processor provides multiple processes, each with a one gigabyte virtual address space. Processes in a processor may share memory, but for fault containment, and to allow processes to migrate to other processors for load balancing, sharing of data among processes is frowned upon. Rather, processes communicate via messages. They only share code segments.

"Processes are the software analog of processors." Yes of course. How easy it is to never ponder such a thing.

There is one other way in which you are not a failure, and I am sure that I am not alone in thinking about it: I have been reading your words for 15 years, from the time I was a baby CS major. That's really true, e.g., here[1] is a comment from 11 years ago where I mentioned that a lisp you wrote for the Apple //e informed a lisp for the Apple //e that I wrote.

Especially in my college years (2009-2013, ish), the world seemed smaller, and to me, a lot of what you wrote was like looking through a keyhole into the real world. Grown-ups can apparently write lisp at JPL[2]! Google was chaotic[3][4][5][6] to work in 2000, especially if you commuted from Burbank. A name change[7]. And, variously, surveillance, more lisp stuff, etc. Now I'm an adult and I still haven't professionally written lisp, but I'm glad to have read about it anyway.

Anyway, it might surprise you to learn that when I think of your writing, though, I think of your HN comments first. There is a kind of influence that you can only get with a steady, unthanked build-up of seemingly-small contributions over a long period of time. In the right place they compound. I probably cite you to other engineers once a month or so.

[1]: https://news.ycombinator.com/item?id=6199857#6200414 [2]: https://flownet.com/gat/jpl-lisp.html [3]: https://web.archive.org/web/20080212170839/https://xooglers.... [4]: https://web.archive.org/web/20090408003924/http://xooglers.b... [5]: https://web.archive.org/web/20090408013612/http://xooglers.b... [6]: https://web.archive.org/web/20090408003913/http://xooglers.b... [7]: https://flownet.com/ron/eg-rg-faq.html

Ok, let's try from another angle. Close your eyes and picture the ideal, best, most successful product in this space, for whatever definitions those words mean to you.

Everyone is different, but I think most people would not picture a source control product where search, issues, and on-prem are each so terrible, the default solution for that feature is to use a completely different product from a totally different company, which solves that specific issue (Sourcegraph, Linear, GitLab, respectively).

Sorry if this was not clear, but I am not making a normative statement that each feature should be broken out into its own tool. I'm saying that the revenue ramp on each these products is, empirically, good enough to be on track to IPO. So GitHub is apparently doing a bad enough job in each of those areas that three separate companies were able to break a feature out into a dedicated product, sell it on its own, and ramp revenue fast enough to support a venture class business. Absolutely wild stuff.

Sorry, the goal here is not to trivialize GitHub, or suggest they suck at engineering, or even to say this is easy. I am just saying my own perspective, which is that I wish the core properties (pull requests, issues) had improved a long time ago. I have been a maintainer of a top 0.01% project, and I have seen it get in the way where other tools would have been tolerable. It hasn't always been easy to be a fan.

Yes this is one of the reasons this discussion is so tricky. I just believe that if I maintain a popular project on GitHub I should not be automatically consigned to worst-in-class experiences for Issues and code review. I understand this is mildly controversial but I have had maintainer status on a few top 0.01% GitHub repositories and I have seen tools that do not suck, and so my opinion is that a better world is possible.

Again, I say all of this entirely with love. I love GitHub. I have used GitHub since I started programming. I want them to win.

I think of GitHub as a sad story. There are probably going to be at least 3 public companies that should have "just" been GitHub features: GitLab (GitHub Enterprise), Sourcegraph (search), and Linear (GitHub Issues). There are dozens of upstarts "unbundling" features of GitHub that are genuinely useful, but which are under-loved and under-invested in, and surely some of those will become successful too. It feels like GitHub continuously invents the future, and then waits for someone else to make it truly great.

It is so painful to watch because I love GitHub so much. I graduated college in 2013, which means I started programming right when they got started. I read their dev blog every single day, eagerly waiting for new features (which were released every couple days). I watched their team page grow, I looked carefully at what they did to deserve a spot at such a cool company. I scoured the projects they contributed back to for hints about what good code looked like (my favorite was Vicent Martí's contributions to libgit2). I eagerly taught my friends how to use git because university taught subversion. I wrote my own Rails tutorials as a way to learn the magic.

But it's been years now, and it's not an easy love. It's work! It's so painful to watch it get continuously lapped by upstarts. I always just thought the core offerings (Pull Requests and Issues) would get better eventually. And now, 14 years later, they finally are. But very slowly. I really want to believe, but after 16 years, it is starting to sink in that GitHub might just be a place to store files.

The magic is still in there. I think there are lots of people like me, who want to believe. But it will take real agency to do it, and that's really hard to muster at this stage in a company's life.

One of my formative experiences as a freshman in CS (I learned to program in college) was accidentally opening a PDF with Emacs and watching as it displayed not weird binary data but a real, rendered PDF. I wondered what else it was doing behind my back that I didn't know about.

Sadly, I was not able to run Doom in a PDF, in Emacs. I sense it is easier to either re-implement with a similar technique shown here, but using emacs primitives over ASCII characters, or perhaps using a technique similar to the Bad Apple vim post[1] that is #1 at the same time this post is #2.

[1]: https://news.ycombinator.com/item?id=42674116

I’m happy to continue this conversation, but I think we’re not on the same page about what I am saying, which makes it hard to say how to proceed. To your specific point here, I’m not sure what this has to do with the discussion.

Oh I think we have very good empirical reasons to believe that’s not true. If this was indeed common knowledge, DEI as a movement would not be mired with the issues it has, specifically relating to performative activism and focus. If that’s not good enough for you, we can evaluate your claim further by surveying people and seeing if this advice is actually well-known. I encourage you to try this yourself, I think what you’ll find is that the vast majority of people who participate in these systems find what I’ve written surprising and unintuitive. And that’s one reason why this comment has 250 upvotes, which is more than almost all HN stories on a given day. YMMV, happy to hear about how this turns out for you.

The qualitative description here is pretty interesting, but so is the quantitative one here[1]. 1,600 ft tall, 220 mph top speed, inflicting 10 Gs for roughly 60 seconds, which induces cerebral hypoxia in the brain, causing death.

Seems like the drop is entirely unnecessary and mainly gamifies it, since the user has to press the button. You could easily just have an Incredicoaster-style magnetic propulsion system that takes you to 220 mph, producing the same effect without the distress. Other than the drop, losing consciousness in this way is relatively pleasant as a way to go (I know because it has happened to me).

[1]: https://www.wired.com/story/human-plus-science-gallery/

Thank you for the response, I am very glad to hear that came through. I think these discussions tend to be fundamentally pessimistic towards the future and I really don't think they need to be. We control our destiny, and we can make it whatever we wish.

To be clear I am not arguing for or against working with a bunch of people from totally different backgrounds, demographics, etc. I am arguing that, because we can't do everything we should decide what really matters to us, commit to it in the long term, and invest in it to the exclusion of the many other completely worthy causes. I know it sounds obvious, but at least for the communities I belong to, the industry committed shallowly and as a result accomplished very little.

I totally get it. A lot of our wounds are still open, too. I'm not here to tell people how to feel, I'm just advocating for deciding what is actually important to you and focusing all your attention on it until it is resolved. I happen to think that citizens of the US are worth more to each other as sometimes-conflicting allies than as complete adversaries, but that is for everyone to decide on their own.

Well, just one data point for you (YMMV), but in "DEI" contexts I've been a part of, class diversity did actually come up somewhat regularly. I would not say corp diversity efforts I saw were all that successful in staffing that demographic—but they also weren't that successful in staffing minorities either. Mostly I think this reflects a consistent disconnect between what people wanted corp diversity efforts to be, and what they really were.

With all that said I do have a story of my own like this. In 2013 or so I wrote some stuff about spam detection and a Twitter engineer reached out about a job. I was an outgoing new grad from the University of Utah. When I got through with the loop the recruiter said, "How did you get here, we don't get many candidates from Utah." I still wonder what they wanted me to think when I heard that. What I actually felt was deeply out of place and uncomfortable. And it has affected every hiring process I've been apart of since.

Unfortunately, our reservation is in central Oregon, which is less desirable. Even if we were not forced out of the ancestral homeland (what is now called the Columbia River Gorge), I'm not sure that would have been better. Although pretty, it is very out of the way, and people do not know that it is in the same class as the Yangtze (say).

In our area, it is mostly resorts and casinos. Economic development gives everyone in the area jobs and opportunities. This has changed the picture from "Indians begging the Bureau of Indian Affairs (BIA) and local government for resources" to "we have a robust economic engine which is a critical part of the greater surrounding community, and which we'd mostly all like to succeed, but need to work through details on." It's not perfect and there's still conflict but it's much easier to work together in the latter situation.

Great questions. The kids mostly speak English as first language, and the schools are in English. With the exception of one huge twist, the schools have many educational difficulties you'll find in rural America generally—it's hard to get money for materials and curriculum, hard to recruit good teachers, hard to get students connected to people with practical advice/guidance, hard to get connected to opportunities, hard to reach escape velocity, and so on.

So, what's the twist? Tribal schools tend to be administrated by the federal government which makes problems extremely slow and hard to address. With some asterisks, the local elementary school was basically provisioned as a consequence of a federal treaty with the US Senate, and is/was mostly administered by a the Bureau of Indian Affairs (BIA), which rolls up into a federal department that until 2020ish, had never been run by a native person. All of these things make it very tricky to work with.

In spite of that, believe it or not, this is a massive improvement: until relatively recently, the school was a mandatory boarding trade school meant to teach kids to be (basically) English-only maids. This lead to a substantial percentage of the population being either illiterate or semi-literate, with no meaningful work experience, and with very very few opportunities that were not menial work. That inertia is extremely challenging to overcome, and the most natural place to try is the education system, which generally is simply not up to it.

I am stating these as a neutral facts on purpose. Regardless of how we got here, the hand is ours to play. Some of us got out and whether we succeed in the next generation depends on whether we can mobilize the community to productively take advantage of the resources we do have. This is why it's painful to me to hear about, e.g., land acknowledgements. If you have seen this pain firsthand I just do not see how that can be the #1 policy objective.

I am Wasq'u (a tribe in the PNW), I am connected to my tribe, and I am one of a handful of remaining speakers of the language. I am really tired of being caught in the maw of people fighting about my identity, what I am owed, and to some extent what place my identity has in society.

To the pro-DEI crowd: I have some hard truths for you. Actual change requires commitment and focus over an extremely long period of time. That means you have to choose probably 1 cause among the many worthy causes, and then invest in it instead of the others. You can't do everything. The problems that afflict my community are running water, drug addiction, lack of educational resources, and secular trends have have made our traditional industries obsolete. I am not saying that land acknowledgements and sports teams changing their names from racial slurs are negative developments, but these things are not even in my list of top 100 things to get done.

We all want to help, but to have an impact you must have courage to say no to the vast majority of social issues you could care about, and then commit deeply to the ones you decide to work on. Do not be a tourist. I don't expect everyone to get involved in Indian affairs, but I do expect you to be honest with me about whether you really care. Don't play house or go through motions to make yourself feel better.

When you do commit to some issue, understand that the biggest contributions you can make are virtually always not be marketable or popular—if they are, you take that as a sign that you need to evaluate whether they really are impactful. Have the courage to make an assessment about what will actually have an impact on the things you care about, and then follow through with them.

To the anti-DEI crowd: focus on what you can build together instead of fighting on ideological lines. The way out for many minority communities in America is substantial economic development. In my own communities, I have seen economic development that has given people the ability to own their own destiny. It has changed the conversation from a zero sum game to one where shared interests makes compromise possible. If you want to succeed you need to understand that your fate is shared with those around you. In-fighting between us is going to make us less competitive on the world stage, which hurts all of us.

Yes, for better or for worse, I think the ethos of Go is pretty much "a mulligan on C". Every C project re-implements a bespoke hash table, struggles with Unicode strings, spends a lot of time on memory management, gets tripped up on dynamic linking, and so on. If otherwise like C but are tired of those things, guess which language is perfect for you?

One big flaw in Go-style `defer` is that error handling and scoping are an afterthought, and it's disappointing to see this is not improved upon in this proposal (at least as I understand the proposal).

I do think this matters in practice. If I have a `func whatever() error` IME it's a common to accidentally do something like `defer whatever()` without catching handling the error. To work around that you'd need to do something like the following.

    var err error
    defer func() {
        err = whatever()
    }

For me personally: ugh. I understand the "received wisdom" is to just structure your code differently. I don't think that's reasonable, because cleanup code is often complicated, often can fail, and is generally vastly less well-tested/exercised. YMMV, my experience is that, because of these things, the dispose-path bugs tend to be disproportionately bad. Error handling facilities that treat the dispose path as by-default not worth insuring are IMO setting users up to have a very bad time later.

While we're fixing up the error handling, I really think it's not an accident that "`defer` in a loop does not terminate in the loop, but at the end of the function" is such a frequent misunderstanding. Yes the docs are clear, but all languages spend a lot of time training you on lexical scoping, and lexically-defined disposal lifetimes (e.g., C#'s `using` or Python's `with`) are a natural extension of that training. Those implementations to varying degrees have the same error handling problem, but with some effort I really think a better world is possible, and I don't think we have to expand this to full-on RAII to provide such semantics.

Ok, well, I guess we're not going to get a proper retrospective for any of the OpenAI stuff for awhile. That's too bad. In the spirit of the post I wish Sam had written, I'll say one thing I learned from watching the show: if you take advice even from your own board, and what they suggested fails, they will still fire you even though it was their advice. So you might as well just always do what you think is right.

This applies to other leadership roles as well.

Since no one seems to be pushing back I'll add my 2¢ here as a former compilers engineer. Calling conventions are just like any other style guide. Yes, any particular coding style is stupid, but it's still useful to have one that you are more or less committed to, especially if everyone else in the ecosystem is committed to it too.

Frame pointers are a great example. Having a well-known and generic representation of %rbp is helpful when you go to use or integrate with existing tools like debuggers, link editors, or (say) most of the existing LLVM/GCC/whatever toolchain. Or when you want to expose a stable ABI to consumers for whatever reason (as, e.g., the Linux kernel famously does). Or, or, or.

I think it's reasonable to say this has been mostly uncontroversial since at least the 90s. The discussion has changed a bit since (apparently) Go needed none of these things to succeed—not the LLVM compiler toolchain infrastructure, and also not the user-facing things like the debuggers. To hear Russ Cox tell the tale, this is mostly because they required flexibility, and I suppose they were right, since they did rewrite their linker 3 times, and sure enough, 15 years later, in the year of our lord 2024, most debugging in Go seems to happen by writing ASCII-shaped bytes to some kind of a file, somewhere, and then using the world's most expensive full text search engine to get those bytes so you can physically read them on a screen. A debugger does seem limited in use for that specific workflow, so maybe that was the right call, who knows.

Anyway, I don't think there's ever been any real doubt that something like LLVM imposes a serious integration cost, but now that we have Go, the discussion has mostly shifted to "is it worth it", and seemingly the answer is "mostly yes" since nearly everyone building a new and hip native language uses LLVM or something like it. Every language is different, YMMV, etc., but I personally don't hear a lot of complaining about what a bummer it is that all these tools work pleasantly together instead of secretly sabotaging each other by loading up FP with whatever cursed data Go wanted to use it for. And why would they?

What is more mysterious to me is how an actual assembly programmer came to defend Go's stance on ... assembly. Perhaps I'm the only one who reads these things, but at various points in the ASM docs[1] (which I will heretofore call "Mr Pike's wild ride") the author expresses a view that I think is reasonably well-described as "a tempered but pretty much open contempt for the practice as a whole". cf.,

> Instructions, registers, and assembler directives are always in UPPER CASE to remind you that assembly programming is a fraught endeavor. (Exception: the g register renaming on ARM.)

Even if your feelings are hard to hurt though, if you ever crack open the toolchain and attempt to read the golang kind-of-IL-kind-of-x86, it is hard to walk away thinking "these people really get me and my profession". DI and FP are both normal registers! It uses the unicode interpunct instead of the plain old dot operator! It uses NIL instead of NULL! It is one thing to say calling conventions are stupid, but it's another thing entirely to give a great big hug to an almost-but-not-quite-assembly-code that is convenient neither for humans to type nor for tools to consume.

[1]: https://go.dev/doc/asm

There is truth to what you say. But I sense what I wrote came off more negative than I intended, and I am not sure it makes any of our lives (our lives or his) better to be hard on the author. Self actualization is legitimately extremely difficult.

You are catching a lot of flak for this, but there is one thing you are right about. If you make tens of millions of dollars, and can't figure out what to do with those resources, you shouldn't be calling your coworkers NPCs. You're the NPC.

I truly mean this in an entirely non-judgemental way. I wish the author luck in achieving his dream of becoming high agency rather than simply high freedom. I wish it for everyone who wants it.

Just to emphasize this point: Walmart was to the IT revolution what Amazon is to the Internet revolution. They were among the first in the sector to move beyond paper and industrialize IT for operations, which allowed them to scale way faster and way more efficiently than their competition. Walmart's most powerful executives were IT executives, and many of them went on to have very decorated careers, e.g., Kevin Turner was the CIO immediately prior to becoming COO at Microsoft.

Walmart is not an Internet company. It is definitely a tech company. It's just that its tech is no longer super cool.

I think the title should be changed, Coda acquired Grammarly. No?

Ian I am willing to continue if you are getting something out of it, but you don't seem to want to answer the question I have and the questions you have seem (to me) like they are trivially answerable from what I've written in the response tree to my original comment. So, I'm not sure that you are.

It is the consensus. I can’t think of a single good researcher I know who doesn’t think this. The last holdout might have been Sutskever, and at NeurIPS he said pretaining as we know it is ending because we ran out of data and synthetics can’t save it. If you have an alternative proposal for how it avoids death I’d love to hear it but currently there are 0 articulated plans that seem plausible and I will bet money that this is true of most researchers.

I think the consensus is that the general purpose transformer-based pertaining models like gpt4 are roughly as good as they’ll be. o1 seems like it will be slightly better in general. So I think it’s fair to say the capability is not there, and even if it was the reliability is not going to be there either, in this generation of models.

I wrote more about the implications of this elsewhere: https://news.ycombinator.com/item?id=42465598