znkr

12 ms·

31.
by znkr 2y ago
Nope: https://isocpp.org/wiki/faq/intrinsic-types#bytes-review
32.
by znkr 2y ago
No, it was based on Google+ which was integrated with Picasa
33.
by znkr 2y ago
You would have that frustration anyway during toolchain upgrades if the map implementation changed from one go version to the next.
34.
by znkr 2y ago
I have been writing Go code for many years, the fact that I don’t need to think about things unrelated to the problem I am trying to solve is why I love Go. I definitely learned a lot about Go and I am thinking more about certain aspects th
35.
by znkr 2y ago
> I'd even postulate that's why we have so many crap applications today that are first on the market but slow, inefficient and user unfriendly. That’s certainly one way to get a crappy application. Another way is to find optima
36.
by znkr 2y ago
I worked in image processing for some time, it’s very similar
37.
by znkr 2y ago
Indeed, its tradeoffs all the way down
38.
by znkr 2y ago
It’s not just tooling; processes, infrastructure and dedicated teams for centralized infrastructure are what makes Google’s monorepo what it is. FWIW, most of the tools are publicly available or have good publicly available counterparts. Wh
39.
by znkr 2y ago
Ceci n'est pas une pipe
40.
by znkr 2y ago
What could possibly go wrong…
41.
by znkr 2y ago
If you don’t have another reason for consolidation than consolidation then yes :)
42.
by znkr 2y ago
It’s not about being used many times, but about the necessity to evolve in the same direction. When that happens, it usually manifests as toil for the team. Consolidating code means to change the structure of the code so that only one piece
43.
by znkr 2y ago
Then the only best practices that matter are the ones that your team believes are correct
44.
by znkr 2y ago
I am the industry for over 10 years now. Whenever I have to work with a project where someone used DRY consciously, I know I am in for a world of pain. Consolidating code is easy, pulling it apart is a lot harder.
45.
by znkr 2y ago
> If you are going to add semantic structure to an identifier, which is frequently useful and a good idea, best practice is usually to encrypt it before sending it to the external world. Encrypting a UUID-like structure is approximately
46.
by znkr 3y ago
It’s been done and it becomes quite complicated very quickly. Then it becomes necessary to manage that complexity and you end up with something like Spanner.
47.
by znkr 3y ago
It’s an indirect quotation, not a quote from a primary source. Your quotation is a quotation of the article, not of Matt Miller. Read the primary sources, the misunderstanding is yours.
48.
by znkr 3y ago
You’ll find more primary sources across different organizations that all arrive at the 60 - 70% number. But what really grinds my gears here is that you take a piece from the article you’re criticizing and pretend that it’s a quote from Mat
49.
by znkr 3y ago
That’s a dangerous line of thinking: memory safe languages can and do have memory safety bugs. There are many causes for this, from incorrect compilation (as seen here IIUC), bugs in the language runtime, concurrency problems, to unsafe lan
50.
by znkr 3y ago
You get reserve, not reserve_exact. You are right that it would be allowed to implement reserve_exact semantics instead, given the method comment. But that’s not how it works, if you want reserve_exact semantics, you need to take extra step
51.
by znkr 3y ago
You can use slices.Grow for that purpose in Go. Exact sizing is only possible during slice creation.
52.
by znkr 3y ago
It grows by 2x for small sizes, then it transitions to growing it by 1.25x
53.
by znkr 3y ago
I think that’s an oversimplification. By that measure any assembler would be simple, yet assembly is not simple at all. Most esoteric languages compile super fast, but are usually complicated by design. Also, it’s not even a sound measure:
54.
by znkr 3y ago
> The fact that an empty message can successfully deserialise into any valid protobuf is an insane decision and should have been thrown out long ago The reason for this is that the protobuf wire format is designed for very high entropy:
55.
by znkr 3y ago
Yeah, it’s a simplification. You need to have something to make statements about. But that doesn’t change that what computers are doing is something completely different than what mathematics as a discipline cares about. It’s the same diffe
56.
by znkr 3y ago
Sorry, this is my personal pet peeve: Your using two definitions of math. Let’s call them proper math and using math. Proper math consists solely of tautologies; statements that are always true. Using math is when you make use of these taut
57.
by znkr 3y ago
https://research.swtch.com/coro
58.
by znkr 3y ago
I am not sure I fully understand your question, but I’ll try to answer the question I understood. Very generally, every field of math I know concerns itself with mappings and what they do (e.g. matrixes are mappings, as are metrics and norm
59.
by znkr 3y ago
Note that ptrace is only one platform and it’s no longer even the default. It’s been replaced by systrap. When running on bare metal, the KVM platform provides the best performance: https://gvisor.dev/docs/architecture_
60.
by znkr 3y ago
> 2. ultimately getting rid of cgo would probably help a lot anyway, cgo calls are pretty slow It’s slow compared to a function call in C, but it’s still measured in nanoseconds. If you’re not calling C functions from a tight loop in Go

More ›