Joe Tsai

@Sean_McDowell @dougbentley A relevant comparison: Was John the Baptist a martyr? He was killed (instigated by Herodias) for calling out Herod's sin of adultery. If yes, then it seems that holding a Christian worldview and being killed for it could fit the definition.

@dougbentley Exactly. I had to read the literature on this in my work on the apostles, and as you indicate, there’s a lot of factors in the definition of martyr.

Was Charlie Kirk a martyr?

@robfig Code generation was explored and shown to be much faster for small programs, but the benefits diminish greatly for large programs. There is value in providing it, but was not deemed an acceptable approach for all cases (esp. large binaries).

@_joetsai - hoping to get you to weigh in. Does Google use the official library? How did you think about whether to include support for generated marshaling routines?

Question for all the #golang gophers out there about #protobuf. The official library uses reflection for marshaling. github.com/golang/protobuf Many organizations used Gogo for code generation to benefit from a significant (~30%) performance improvement. github.com/gogo/protobuf

@robfig Yes, they use golang/pb2. It provides reflection APIs so that different message representations can interoperate. This allowed for experimentation with different underlying implementations that are faster. Good to see other implementations that are v2-compatible.

@davidcrawshaw I'm surprised that rsync today still does not do parallel compression.

Fun discovery in production today: rsync is (by default) slow over modern ethernet. It only uses a single core and (by default) compresses data, so it uses less than 10% of even a moderate link before maxing out CPU. You get 10x the throughput with scp.

@ablewhiskey @maisem_ali @Tailscale Correct. A key is just an opaque token that gives you authority to perform some action (e.g., authorize a node, call API method, etc.). The /keys endpoint is intended to support all things related to keys, but some functionality is still missing.

@maisem_ali @Tailscale I guess definition of key here is concatenation of prefix-id-secret

Would be real nice if the @Tailscale API had an endpoint that would tell you when the API key you’re using is due to expire so clients could help drive necessary renewal processes

@mvdan_ @JoeTsai11275351 @davidcrawshaw Ooops. I had logged into Twitter with my Gmail ID. I guess that was my first tweet from that account.

Today's neat hack by @_joetsai: a //go:generate command that generates its own //go:generate directive. github.com/tailscale/tail…

@_smitop @Tailscale @xe @bradfitz @dave_universetf @commaok #TailscaleUp @bradfitz can comment more, but some thoughts: 1) benefit from upstream changes quicker, 2) experiment with changes before merging upstream (e.g., github.com/golang/go/issu…), 3) make minor breaking changes that can't be upstreamed but is safe for our usages.

@Tailscale @xe @bradfitz @dave_universetf @commaok Why do you use your own fork of Go instead of just pulling the latest upstream version? #TailscaleUp

Tailscale engineers @xe @bradfitz @dave_universetf & @commaok are standing by. Tag your questions with #TailscaleUp and we'll do our best to answer them!

@th3_noname #TailscaleUp Yep, such a feature is in the works. Stay tuned!

#TailscaleUp Any plans on making it possible to create on-time keys using the tailscale API? That would make it possible to automatically create a VM that joins the network, without worrying about where the key ends up.

@oldmanuk @JohanBrandhorst @jimmyzelinskie See github.com/google/go-cmp/… and github.com/golang/protobu… for more information.

@JohanBrandhorst @jimmyzelinskie Yeah I guessed as much, @_joetsai maintains both go-cmp and the golang protobuf library

is this what they call "defensive programming" lolsob

@JohanBrandhorst @katie_hockman Yep, we'd like to move over to native fuzzing build into the Go toolchain. The existing third-party fuzzing support has several friction points by nature of being a non-native implementation. See github.com/golang/protobu…

Go native fuzzing is almost ready for beta-use in its development branch! 🎉 Be on the lookout for an upcoming announcement with setup instructions. Are you interested in being an early user? Do you know projects that would be good candidates? golang.org/s/draft-fuzzin… #golang

@mvdan_ I started searching around and found #TOC_3" target="_blank" rel="nofollow noopener">blog.golang.org/11years#TOC_3. Russ mentions hopefully having "beta" support for fuzzing in 1.17.

@mvdan_ Happy to see fuzzing move forward, but github.com/golang/go/issu… is currently marked as "Proposal-Hold". Did I miss something about this for 1.17?

@kenners @SpaceX Congratulations on your many years there! I still remember when we started around the same time working Iron Maiden and Firestorm in the wee hours of the night.

@_zombiezen_ @dgryski @commaok @agl__ I just realized that you mentioned Roughtime in the initial post, sorry for the duplicate mention.

@_zombiezen_ @dgryski @commaok The Roughtime implementation from @agl__ (#maintaining-a-healthy-software-ecosystem" target="_blank" rel="nofollow noopener">roughtime.googlesource.com/roughtime/+/re…) provides a server that is strict is what it accepts and is liberal in what it provides. It's the complete opposite of "Postel's Law"; perhaps we should call this "Langley's Law"

@jyzg @Jeffinatorator @bradfitz @Tailscale A challenge in Go is that most Go binaries have all their dependencies statically linked in. Thus, disjoints sets of Go binaries each using Brotli are unlikely to dynamically share that dictionary.

@_joetsai @Jeffinatorator @bradfitz @Tailscale The beauty of the static dictionary is that it can be shared between threads and even by different applications. That is unlike any other compression resources. If you have a custom environment where you want to save some footprint, you can remove the static dictionary.

Oh a whim, I decided to try to use Protocol Buffers in @Tailscale for something. Recall that on iOS we currently have ~2.5 MiB of free memory remaining (of 15 total) Just adding a single protobuf message w/ a single boolean field takes 1.2 more MiB! @_joetsai, protolite plz? :)

@Jeffinatorator @bradfitz @Tailscale Thanks for diving into this. There seems to be quite a number of low-hanging fruit of things we can do today like making protowire.ParseError not inlineable.

@Jeffinatorator @bradfitz @Tailscale On the topic of raw descriptors, if we wanted to minimize their footprint, Brotli does amazingly well on them due to its use of a static dictionary. However, Brotli's static dictionary itself incurs a fixed cost of ~120KB.

@Jeffinatorator @bradfitz @Tailscale The raw descriptors take up some, but they are actually far less than people think. For that reason, we stopped compressing them in v1.4 and on since the binary size reduction didn't quite justify the CPU cost of decompressing them.

@bradfitz @Tailscale Heh... Go protobufs have not been optimized at all for the mobile environment. \cc @Damien_Neil I'm curious how much of that cost is initial overhead. What's it look like for a single message with two fields? or two messages?