zeeboo

5 ms·

1.
by zeeboo 9mo ago
It is indeed manufactured specifically to show the existence of "normal" numbers, which are, loosely, numbers where every finite sequence of digits is equally likely to appear. This property is both ubiquitous (almost every number
2.
by zeeboo 1y ago
https://go.dev/doc/faq#generic_methods
3.
by zeeboo 3y ago
Go's GC has been precise since 1.4 released about 13 years ago.
4.
by zeeboo 4y ago
You forgot to list the most useful feature of adding generics: people on the internet can no longer say "lol no generics", drastically reducing the amount of garbage comments about Go.
5.
by zeeboo 4y ago
It's for people who think racism is wrong and want a reason to avoid being introspective about what they can do about living in and benefiting from a society built on racism.
6.
by zeeboo 4y ago
Again, it's not just malicious updates. Normal updates can also introduce security vulnerabilities. For example, I have a dependency at v1.0 and v1.0.1 introduces a security bug unintentionally. It is eventually fixed in v1.1. If I wai
7.
by zeeboo 4y ago
My statement had nothing to do with intent. Conversely, once a vulnerability is introduced (intentionally or not), you don't want every developer to update their deps to the newly insecure version.
8.
by zeeboo 4y ago
Every change that fixes a security issue implies the existence of a change that introduced the security issue in the first place. Why is bumping a version more likely to remove security issues instead of introduce them? The reason why older
9.
A Tale of Two Copies(storj.io)
6 points by zeeboo 5y ago|0 comments
10.
by zeeboo 5y ago
So, I thought this at one point, too. But it turns out that methods is a type alias to an unnamed type, so there's no package level privacy issues: https://github.com/protocolbuffers/protobuf-go/blob/v1.2
11.
by zeeboo 5y ago
For example, it doesn't use HTTP/2 (which has a ~100 page RFC and compiles to a ~2MB object file), does not have any load balancing or name resolution engine, and does not handle connection pooling or multiplexing. Granted, one pe
12.
by zeeboo 5y ago
Indeed. This is in a thread where the original comment was "I think the best approach would be making & work in basically any scenario." I'm trying to demonstrate the complications of making it work on map accesses.
13.
by zeeboo 5y ago
I apologize if the tone of my previous comment sounded harsh to you or if some of my arguments sounded like strawmen. I am in good faith trying to interpret your comments as best as I am able. I don't feel like you're giving me th
14.
by zeeboo 5y ago
> That's a distinction without a difference. `append` does not "explicitly reallocate", it may or may not reallocate, you've no idea. Even if the backing array is full, it might be realloc'd in-place. Maybe to yo
15.
by zeeboo 5y ago
> It doesn't (have to) invalidate the pointer though. When resized the map's content get copied to a new backing buffer, the pointer can keep pointing to the old buffer. That's true, but I don't think it's very c
16.
by zeeboo 5y ago
I think I didn't communicate my point clearly. Consider this hypothetical program: x := make(map[int]int) x[0] = 5 y := &x[0] *y = 10 print(x[0]) // 5 or 10? x[0] = 6 prin
17.
by zeeboo 5y ago
What about `&m[x]` where m is some map? Does that heap allocate and create a copy, or is it a pointer to the actual storage slot? If the former, that's a hidden copy/allocation that didn't exist before, and if it's t
18.
by zeeboo 6y ago
A simple map was discussed in the post. The problem it has is that it has unbounded growth. The sync.Pool approach is a best effort to avoid allocations only. If its API was changed to return sentinel pointers rather than the string, it wou
19.
by zeeboo 6y ago
If you can look at any widely used API that has existed for an extended period of time and not find a single tradeoff or hindsight flaw, you aren't looking hard enough.
20.
by zeeboo 6y ago
It also doesn't include the ipv6 zone scope. Adding that would take it to at least 28 bytes, and still have to handle all the interning problems for cheap equality.
21.
by zeeboo 6y ago
The standard library IP type has worked for numerous programs for a literal decade. Just because a specialized application can do a better job by leveraging, again, decades of real world experience with the language doesn't invalidate
22.
by zeeboo 6y ago
The type is designed to hold both ipv4 and ipv6 addresses.
23.
by zeeboo 6y ago
You can do dynamic tagged values in Go, too. It's called interface{} and everyone hates it. So this does not respond to the parent's point.
24.
by zeeboo 6y ago
It can target glibc in a cross-compile setting. https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
25.
by zeeboo 6y ago
I should not have used the word "assertion". I meant it in the more general way of "code that checks some property", not a literal "assert" feature as built in to the language. I was just pointing out that this
26.
by zeeboo 6y ago
I think it's unlikely this would have been caught by fuzzing. I think you'd have to write assertions that it only read as many bytes as necessary, which is basically saying just don't write the bug in the first place.
27.
by zeeboo 6y ago
I've been working on something like this for some years now: https://github.com/zeebo/rothko
28.
by zeeboo 6y ago
So after I rolled this 20 sided die 8 times and it got a 20 every time that means it's loaded? smh
29.
by zeeboo 7y ago
Technically the Go module _proxy_ is hosted by Google. Even if the proxy went away, you'd still be able to get access to all of the packages as they're still hosted elsewhere. It just wouldn't be as fast.
30.
by zeeboo 7y ago
Using chan struct{} is more efficient, and guarantees there is nothing being put into the channel. That's why you see it used on the Context type's Done method, for example. https://golang.org/pkg/context&#x2F

More ›