Readit News logoReadit News
rsc commented on Improved Gemini 2.5 Flash and Flash-Lite   developers.googleblog.com... · Posted by u/meetpateltech
scosman · 3 months ago
Ugh. If the model name includes sem_ver version number, increment the version number when making a new release!

Anthropic learned this lesson. Google, Deepseek, Kimi, OpenAI and others keep repeating it. This feels like Gemini_2.5_final_FINAL_FINAL_v2.

rsc · 3 months ago
FWIW, the versions are not semver but they do follow a defined and regular version schema: https://ai.google.dev/gemini-api/docs/models#model-versions.
rsc commented on What is the go proxy even doing?   flak.tedunangst.com/post/... · Posted by u/ingve
rsc · 4 months ago
[Also posted to Lobsters: https://lobste.rs/s/ms94ja/what_is_go_proxy_even_doing#c_vz2...]

I apologize for the traffic. We clearly need to look at the “thundering herd” you are observing. That shouldn’t be happening at all.

Separately, the bug we fixed last time were about repeatedly cloning a repo in sequence even if it was unchanged, not about redundant parallel fetches. We fixed that only for Git, because Git makes it very easy to look at a branch or tag and get the tree hash, without downloading the full repo. This is exposed as the go command’s -reuse flag. The relevant Git code is at https://go.dev/src/cmd/go/internal/modfetch/codehost/git.go#... (CheckReuse).

What we need from any VCS to implement the reuse check is a cheap way to download a list of every tag and branch along with a cryptographic file tree checksum for each one, without doing a full repo clone. At the time, I convinced myself Mercurial did not support this. Perhaps I was wrong or perhaps it does now. If anyone can help us understand how that works, we could implement the -reuse flag for Mercurial too. (Any other VCSs would be great too, but Git is #1 by a very wide margin and I believe Mercurial is #2 also by a wide margin.)

Again, apologies for all the traffic, and thanks to Ted for the excellent analysis. We will look into both.

rsc commented on How to store Go pointers from assembly   mazzo.li/posts/go-asm-poi... · Posted by u/pdziepak
rsc · 6 months ago
This is a strange and dangerous thing to try to do from assembly. In particular, all these details about write barriers being hand-coded in the assembly are subject to change from release to release.

Better to structure your code so that you do the pointer manipulation (and allocation) in Go code instead, and leave assembly only for what is absolutely necessary for performance (usually things like bulk operations, special instructions, and so on).

rsc commented on Leaving Google   airs.com/blog/archives/67... · Posted by u/todsacerdoti
atombender · 7 months ago
Gotcha. In your golang-dev announcement you wrote that you are "not leaving the Go project", but maybe there was another announcement?
rsc · 7 months ago
The parent comment is the first time I've said anything publicly (it has only been a few weeks). I didn't feel like it needed an announcement, but since it came up, it seemed worth correcting. It's not a state secret. :-)

In my August announcement, I was careful to say I wasn't leaving the Go project. I'm still involved with the Go project and expect to keep being involved. I'm just not officially on the Go team at Google anymore. Stepping back from the actual team to give others room to lead always seemed to me both likely and appropriate.

rsc commented on Leaving Google   airs.com/blog/archives/67... · Posted by u/todsacerdoti
atombender · 7 months ago
Russ Cox has not left. He's still on the Go team at Google, but he's stepped down from his position as tech lead.
rsc · 7 months ago
Officially, I have left the Go team too; I started on a new team at Google a few weeks ago. I still use Go quite a bit, I still talk to people on the Go team regularly, and you will still see the occasional code change, code review, or blog post from me. Most importantly, I have high confidence that the team we built will do an excellent job continuing the work.
rsc commented on Optimizing Heap Allocations in Go: A Case Study   dolthub.com/blog/2025-04-... · Posted by u/ingve
38 · 8 months ago
instead of this:

    t.Buf = []byte{}
you can just do:

    t.Buf = nil

rsc · 8 months ago
Those are semantically different (one is nil and one is not) but neither allocates.
rsc commented on Porting Tailscale to Plan 9   tailscale.com/blog/plan9-... · Posted by u/adriangrigore
mcdow · 9 months ago
Rob Pike is in shambles after this devastating betrayal
rsc · 9 months ago
Not sure what the betrayal is? He contributed a quote for yesterday's post. https://tailscale.com/blog/tailscale-enterprise-plan-9-suppo...
rsc commented on Porting Tailscale to Plan 9   tailscale.com/blog/plan9-... · Posted by u/adriangrigore
0xbadcafebee · 9 months ago
I like the premise of the joke, but then as the explanation ran on... I suddenly became depressed. So much broken stuff, so much complexity.... to, what, make a network tunnel? If all this extra work was the joke, that would be funny.
rsc · 9 months ago
We had to do some Plan 9 work, which makes sense when doing something new, but the actual Tailscale implementation is far _less_ work than for other Unixes.
rsc commented on Show HN: Chez Scheme txtar port from Go   git.sr.ht/~egtann/txtar/... · Posted by u/hellcow
thaliaarchi · a year ago
Simple format. Makes me want to write a parser for it using a shared buffered reader library I’m working on in Rust.
rsc commented on Cracking a 512-bit DKIM key for less than $8 in the cloud   dmarcchecker.app/articles... · Posted by u/awulf
linsomniac · a year ago
I forget where but someone proposed regularly rotating your DKIM key and publishing old keys for deniability. So you can still use strong keys and provide a level of deniability.
rsc · a year ago
In the link in the parent comment. :-)

u/rsc

KarmaCake day4236November 10, 2009View Original