theobeers

What am I supposed to say to that? If you think the argument that you believe I’m trying to make (which I couldn’t guess if you put a gun to my head) would be easy to make, and that I’m just not doing so, then you’d be better off engaging in discourse with an imaginary but more competent interlocutor.

Mr. Ptacek, a) I have no affiliation with OP, and b) do you know what my actual position is (not presupposing that you care)? It's that I don't know anyone who has been inspired by anything that YC has funded in a very long time. The supermajority of these startups that don't make headlines for being scams is, in a way, even sadder.

I also think it's pointless to howl at the sky about how depressing this is. It's just the current reality of SV. I'm not going to pretend that what a16z is funding is any better (or worse).

While I agree that YC appears rotten to the core at this point, it’s almost impossible to sustain a criticism of the accelerator because they make so many little investments. No matter what you accuse them of, they’ll dismiss it by saying you’re cherry-picking. I have to admit, it’s a brilliant strategy to avoid any kind of accountability.

Well, that's sort of like what the "sort key" of a given string is: a vector of its nonzero primary-level collation weights, then secondaries, then tertiaries... And once you know what collation options you're using (tailoring etc.), you could just compute the sort key of each string as you encounter it and cache that. Then you would be able to reach a collation decision rapidly for any two strings whose sort keys you already have. It does boil down to vector comparison at that point.

I experimented with adding an LRU cache to my Rust UCA implementation, but I saw essentially no performance benefit (on the workloads I had), and I decided the feature wasn't worth the complexity and removed it.

Something I found about Unicode collation is that, once the fast paths are added, they get hit a surprisingly large percentage of the time. I'm thinking in particular of the way that performant UCA implementations build sort keys lazily, stopping once a collation decision is reached. The average "point of difference" is at the primary level and within a few characters of the start of each string. Only a small portion of the sort keys ever get built.

I am definitely interested in finding more ways to avoid work in the collation routine. Many times, I've had what I thought was a clever idea and found that it didn't pan out in benchmarks. Thank you for your comment!

Submission statement:

Figuring out how to develop a Unicode collator from scratch for a research group that I working with in Berlin was one of my formative experiences as a programmer. Ever since then, I've wanted to write something to collect my thoughts on the Unicode Collation Algorithm and the process of building a conformant implementation. Last summer I had a good excuse to do this, when I decided to adapt my collator to Zig as a way of learning that language.

The Unicode standards, and the (relatively) low-level software libraries based on them, do a lot of things for us to make computing possible. We have the luxury of not needing to worry about most of those things most of the time. I find it humbling whenever I do peek under the hood.

“If AI doesn’t literally take all the white-collar jobs over the next few years, we won’t just have a stock market bubble to deal with. We’ll have a drought of educated workers.”

Indeed. For me this feels like an “I saw the best minds of my generation” moment.

Indeed, many such cases. Our society is full of institutions that functioned only because "no one in a position to participate would be shameless enough to abuse it." Then that assumption breaks, and it's ruined for everyone.

It is relevant, though awkward to discuss, that a large share of NIH and NSF funding proposals (and indeed funded projects) are led by researchers who didn't grow up in the US. I wonder if it's in fact a majority.

Another record, Name Authority Pointer (NAPTR), has the telephone number of the Johnson Space Center in Houston:

  > dig where-is-the-iss.dedyn.io NAPTR

  ; <<>> DiG 9.10.6 <<>> where-is-the-iss.dedyn.io NAPTR
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31786
  ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 1232
  ;; QUESTION SECTION:
  ;where-is-the-iss.dedyn.io. IN NAPTR

  ;; ANSWER SECTION:
  where-is-the-iss.dedyn.io. 3600 IN NAPTR 100 100 "u" "E2U+voice:tel" "!^.*$!tel:+12814830123!" .

  ;; Query time: 84 msec
  ;; SERVER: 100.100.100.100#53(100.100.100.100)
  ;; WHEN: Sun Jul 06 10:53:39 EDT 2025
  ;; MSG SIZE rcvd: 111

As recently as five years ago, the Fine Arts Building on Michigan Ave. in Chicago employed elevator operators. It probably still does.

Watching that video made me wonder whether I should even feel comfortable visiting HN.