kiitos

41 ms·

661.
by kiitos 3y ago
Exhibit A > I would say I have a pretty good understanding of ... HTTP Exhibit B > HTTP/2 implements multiplexing on top of TCP, which is just plain stupid ... the correct thing to do is to establish multiple TCP connections
662.
by kiitos 3y ago
Obviously nobody is going to run workloads that need to exploit these kinds of things on ECS instances. But these workloads are niche, not normal. Most code that's written and deployed to some notion of "production" is not CP
663.
by kiitos 3y ago
HTTP/1 between a client-server pair incurs per-request overhead which is not present in HTTP/2. You can do more RPS with less CPU if you use HTTP/2.
664.
by kiitos 3y ago
For someone who complains about web stuff so much, it's weird that you don't have a better understanding of the technology. No amount of pipelining can fix HTTP/1's request-per-connection model enough to make it competit
665.
by kiitos 3y ago
> In Pijul, there are two kinds of conflicts inside a file: > When two different authors add lines at the same position in a file, and it is impossible to tell which comes first in the file. > When one author adds a line in a bloc
666.
by kiitos 3y ago
OK, but you don't store the string representation in your DB, or on disk, etc.
667.
by kiitos 3y ago
For me the whole value prop for ULIDs is that they can be generated by any node in a distributed system without coordination, while roughly preserving time order. "Roughly" meaning: all IDs will be globally ordered at millisecon
668.
by kiitos 3y ago
> It seems like the only real use case for these timestamps is to get data from around the same time together. Yep. > A second is fine for that. Not when you're doing O(1k-1M) operations per second, it isn't!
669.
by kiitos 3y ago
Oops, yes, this one.
670.
by kiitos 3y ago
> If you need more than second precision then millisecond doesn't get you much further. It gets you precisely 100x further.
671.
by kiitos 3y ago
> alias and type redefinitions are conceptually the same. In Go, they are not. Aliases establish precise equivalence between types, type redefinitions establish new types altogether.
672.
by kiitos 3y ago
In the year of our lord 2023, Graphite, Statsd, etc. are anachronisms. Prometheus is wildly superior to those tools.
673.
by kiitos 3y ago
Second precision is too coarse for many (most?) use cases.
674.
by kiitos 3y ago
UUIDs are 128 bits, or 16 bytes. They have infinitely many possible string representations. Those strings are not the value, they're a transformation of the value.
675.
by kiitos 3y ago
Technically not a type alias, just a normal type declaration. But yes, this is my point: you can't assume that an enum type will always be one of a fixed set of values that you've defined. You always have to do at least a little
676.
by kiitos 3y ago
func fn(c color.Color) { switch c { case color.Red, color.Green, color.Blue: log.Printf("c=%#+v -- OK", c) default: log.Printf("c=%#+v -- should not be possible", c) } }
677.
by kiitos 3y ago
I don't know what point you're trying to make, beyond just objecting to the points that I'm trying to make. Not interested in continuing.
678.
by kiitos 3y ago
It literally isn't enforced by the compiler, because I can compile code which is invalid.
679.
by kiitos 3y ago
Sure, by parsing a string to a Color value.
680.
by kiitos 3y ago
This is an inane comparison. Casting as demonstrated in the example is normal and has to be expected. Go types aren't as strict as types in other languages. Code can't assume otherwise.
681.
by kiitos 3y ago
The point here is that, in Go, "what a Color type is" isn't something that can be enforced by the compiler. And more specifically, Go doesn't allow you to define reliable enums.
682.
by kiitos 3y ago
The code in my example is an entirely valid way to interact with values, and doesn't represent an "opting out" of safety or abstraction.
683.
by kiitos 3y ago
Casting (in the way I did it in my example) is entirely normal and common and in no way an escape hatch.
684.
by kiitos 3y ago
> it’s is not my responsibility to validate all permutations of unknown types to ensure you’re passing me mine. Of course it is! If you provide an API that takes a Color, and you define valid Colors as exclusively Red, Green, and Blue, t
685.
by kiitos 3y ago
> By that measure, are the type safety hints of Python not really giving any type safety? If we're talking compile-time, then: yes, absolutely! Type hinting doesn't provide type safety, because type safety isn't a spectrum
686.
by kiitos 3y ago
> If your module relies on compile time checks for validity, ...then it's broken, because the Go compiler, factually, cannot (in general) check or enforce the validity of specific values. > there's no reason for you to also
687.
by kiitos 3y ago
I'm not sure how that's comparable. Compile-time type safety is a boolean thing, you either have it or you don't. If you have it, then my example shouldn't compile. But it does compile, so you don't have it.
688.
by kiitos 3y ago
The article is titled "Compile-time safety for enumerations in Go" but my example demonstrates that this is not the case.
689.
by kiitos 3y ago
Indeed. Go types are like simple locks: they keep honest users honest, but they don't prevent dishonest users from breaking your assumptions. The point is just that "compile-time type safety for enumerations" isn't actua
690.
by kiitos 3y ago
> But he doesn't even need to do the pointer/type conversion stuff, he could just do `c = Color("orange")` and call it a day. c = Color("orange") does not compile.

More ›