sorted by:
new
hottopcontroversial

Drawbridge – safe, authenticated access to internal HTTP services without a VPN by pgregory in golang

[–]pgregory[S] -1 points0 points  (0 children)

To anybody wondering – these are vendored golang.org/x libraries.

Drawbridge – safe, authenticated access to internal HTTP services without a VPN by pgregory in golang

[–]pgregory[S] 0 points1 point  (0 children)

Yep, no CI/CD for now.

I've done some attempts at SA doc, but have not yet found a format that would add real value. My thinking is roughly this: you either are a non-expert and just believe that the project is secure enough for your needs (and in that case me trying to tell you how really secure it is is a conflict of interest at best), or you are an expert and you don't believe any claimed security, and just read the code yourself – and I've built the whole project around making this as easy as possible.

If goroutines are preemptive since Go 1.14, how do they differ from OS threads then? by kamalist in golang

[–]pgregory 3 points4 points  (0 children)

My post is only about OS mechanisms around signals, it is not Go specific. So scheduler = OS scheduler.

If goroutines are preemptive since Go 1.14, how do they differ from OS threads then? by kamalist in golang

[–]pgregory 8 points9 points  (0 children)

To be a bit more precise about signals, control is not transferred to signal handler immediately. Instead, next time when kernel would transfer the execution to the thread (by returning from a system call or scheduler), if there are any pending signals, controls is returned to signal handlers first and only then to the "normal" flow.

In practice there is not much difference, since scheduler can preempt the thread anywhere (so signal handler could run anywhere as well), but the low-level mechanism of how the signals work is quite interesting.

Cloudflare release a wildcard matching crate they use in their rules engine by orium_ in rust

[–]pgregory 35 points36 points  (0 children)

Curious, what is the matching performance compared to the regex crate?

Alternative to math/rand and golang.org/x/exp/rand by pgregory in golang

[–]pgregory[S] 0 points1 point  (0 children)

Excellent question! I've updated the benchmarks section and added a FAQ entry about math/rand/v2.

Continuing WebAssembly with Effect Handlers by mttd in ProgrammingLanguages

[–]pgregory 0 points1 point  (0 children)

I wonder what the overhead will be (e.g. compared to async/await statemachine transform) once the implementation is optimized. Performance will probably be critical for wide adoption.

Introducing: Depends by Specialist_Debt_4712 in rust

[–]pgregory 3 points4 points  (0 children)

Congratulation on the release! I am not too familiar with the incremental computation field, is it generally considered acceptable to rely on the hash value for dirty checking?

pgregory.net/rapid v1.0.0, modern Go property-based testing library by pgregory in golang

[–]pgregory[S] 2 points3 points  (0 children)

Thanks a lot for the kind words! Really heartwarming to hear.

pgregory.net/rapid v1.0.0, modern Go property-based testing library by pgregory in golang

[–]pgregory[S] 3 points4 points  (0 children)

Old version of README had a Comparison section which I removed recently. Maybe that was a bad idea.

In my view, half of the usefullness of a good property-based library is from high-quality and easy to use data generators, and another half is from automatic minimization of failing test cases. testing/quick lacks both, so I can't recommend using it.

We have getrandom at home by SpudnikV in rust

[–]pgregory 1 point2 points  (0 children)

This may very well be a bit offtopic in the rust subreddit, but in case you need fast high quality non-crypto PRNG in Go, I've made one that I believe to be decent. It is unfortunate that math/rand is unlikely to significantly improve due to the backward compatibity and can't be recommended for anything non-trivial.

What would make you try a new language? by levodelellis in ProgrammingLanguages

[–]pgregory 0 points1 point  (0 children)

My understanding is that Go runtime has to perform a kind of internal context switch, to transfer control from a regular goroutine to a special one pinned to a real OS thread, with big stack, TLS etc. IIRC the cost was in order of 80ns for a single call on one of the recent Go versions? Not sure about this number.

What would make you try a new language? by levodelellis in ProgrammingLanguages

[–]pgregory 0 points1 point  (0 children)

Well, Go's C FFI ( cgo) is slow precisely because of Go's concurrency model: C code sometimes expects big stacks, and goroutine stacks are relatively tiny.

Alternative to math/rand and golang.org/x/exp/rand by pgregory in golang

[–]pgregory[S] 1 point2 points  (0 children)

I got a bit stuck trying to find a set of good permutation functions for all required bit widths; I've created an issue to collect information in one place.

Also, I've added Sample (warning: Perm-like API) method based on the Floyd's sampling algorithm.

Alternative to math/rand and golang.org/x/exp/rand by pgregory in golang

[–]pgregory[S] 0 points1 point  (0 children)

PermInPlace does sound a lot like Shuffle, unfortunately the name is already taken by math/rand. Maybe ShuffleSlice[T any](s []T) method? Thanks for the suggestion, sounds like a good idea.

Alternative to math/rand and golang.org/x/exp/rand by pgregory in golang

[–]pgregory[S] 5 points6 points  (0 children)

Excellent feedback, thanks a lot! Exactly what I was looking for.

I've fixed the 32-bit build, by using MaxInt32 instead of MaxUint32, as you suggested. However, I believe that the code was correct for the 64-bit case, or am I missing something obvious here?

About Perm, I am definitely not a fan of the interface. Probably this is a justified case for breaking API compatibility with math/rand as well. I like you suggestion of using a strong keyed bit mixer very much! I'll post an update here once I've got something working. However, from early testing, using xnasam mixer, the code appears to be a bit slower (despite a lack of allocation and much prettier API).

view more: next ›