twic

    $ echo 'class Hello { public static void main(String[] args) { System.out.println("Hello, world"); } }' >Hello.java
    $ javac Hello.java 
    $ java --version
    openjdk 21.0.7 2025-04-15 LTS
    OpenJDK Runtime Environment Zulu21.42+21-CRaC-CA (build 21.0.7+6-LTS)
    OpenJDK 64-Bit Server VM Zulu21.42+21-CRaC-CA (build 21.0.7+6-LTS, mixed mode, sharing)
    $ time java -cp . Hello
    Hello, world
    
    real 0m0.026s
    user 0m0.010s
    sys  0m0.018s

For some reason this machine is still on 21. Anyway, the overhead of the JVM itself is pretty low.

For small tools it's fine:

    $ echo 'class Dig { public static void main(String[] args) throws Exception { var addr = java.net.InetAddress.getByName(args[0]); System.out.println(addr); } }' >Dig.java
    $ javac Dig.java
    $ time java -cp . Dig news.ycombinator.com
    news.ycombinator.com/209.216.230.207
    
    real 0m0.047s
    user 0m0.026s
    sys  0m0.021s

    $ time host news.ycombinator.com
    news.ycombinator.com has address 209.216.230.207
    news.ycombinator.com has IPv6 address 2606:7100:1:67::26
    
    real 0m0.052s
    user 0m0.005s
    sys  0m0.004s

Java startup gets slow when you use some massive framework like Spring. If you need a program to start fast, don't use one!

Have you tried being Queen of England by grace of God?

Is there a dataset for this? Maybe a Bloomberg ticker?

The terminology is all a bit loose. Proteins are peptides, but we don't usually call them that. But when a hormone is a protein, rather than a small molecule, then we call it a "peptide hormone". I suppose because we're making a chemical point, that the hormone is in the family of peptides rather than steroids or eicosanoids or whatever?

As you say, insulin is a fully fledged protein, albeit a small one, and i wouldn't call it a peptide myself. But then, insulin is 51 residues, whereas tirzepatide (Mounjaro) is 39; is that such a big difference? FWIW i think a lot of other "peptides" are even smaller, eg CJC-1295 is about 30 residues.

Logs and metrics are both derived from events. A log takes the whole event and records it somewhere. A metric takes some numeric value from the event, aggregates it over time, and records it periodically. You can reconstruct a metric from logs for the underlying events.

A trace is a period of execution between two events. You could record a trace as a pair of log entries, or one log entry at the end. You can then reconstruct a trace from those log entries. If you want to associate multiple spans, and separate log entries, within a trace, you use a shared ID, which is just the same as a context entry for logging.

All three of these pillars are just ways of looking at events. They are not fundamentally different at all. This is a mistaken idea in "Observability 1.0" whose correction is the basis of "Observability 2.0".

The pillars still have their uses, but the choice between them is really a non-functional one - storing a log entry for every event might be too expensive, so just store metrics instead, and index every log entry so it can be correlated with nearby ones might be too expensive, so just store specific traces instead.

Pretty sure you've been able to interrupt a thread blocked on IO in a normal InputStream since 1.0.2 in 1996.

There is a significant caveat to this, which is that if the underlying blocking IO operation isn't natively cancellable (and the JDK doesn't use the trick Zig uses here), then the interrupt is allowed to close the IO resource as a way of ending the operation early. In practice this is usually fine, as you're interrupting the thread precisely because you want it to give up on whatever it's doing, but it precludes some particularly subtle possible IO designs.

Not sure if this changes under virtual threads, where the thread is much more loosely coupled to the syscall.

Mild counterpoint: a friend of mine, a professional woman, started on GLP-1 drugs some time ago. She has lost weight, but she also says she's had significant cognitive improvements, more focus, better sleep, etc. It would be great to have research which explicitly teases out these various effects.

> A well done monorepo is a huge force multiplier on a large organization

How so?

I work at a company which uses a monorepo, and I haven't seen any upside to it yet. We have a tools team that's invested a vast amount of work in it. Still seems strictly worse than a 'normal' polyrepo setup. I haven't understood why so many people are so enthusiastic about it.

An Italian friend was excited to visit a castle, and on arrival disappointedly exclaimed "but this is a "fortezza!".

See? Immortality through memes!