thinkharderdev

If you need to deserialize an old version then it's not a problem. The unknown field is just ignored during deserialization. The problem is adding a required field since some clients might be sending the old value during the rollout.

But in some situations you can be pretty confident that a field will be required always. And if you turn out to be wrong then it's not a huge deal. You add the new field as optional first (with all upgraded clients setting the value) and then once that is rolled out you make it required.

And if a field is in fact semantically required (like the API cannot process a request without the data in a field) then making it optional at the interface level doesn't really solve anything. The message will get deserialized but if the field is not set it's just an immediate error which doesn't seem much worse to me than a deserialization error.

> I don't actually want to do this, because then you have N + 1 implementations of each data type, where N = number of programming languages touching the data, and + 1 for the proto implementation.

I think this is exactly what you end up with using protobuf. You have an IDL that describes the interface types but then protoc generates language-specific types that are horrible so you end up converting the generated types to some internal type that is easier to use.

Ideally if you have an IDL that is more expressive then the code generator can create more "natural" data structures in the target language. I haven't used it a ton, but when I have used thrift the generated code has been 100x better than what protoc generates. I've been able to actually model my domain in the thrift IDL and end up with types that look like what I would have written by hand so I don't need to create a parallel set of types as a separate domain model.

Support across languages etc is much less mature but I find thrift serialization format to be much nicer than protobuf. The codegen somehow manages to produce types that look like types I would actually write compared to the monstrosities that protoc generates.

Yeah, as soon as you have a moderately complex type the generated code is basically useless. Honestly, ~80% of my gripes about protocol buffers could be alleviated by just allowing me to mark a message field as required.

I feel like I could have written an article like this at various points. Probably while spending two hours trying to figure out a way to represent some protobuf type in a sane way internally.

As far as I understand, the backing assets aren't on-chain. I give tether $100, they create and issue me 100 USDT on-chain. But they can take my $100 and lend it out. Now whoever Tether loaned the $100 to has $100 and I have 100 USDT so $100 has been added to the money supply, just like with a normal bank.

> (1) can't they be taken to court?

Yes, they can be and are being but it's not much comfort to know that the courts will decide a deportation was unlawful after you've already spent 6 months being tortured in an El Salvadoran prison.

Yes, this is an excellent rule. I read an essay years ago (which I can't find now) about technical debt whether the author separate tech debt into two flavors which he analogized to a mortgage (good) and credit card debt (bad). Basically, getting the right design but only partially implementing it is like a mortgage, you're making a down payment on the full implementation and you can pay down the debt over time. But doing terrible hacks to "get something working" is like credit card debt. You're buying some time but will have to pay that back later (with a lot of interest).

I agree with the saying as such but I think it's actually a counterpoint to the "do the simplest thing that could possibly work" idea. When building a system initially you want to do the simplest thing that can possible work, given some appropriate definition of "working". Ideally as the systems requirements evolve you should refactor to address the complexity by adding abstractions, making things horizontally scalable, etc. But for any given change the "simplest thing that can possible work" is usually something along the lines of "we'll just add another if-statement" or "we'll just add another parameter to the API call". Before you know it you have an incomprehensible API with 250 parameters which interact in complex ways and a rats nest of spaghetti code serving it.

I prefer the way Einstein said it (or at least I've heard it attributed to him, not sure if he actually said it): "Make things as simple as possible, but no simpler".

> I mean both sides are guilty. ‘08 saw us bail out banks and now the likes of Fannie Mae and Freddie Mac are GSE’s.

George W Bush (also a Republican) was POTUS in 2008 and it was his administration that oversaw the bank bailouts (the program continued under the Obama administration but was designed and implemented by the Bush admin) and the nationalization of Fannie and Freddie.

It is definitely not good advice for all things. For workloads that are either end of the CPU/IO spectrum (e.g. almost all waiting on IO or almost all doing CPU work) it can be a huge win as you can get very good L1 cache utilization, are not context-switching and don't need to handle thread synchronization in your code because not state is shared between threads.

For workloads that are a mix of IO and non-trivial CPU work, it can still work but is much, much harder to get right.

> It just refuses to work with non-UTF-8 files at all -- is this less sloppy?

You can debate whether it is sloppy but I think an error is much better than silently corrupting data.

> The best approach is to treat data as opaque bytes unless there is a good reason not to

This doesn't seem like a good approach when dealing with strings which are not just blobs of bytes. They have an encoding and generally you want ways to, for instance, convert a string to upper/lowercase.

Yeah, I've always found it a bit puzzling how companies like OpenAI/Anthropic have such high valuations. Like what is the actual business model? You can sell inference-as-a-service of course but given that there are a half-dozen SOTA frontier models and the compute cost of inference is still very high it just seems like there is no margin in it. Nvidia captures so much value on the compute infrastructure and competition pushes prices down for inference and what is left?

> I've regularly wondered how much of the slow battery degradation in these car battery packs is "cheating".

Using the word "cheating" has a very negative valence, but it's not exactly a secret that EV batteries are not designed to use their full "raw" capacity. The manufacturer is quite clear that you should avoid charging to more than 80% on a regular basis as it will degrade the battery faster. What matters is not that the batteries are capable of some theoretical "raw" capacity but that the advertised capacity is correct, just like with SSDs. It doesn't strike me as cheating that SSDs have more capacity than what is advertised on the (proverbial) box.

How well does the expression detection scale with number of columns? If I am reading Table 4 correctly FastLanes is ~10x slower at encoding than parquet+snappy (which seems a reasonable tradeoff for the better compression and scan times) but how is that affected for very wide tables (eg 2k columns or something like that)

I think in practice this would just lead to a class of staffers who actually ran everything.

You don't trust people who run a massive-scale streaming video platform to have the technical chops to generate random numbers?

Yes, absolutely. Just like I'm willing to pay for due process for everyone charged with a crime in this country.

You are confusing two separate things:

1. What to do with people apprehended entering the country illegally and who then claim asylum.

2. What to do with people already inside the country who are suspected of being here illegally.

The first thing is complicated and badly in need of a rethink because clearly our asylum laws are being gamed. I don't have any ready answers but I'm sure that there are a zillion proposals for reform.

For the second thing, yes I believe that if you are suspected of being in the US illegally then you should absolutely have the right to challenge deportation in court. Otherwise literally anyone can be scooped up off the street and deported with no recourse whether they are an American citizen or not. And honestly it is a bit maddening to see people continuously fail to grasp (or pretend to fail to grasp) this basic point.

Deporting people who are in the country illegally is in line with the constitution. Deporting people without due process is not.

> But that is not representative of a real app

Many, many real apps process millions of events per second. You may not have worked on any of them but that does not mean they don't exist.

My wife started snoring pretty badly while she was pregnant so ended up buying these earplugs https://www.amazon.com/dp/B0DPH7HNT1. I've never been able to sleep in the foam earplugs as they either fall out or the pressure starts to really irritate after a while, but these don't put pressure and they stay in all night. They're also really block out noise.

The CIA triad is a framework for threat modeling, not a threat model in and of itself. And what those specific terms mean will also be very system-specific.

That seems a bit circular to me. Of course you distrust someone you think is lying to you or manipulating you. That is what distrust means isn't it? The question is why you think you are being lied to or manipulated to begin with.

I think the answer is obvious, no? Because there may be products that can make your life better but you don't know about them. It's a bit like asking "why would you ever want a medical treatment you didn't know existed?" Because I, not being a doctor, don't know of the existence of most medical treatments but some may be able to cure diseases or other ailments I have.

For me, the killer features were the metaprogramming abilities (both type and macro based). Not so much because I used them directly but because they allowed library authors to create extremely expressive libraries.

I think the use case is mostly dev servers, either remote machines running in the cloud or docker containers running locally. I don't use VSCode much, but the one thing I do use it for is when I need to do something linux-specific. I spin up a linux VM on my MacBook and use VSCode to remote into the VM.

I spent 10 years or so mostly writing Scala and now am entirely using Rust. I found the transition really easy. Where I work now has historically been a Scala shop and is moving more and more towards Rust as the default. In my experience engineers who are seasoned Scala devs pick it up very quickly

Asking if the implication is true that having more dependencies is on net bad for security for a complex system. The alternative being reimplementing whatever you would otherwise pull in a third-party dependency for. On the one hand, you reduce the attack surface in your supply chain. On the other hand you run the risk of introducing security bugs in the code you write that is outside your domain of expertise. It's not at all clear to me which one would be more important.

Is it? You know for a fact that there are bugs in some of your dependencies. But how many bugs would the code you wrote from scratch instead of adding a dependency have?