You can do this in Go by making a type declaration defining a function and then adding a method with the same signature on that type, which calls the function. The Go standard library does exactly this with the `HandlerFunc` type [1].
// The HandlerFunc type is an adapter to allow the use of
// ordinary functions as HTTP handlers. If f is a function
// with the appropriate signature, HandlerFunc(f) is a
// [Handler] that calls f.
type HandlerFunc func(ResponseWriter, *Request)
// ServeHTTP calls f(w, r).
func (f HandlerFunc) ServeHTTP(w ResponseWriter, r *Request) {
f(w, r)
}
Advertising any UUID/GUID generator as cryptographically secure, or relying on it to be so, is a mistake, in my opinion.
You use a UUID when you need a universally unique ID whose guessability properties are not a critical security requirement. While the V4 UUID spec (which this package does not implement, but most users might assume it does) states that a UUID implementation SHOULD be cryptographically secure [1], it also states that they MUST NOT be used as security capabilities [2]. This is b/c they are not intended as secure tokens, but many users mistakenly assume them to be suitable as such. Not to mention, V4 UUIDs only have 122 bits of entropy, not 128, since 6 bits are reserved for version and variant information, which many users don't realize.
So you can generate a UUID that is suitable as a secure token, but at that point don't call it a UUID. Just call it a secure token. And if you need a secure token, use something like Go's `Text()` function from `crypto/rand` [3].
The situation reminds me of how the Go team updated the `math/rand` and `math/rand/v2` packages to use a CSPRNG as a defensive measure [4], while still urging users to use `crypto/rand` in secure contexts.
This shouldn't really matter as your import paths are obviously different. `github.com/google/uuid` and `github.com/sdrapkin/guid` can happily coexist. Any file/codebase importing both (which would ideally be avoided in the first place) can alias them.
> IMHO "Guid" is just as well known
I think the point the commenter was trying to make is that these do not adhere to the UUID spec. You don't specify which version, but judging by the docs and your comparison to `github.com/google/uuid`, I'd wager most folks looking at this library would assume they are supposed to be V4 UUIDs.
Something similar, but encrypted, is PaperAge [1]. Admittedly, I haven't used it, but it seems like a nice solution for secure physical backup of small secrets. The catch, of course, is now you need to make sure you never forget your passphrase or back that up off-site somewhere else.
> Overall, pretty weird stuff. I am not sure why the Go team went down this route. Maybe it simplifies the compiler by having this bespoke assembly format?
Rob Pike spoke on the design of Go's assembler at a talk in 2016 [1][2]. I think it basically came down to the observation that most assembly language is roughly the same, so why not build a common assembly language that "lets you talk to the machine at the lowest level and yet not have to learn a new syntax." It also enables them to automatically generate a working assembler given an instruction manual PDF for a new architecture as input.
Pretty much, yes. If you imagine “Bob” has a policy that he can only converse with numbers in his address book, then you could think of it as:
1. -> Alice calls Bob
1.a. Bob does not pick up the call, but adds the number shown from caller ID to his address book
2. <- Bob calls the number (Alice) back
3. -> Alice picks up and they talk happily
My interpretation is he's lamenting that certain Unix OS abstractions (e.g. open, close, read, and write) do not lend themselves well to building distributed systems, like a distributed filesystem. Plan9, for example, designed it's API with such possibilities in mind.
Agreed. I avoid reader-writer locks unless absolutely required and benchmarks prove it worthwhile.
Their usage often fails to outperform a regular lock due to additional overhead. They seem to make sense only in specific high-contention scenarios where arrival rate is high and/or the critical section has a long duration [1].
> When io.Copy copies from a TCPConn to a UnixConn, it will now use Linux's splice(2) system call if possible, using the new method TCPConn.WriteTo.
Interface upgrades, yet again, transparently giving us more zero-copy IO. Love how much mileage they’re able to get out of this pattern in the io package.
I'm curious to hear others' answers to this question as well. I've been looking into building my own OpenBSD based home router and so far thinking a Protectli Vault [1] would fit the bill.
Well, turns out I'm no longer able to reproduce the issue either. I just turned DDG Privacy Essentials back on for https://cs.opensource.google and I was able to view the site just fine.
Back when it was happening (maybe ~1 year ago?), I was using the latest versions of Firefox and DDG Privacy Essentials and it ocurred even if I went directly to https://cs.opensource.google. I had confirmed back then that when I turned DDG Privacy Essentials on I got "Permission denied", but with it off I was able to view the page.
I'm on the latest verisons of Firefox and DDG Privacy Essentials now. Seems it is no longer an issue in the latest version(s).
Do you have any privacy/ad-blocking extensions installed? I used to have the same issue and realized it was due to the DuckDuckGo Privacy Essentials extension. When I turn that extension's protections off for cs.opensource.google then it works.
This post resonates with me and briefly acknowledges the thing that scares me the most about self hosting personal stuff for myself and loved ones: the bus factor. I haven't heard many self-hosting proponents talk about their strategy to mitigate the bus factor. I really want to self-host, but it seems like such a headache and a risk.
I see a lot of folks in this thread lamenting the usage of ligatures, but note that the downloaded set of font files includes a "JetBrainsMonoNL" version of all variants, which does not include ligatures ("NL", as in, "No Ligatures").
I do not like ligatures either, yet this is my favorite monospaced font. I use JetBrainsMonoNL in all the places.
I applied to Fly.io and a big part of that was because of their hiring process. Reading about the way they think about finding good candidates resonated with me. The role for which I applied was something I am deeply interested in, and would love to get into, might _possibly_ have the chops, but for which I probably do not yet have "the" resume. It felt like a Hail Mary to apply but I figured if nothing else I'd learn alot in the process and if I'm really lucky, might even get some constructive feedback.
I didn't clear the work sample but man, I had fun doing it. I learned a ton. I most appreciated that they gave me legitimate feedback as to why they decided not to move ahead with me. It highlighted a gap in my current knowledge/experience that I was glad to discover.
That being said, it did take a very long time to get a final answer back from them, but overall I'm a happpy reject. Could even see myself applying again some day.
[1]: https://cs.opensource.google/go/go/+/refs/tags/go1.25.4:src/...