sync.Map is a concurrency-safe hash map. Same name, totally different thing.
636 karma · joined March 16, 2012
sync.Map is a concurrency-safe hash map. Same name, totally different thing.
Contrary to the article's title, it looks like this was a zonal rather than regional outage.
GCP incident report (also linked in the article): https://status.cloud.google.com/incidents/e3yQSE1ysCGjCVEn2q...
This gives the front-end developers lots of flexibility when initially developing new screens and components. Once the UI is ready to ship, the backend team checks to make sure that performance is acceptable (optimizing if necessary), allowlists the new query/queries, and ships to production.
We just joined the CNCF, too!
They plan to keep the project open source and employ Lukas to continue maintaining it.
I can't find a source now, but I believe Rob described Russ Cox as "the only programmer I've met as gifted as Ken." High praise indeed.
From my perspective, the problem with the KeyValuePairs API is that it’s inescapably slow and allocation-heavy. I’m glad that a logging API built into the standard library is usable in more performance-sensitive contexts. It’s easy enough to wrap it up in a KeyValuePairs-style API if you’d prefer that, and you’ll now have the ability to unwrap your logger and interop with other libraries that expect the standard slog interface.
gRPC _does_ require support for HTTP trailers, which aren't used much elsewhere. If you want to use streaming RPCs, you also need a proxy that doesn't buffer (or allows you to disable buffering).
Unlike the other gRPC implementations, it's also taken seriously by MSFT's entire developer division. MSFT contributed a bunch of performance improvements to the protobuf runtime and generated code for .NET, the Kestrel webserver team runs gRPC benchmarks, and support for gRPC-Web is baked right into the core frameworks. From a user perspective, it's clear that someone cares about how all the pieces fit together.
Reading between the lines, it sounds like the main problem is Google's tight control over the project. Apple contributes to the Swift implementation and MSFT drives the native .NET implementation, but there's little non-Google input in decision-making for Go, Java, C++ core, or any of the implementations that wrap core.
More subjectively, I'm impressed by the CNCF's willingness to stick to their stated graduation criteria. gRPC is widely used (even among other CNCF projects), and comes from the company that organized the CNCF - there must have been a lot of pressure to rubber-stamp the application.
Kudos to Daniel for building such a wonderful package.
React now seems like the conservative choice, with early adopters maybe using Svelte; I haven’t heard much about Ember in years. I’m not a web developer, though :)
To date, writing has evaded this trap. Sure, students write short essays during timed exams, but they also wrestle with more complex ideas and topics in longer assignments. Those assignments often take days, or even weeks, to do well.
I’m not sure what the future of those longer assignments is. I’m a bit disturbed by the idea that reading widely, thinking deeply, and distilling a few pages of coherent thoughts may not be an important part of early education. (Schools don’t always teach this well today, but at least we expect them to try.)
Storing a pointer to each node’s parent or using sorted sets seems like it would make the parent poster’s query slower. Those approaches would make it easier to reparent comments, though, and they’d support arbitrarily deep trees (whereas the materialized path implementations I’ve seen limit path length).
You could be writing a linter, a formatter, an implementation of the Language Server Protocol, a compiler that's not protoc, a way to apply semantic patches to large numbers of Protobuf schemas, or any number of other useful tools. There's clearly at least some demand for tools like this - partial implementations of most of these exist, often with some corporate backing.
Unless you're implementing a Protobuf runtime (google.golang.org/protobuf in Go, upb for Python, etc.), your experience seems unusual to me - most developers I've encountered read and write the wire format using one of the existing runtimes.
That said, it does sound like a lot of fun - especially if it's in lisp!
(Source: I helped to start and taught at a charter school in the early 00's. For better and for worse, that school grew into a fairly large charter management organization. Classroom management - which boiled down to convincing a lot of very jaded kids that we actually cared about them - took months at the beginning of each year, and no substantive academic work was possible during that time. Looping in two-year windows struck a good balance between amortizing that cost and preserving teacher expertise.)
> Maybe you mean something besides the wire format. In that case, good luck, because that shit ain't protobuf.
Naming's hard :) Being really pedantic, I think even Google calls the schema description language "Protocol Buffers" and uses phrases like "the Protobuf binary format" or "the Protocol Buffer wire format" to refer to the wire format. Colloquially, it's never confused me to just use "Protobuf" for both.
In his book Sourdough, he spends quite a while describing the music of the Mazg - a fictional group of European migrants. For the audiobook version of Sourdough, he trains a SampleRNN model on a particular genre of Croatian music, then has the model produce Mazg music. The description of machine learning is vivid and approachable, and the audio clips are fantastic.
The article is, IMO, somewhat misleading - it discusses the issue without mentioning gRPC envelopes at all, and it seems pretty clear that envelopes were designed (in part) to address this exact issue.
It's not true of gRPC. It's not "RPC" in any traditional sense - it's just a particular HTTP convention, and the clients reflect that. They're asynchronous, make deadlines and transport errors first-class concepts, and make it easy to work with HTTP headers (and trailers, as the article explains). Calling a gRPC API with a generated client often doesn't feel too different from using a client library for a REST API.
It's definitely a verb-oriented style, as opposed to REST's noun orientation. That's sometimes a plus, and sometimes a minus; it's the same "Kingdom of Nouns" debate [0] that's been going on about Java-style OOP for years.
0: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
> It didn't seem like the gRPC folks understood the needs of web developers very well.
Agreed. Being fair to the team that designed the protocol, though, it seems like browsers weren't in scope at the time.