thinkharderdev

> If it were written with async it would likely have enough other baggage that it wouldn't fit or otherwise wouldn't work

I'm unclear what this means. What is the other baggage in this context?

Right, because this would deadlock. But it seems like Zig would have the same issue. If I am running something in a evented IO system and then I try and do some blocking IO inside it then I will get a deadlock. The idea that you can write libraries that are agnostic to the asynchronous runtime seems fanciful to me beyond trivial examples.

Honestly I don't see how that is different than how it works in Rust. Synchronous code is a proper subset of asynchronous code. If you have a streaming API then you can have an implementation that works in a synchronous way with no overhead if you want. For example, if you already have the whole buffer in memory sometimes then you can just use it and the stream will work exactly like a loop that you would write in the sync version.

> The problem is I still have some of their clothes I bought 10 years ago and their quality trumps premium brands now.

I'm skeptical of this claim. Maybe it's true for some particular brand but that's just an artifact of one particular "premium brand" essentially cashing in its brand equity by reducing quality while (temporarily) being able to command a premium price. But it is easier now than at any other time in my life to purchase high-quality clothing that is built to last for decades. You just have to pay for that quality, which is something a lot of people don't want to do.

> It's good to know that OOTB duckdb can replace snowflake et all in these situations, especially with how expensive they are.

Does this article demonstrate that though? I get, and agree, that a lot of people are using "big data" tools for datasets that are way too small to require it. But this article consists of exactly one very simple aggregation query. And even then it takes 16m to run (in the best case). As others have mentioned the long execution time is almost certainly dominated by IO because of limited network bandwidth, but network bandwidth is one of the resources you get more of in a distributed computing environment.

But my bigger issue is just that real analytical queries are often quite a bit more complicated than a simple count by timestamp. As soon as you start adding non-trivial compute to query, or multiple joins (and g*d forbid you have a nested-loop join in there somewhere), or sorting then the single node execution time is going to explode.

This depends a lot of what you are using exceptions for. I think in general the branch on Ok/Err is probably not meaningful performance-wise because the branch predictor will see right through that.

But more generally the happy-path/error-path distinction can be a bit murky. From my days writing Java back in the day it was very common to see code where checked exceptions were used as a sort of control flow mechanism, so you end up using the slow path relatively frequently because it was just how you handled certain expected conditions that were arbitrarily designated as "exceptions". The idea behind Result types to me is just that recoverable, expected errors are part of the program's control flow and should be handled through normal code and not some side-channel. Exceptions/panics should be used only for actually exceptional conditions (programming errors which break some expected invariant of the system) and immediately terminate the unit of work that experienced the exception.

Happened to me. Bought a house with wood floors in the basement. We had some flooding which ruined the wood and when we ripped it out to replace, turns out the wood floors were installed over the original asbestos tiles. From what I can tell, the asbestos tiles themselves were of no particular danger to us, but once they got wet and started cracking they had to be removed which cost an additional couple thousand dollars on top of replacing he floors.

Yes

Trump is definitely the most egregious by a very wide margin, but the pardon power has been abused by every President in my lifetime. It's a truly insane feature of our constitution that needs to be changed.

I interviewed with Amazon a few years back. The whole thing turned me off. A recruiter reached out and I was interested (it was late 2020 and the money was tempting). But before the first phone screen I had to have a call with the recruiter again, where she gave me a list of things I needed to "study" and was told that "successfully candidates usually spend 5-10 hours preparing for the interview". The study list was the usual list of CS101 topics. I didn't bother preparing and it was a good thing because on the phone screen the guy just asked me some a fairly mundane coding question and then some more general stuff (it was actually a very reasonable interview). Based on that they wanted to proceed to a final interview which was an all-day affair (on zoom of course because this was during the pandemic). But first I had to do ANOTHER 1h call with the recruiter where she gave me ANOTHER list of things I needed to "study" and reminded me that I should spend 5-10h preparing. That was too much for me and I politely declined the opportunity.

> Also, does it use doubly linked lists or graphs at all? Those can, in a way, be safer in C since Rust makes you roll your own virtual pointer arena.

You can implement a linked list in Rust the same as you would in C using raw pointers and some unsafe code. In fact there is one in the standard library.

How does this work in two-party consent states. IANAL but as I understand it, you need to permission to record someone in California.

As an aside, I don't consider myself a particularly paranoid person (relative to the median HN commenter, I'm probably still in the 95th percentile of paranoid-ness in the general population), but I couldn't imagine ever wearing a device that records my entire life and uploads it to Meta of all companies....

Sure, any program can have bugs. The point though is that it is "just a bug" and not UB.

> doesn't mean you're not stomping on in-bounds neighboring data

I don't see how you would do that in safe rust though. The point of the arena would just be to solve the lifetime issue. It just moves the ownership problem one level higher. Instead of having circular ownership in a linked list, all linked list nodes are owned by the arena and hence have the same lifetime as the arena.

The main reason is that arrow files are not compressed at all. So storing everything as Arrow would increase storage size by 10-100x (depending on data)

I took the article to be saying that mpmc queues are not queues so we can use bags instead because bags are faster. The second claim seems dubious to me though. I checked out the repo which led me to https://alexsaveau.dev/blog/opinions/performance/lockness/at... which proposes new CPU instructions to create atomic bitmasks. As the author notes, the bag structure breaks down a bit because you have to operate on the bit mask with atomic operations which will contend heavily with each other.

> As long as the audience accepts the framing that ergonomics doesn't matter because it can't be quantified, the hand-waving exemplified above will confound.

I interpreted the parent to be saying that ergonomics IS (at least partly) subjective. The subjective aspect is "what you are used to". And once you get used to Rust its ergonomics are fine, something I agree with having used Rust for a few years now.

> The Rust community should be upfront about this tradeoff

I think they are. But more to the point, I think that safety is not really something you can reasonably "trade-off", at least not for non-toy software. And I think that because I don't really see C/C++/Zig people saying "we're trading off safety for developer productivity/performance/etc". I see them saying "we can write safe code in an unsafe language by being really careful and having a good process". Maybe they're right, but I'm skeptical based on the never-ending proliferation of memory safety issues in C/C++ code.

I read this article earlier today and ended up going down a rabbit hole trying to figure out what Xanadu actually "is" (on a more technical level) but haven't really been able to find much. Does anyone have a good resource for understanding the details?

The basic tradeoff is that you are paying an extra tax on all requests that are not served by the cache, so you something like this would help if you are reading the same data repeatedly. So, for example, a database built on object storage or something like that.

I'm not a fan of tipping in general, but as an American who has spent a lot of time in Europe, my experience is that the level of service in American restaurants is quite a bit higher than in European ones on average. That's not to say that in Europe it's bad service per se, and in certain ways I actually prefer it in Europe where the server isn't constantly "checking in" on me while I'm trying to have dinner.

Is this also the case for senior executives?

> I can have the call in the background while looking at something else without it being impolite. I can eat, drink, or use the restroom at will.

This works great when you are one of a dozen anonymous people on a zoom call. less so when you are the senior person in the meeting who everyone is actually talking to and expecting you to make a decision.

But this response kind of proves my point. If you are the principal in a meeting, the fact that everyone else in the meeting is zoned out and doing something else is not great.

> I think at some point, it's just inevitable that C-level management takes decisions based on the assumption that people are replaceable and that the difference between a great performer and a poor performer is essentially irrelevant.

Maybe, but I find it hard to believe that someone who has spent their entire career in the tech industry actually believes this.

The "backdoor layoffs" theory seems suspect to me more generally. It's not like they're particularly averse to doing layoffs the normal way. Especially now where the signal from big tech company doing layoffs is "we're really good at AI".

My personal pet theory (based on no evidence other than personal experience) is that, if your job is in senior management then your day-to-day work is going to meetings. And spending 8-10h on zoom meetings every day is unbelievably soul-crushing.

Yeah, back when I used to swim a lot I could never find anything that was any good at tracking swim distance either in a pool or open water.

I'm not hypochondriac and don't use any of the health monitoring features. What I use it for:

* Notifications (imessages mainly, but anything that sends a push notification to your phone can also notify you on your watch)

* Quickly responding (thumbs up/down) to messages

* Apple Pay

* HomeKey (I can unlock all the doors in my house with my watch)

* Some apps (like AllTrails) have nice watchOS apps which give you the important info by glancing at your wrist.

Sure, you just have to balance that against the cost of a poorly specified API interface. The errors because clients aren't clear on what is really required or not, what they should consider an error if it is not defined, etc. And of course all the boilerplate code that you have to write to convert the interface model to an internal domain model you can actually use inside your code.

> Philosophically, checking that a field is required or not is data validation and doesn't have anything to do with serialization

But protocol buffers is not just a serialization format it is an interface definition language. And not being able to communicate that a field is required or not is very limiting. Sometimes things are required to process a message. If you need to add a new field but be able to process older versions of the message where the field wasn't required (or didn't exist) then you can just add it as optional.

I understand that in some situations you have very hard compatibility requirements and it makes sense to make everything optional and deal with it in application code, but adding a required attribute to fields doesn't stop you from doing that. You can still just make everything optional. You can even add a CI lint that prevents people from merging code with required fields. But making required fields illegal at the interface definition level just strikes me as killing a fly with a bazooka.

> Then it's not really required if it can be ignored.

It can be required in v2 but not in v1 which was my point. If the client is running v2 while the server is still on v1 temporarily, then there is no problem. The server just ignores the new field until it is upgraded.

> This is the problem, software (and protos) can live for a long time). They might be used by other clients elsewhere that you don't control. What you thought might not required 10 years down the line is not anymore. What you "think" is not a huge deal then becomes a huge deal and can cause downtime.

Part of this is just that trying to create a format that is suitable both as an rpc wire serialization format and ALSO a format suitable for long term storage leads to something that is not great for either use case. But even taking that into account, RDBMS have been dealing with this problem for decades and every RDBMS lets you define fields as non-nullable.

> If a message is required for an interface to function, you should be checking it anyway and returning the correct error. How is that change with proto supporting require?

That's my point, you have to do that check in code which clutters the implementation with validation noise. That and you often can't use the wire message in your internal domain model since you now have to do that defensive null-check everywhere the object is used.

Aside from that, protocol buffers are an interface definition language so should be able to encode some of the validation logic at least (make invalid states unrepresentable and all that). If you are just looking at the proto IDL you have no way of knowing whether a field is really required or not because there is no way to specify that.

But this is something you should be able to handle on a case-by-case basis. If you have a type which is stored durably as protobuf then adding required fields is much harder. But if you are just dealing with transient rpc messages then it can be done relatively easily in a two step process. First you add the field as optional and then once all producers are upgraded (and setting the new field), make it required. It's annoying for sure but still seems better than having everything optional always and needing to deal with that in application code everywhere.