thinkharderdev

55% chance for a $10 payout; 45% chance to lose $10. You would keep on rolling that die, right?

The answer is that it depends? If I have $1B then yeah I would roll the dice and keep rolling as long as they let me. If I have $100? Maybe not because you can go very easily go broke even if each bet is positive EV.

Honestly asking for any specific number is a deeply weird and off-putting question to ask.

I'm in my early forties and both my parents worked (as did all my neighborhood friend's parents) and we still spent a lot of time wandering around. Honestly I think people are really overthinking this. We spent a lot of time wandering around outside because we were bored. Now kids have an endless well of entertainment to choose from so staying at home is a much more appealing option. It's always tempting to romanticize your childhood but if I'm being honest, most of that time wandering around outside I was bored out of my skull. I was just marginally less bored than I would have been sitting at home.

The best endurance runners run in such a way that their feet land on the front of their foot during running

This is not really true and the whole fore foot vs heal striker thing is a bit of a red herring. There are elite distance runners that are forefoot, mid-foot (probably the majority) and heal strikers. The main thing is that wherever on their foot hits first, the foot itself is under their center of gravity and not out in front of them.

Congratulations on getting back in shape. Just here to say that there is no such thing as ramping up too slowly when getting into (or back into running). So many people push too hard too fast and flame out.

Sure, findings ways to burn tokens is not hard. Even finding ways to burn tokens on things (like your example) which are actually useful is not hard. But what is the ROI on that from the company perspective. I mean, you could have also hired an intern to do the job of collating this report every week. But if you went to your boss and asked to hire someone to do something, they would, reasonably, ask what the value of that thing is and whether it justifies more headcount. But we're in this bizarro world where the bosses are basically saying "go hire more people, even if you don't have specific high-value things for them to do. Just create make-work jobs for them!" It's wild.

The Grand Canyon review is spot on though.

The review of the Grand Canyon annoyed me the most:

``` Can you hike in the Grand Canyon? Yes, technically. You can walk along the rim, but the view won’t change; same damn canyon on one side, same damn parking lot on the other. There are trails that go down into the canyon, but they’re a trap ```

So you can't even hike there, except of course for the hike that you can do.

"They are featureless steep inclines formed into endless switchbacks, and when they finally end, there’s nothing to do except go back up"

That is what hiking is! Granted, usually you hike up and then back down. And I wouldn't call the hike down into the canyon "featureless". Honestly, it sounds like this person just doesn't really like hiking, which if fine it's not for everyone, but that is just what there is to do in most national parks.

Same, but it's configurable in slack so now I have it configured the Enter inserts a line break and Cmd+Enter submits the message

Mr Back is already a very public figure in the bitcoin/crypto community who is the face of a public company. This isn't some rando who nobody has ever heard of before.

Because in this particular case it endangers subject's life.

This seems like a stretch. Mr Back is already a well-known wealthy person who (presumably) owns lots of crypto. I think it's a stretch to think this article significantly increase the danger to his life.

I mean, yeah? We can wag our fingers about what people find interesting but it is what it is. Bitcoin is an important technology in the world, and people are interested in who the inventor is. You may think it doesn't matter, but clearly a lot of people disagree.

This one is challenging I think because the article itself is so thin. The evidence seems really shaky.

That said, clearly a lot of people really do seem to care who Satoshi is, so it doesn't seem like its out of the question for a newspaper to print an article claiming to answer that question.

Do they just not care about the ethical implications?

Did Satoshi not care about the ethical implications of creating bitcoin? Mr Back may not be Satoshi, but he's also made a career driving the adoption of bitcoin and bitcoin itself has enabled many, many terrible crimes. It seems like special pleading to argue that Mr Back is not responsible for any of the consequence of bitcoin in the world, and also that the NY Times is morally responsible if someone harms Mr Back because they think he is Satoshi. Either we have an ethical responsibility to consider the consequences of our actions or we don't.

I agree there's a sort of "who cares" aspect to the piece

Sure, rationally I agree, but clearly a lot of people do care. It may not matter in any substantive way who Satoshi is but people still care.

There is no artistic intent to interpret

Is that the case? Obviously there is no artistic intent as bitcoin is not art, but it's not clear to me why the intent of an artist is important but the intent of a technologist is not.

I think they are saying what you want them to say. In the past they got a bunch of AI slop and now they are getting a lot of legit bug reports. The implication being that the AI got better at finding (and writing reports of) real bugs.

Are you saying Maccy was vibe-coded or that it was written in Python? I don't think either are true. I've definitely been using it (you're right, it's great!) since before vibe-coding was a thing. And looking at the GitHub it seems to be 100% in Swift.

It's like a C fanatic saying "No useful software can be made using Python", and then asking for a counterexample

At which point you could provide them many, many counterexamples?

I like AI coding assistants as much as the next red-blooded SWE and find them incredibly useful and a genuine productivity booster, but I think the claims of 10/100/1000x productivity boosts are unsupported by evidence AFAICT. And I certainly know I'm not 10x as productive nor do any of my teammates who have embraced AI seem to be 10x more productive.

This is flat-earther level

Ok, so do you have a counterexample?

This will obviously depend on which implementation you use. Using the rust arrow-rs crate you at least get panics when you overflow max buffer sizes. But one of my enduring annoyances with arrow is that they use signed integer types for buffer offsets and the like. I understand why it has to be that way since it's intended to be cross-language and not all languages have unsigned integer types. But it does lead to lots of very weird bugs when you are working in a native language and casting back and forth from signed to unsigned types. I spent a very frustrating day tracking down this one in particular https://github.com/apache/datafusion/issues/15967

There's an old saying among cyclists attributed to Greg Lemond: "It doesn't get easier, you just go faster"

Keep in mind, our parents (age specific) and/or their parents parents paid for news and didn't question that setup

I don't think this is quite right. Our parents paid for the newspaper but the newspaper was basically the internet of their time. That is where they got sports scores, movie/tv listings, etc. The fact that this was bundled with hard news was mostly a side-effect.

To have better performance in benchmarks

Yes, exactly.

That makes sense. I don't know anything about embedded programming really but I thought that it really fundamentally requires async (in the conceptual sense). So you have to structure your program as an event loop no matter what. Wasn't the alleged goal of rust async to be zero-cost in the sense that the program transformation of a future ends up being roughly what you would write by hand if you have to hand-roll a state machine? Of course the runtime itself requires a runtime and I get why something like Tokio would be a non-started in embedded environments, but you can still hand-roll the core runtime and structure the rest of the code with async/await right? Or are you saying that the generated code even without the runtime is too heavy for an embedded environment?

Except a consumer can discard an unprocessable record?

It's not the unproccessable records that are the problem it is the records that are very slow to process (for whatever reason).

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