mh2266

the scrollbar change happened in 10.7 Lion. it was released in 2011. on mobile it was there since iPhone OS 1. it is not a recent change, macOS/OS X/Mac OS X has had these scrollbars for longer than it did not have them.

you can disable them in the settings app, and have been able to since Lion...

are LLM codebases not messy?

Claude by default, unless I tell it not to, will write stuff like:

    // we need something to be true
    somethingPasses = something()
    if (!somethingPasses) {
        return false
    }

    // we need somethingElse to be true
    somethingElsePasses = somethingElse()
    if (!somethingElsePasses) {
        return false
    }

    return true

instead of the very simple boolean logic that could express this in one line, with the "this code does what it obviously does" comments added all over the place.

generally unless you tell it not to, it does things in very verbose ways that most humans would never do, and since there's an infinite number of ways that it can invent absurd verbosity, it is hard to preemptively prompt against all of them.

to be clear, I am getting a huge amount of value out of it for executing a bunch of large refactors and "modernization" of a (really) big legacy codebase at scale and in parallel. but it's not outputting the sort of code that I see when someone prompts it "build a new feature ...", and a big part of my prompts is screaming at it not to do certain things or to refuse the task if it at any point becomes unsure.

I don't exactly disagree with this but I have seen models simply deleting the tests, or updating the tests to pass and declaring the failures were "unrelated to my changes", so it helpfully fixed them

> I've been trying to implement a multiplayer game with server authoritative networking in Rust with Bevy. I specifically chose Bevy as the latest version was after Claude's cut off, it had a number of breaking changes, and there aren't a lot of deep examples online.

I am interested in doing something similar (Bevy. not multiplayer).

I had the thought that you ought be able to provide a cargo doc or rust-analyzer equivalent over MCP? This... must exist?

I'm also curious how you test if the game is, um... fun? Maybe it doesn't apply so much for a multiplayer game, I'm thinking of stuff like the enemy patterns and timings in a soulslike, Zelda, etc.

I did use ChatGPT to get some rendering code for a retro RCT/SimCity-style terrain mesh in Bevy and it basically worked, though several times I had to tell it "yeah uh nothing shows up", at which point is said "of course! the problem is..." and then I learned about mesh winding, fine, okay... felt like I was in over my head and decided to go to a 2D game instead so didn't pursue that further.

Is there any type of clothing that existed in the 1800s that you could actually not buy or have custom made today?

On the other hand, you could not buy a Gore-Tex Pro shell or an ultralight down jacket for any price in 1800.

put a `git` script in `PATH` that simply errors out i.e.:

    if "--no-verify" in sys.args:
        println("--no-verify is not allowed, file=sys.stderr)
        sys.exit(1)

and otherwise forwards to the underlying `git`

> Exactly, designing a 'third place' that isn't alcohol focused seems to be a tough nut to crack.

how so? I go to a climbing gym and it is a pretty social (and, of course, healthy) activity... crossfit is not my thing but apparently it is similar for more traditional workouts. to the extent you can consider a cycling or running club a "space" those are similar. dog parks for dog owners, playgrounds for parents, etc...

> They bet the house on liquid glass

How? If they reverted to the previous iOS and macOS designs, Apple would go out of business?

cigarettes are an explicit part of the diet...?

is there some reason to implement it as a time limit instead of iterations or something else deterministic? it being affected by CPU speed or machine load seems obvious.

or whatever makes sense if “iterations” isn’t a thing, I know nothing about chess algorithms

Yes, of course, but the actual games are written (primarily! sometimes they will optimize something when actually necessary with a lower-level language! that's great!) in the scripting language.

The OP implies heavily that writing a program in a language with anything but pure manual memory management makes you lesser as a programmer than him: "Unfortunately, a lot of people never move past this point on their journey as a programmer" implies he has moved further on in his "journey" than those that dare to use a language with GC.

(and with respect to C++ note that OP considers RAII to be deficient in the same way as GC and ARC)

The section "The Problem of the Individual-Element Mindset" bugs me quite a bit, the core of it being:

> This architectural mindset does lead to loads of problems as a project scales. Unfortunately, a lot of people never move past this point on their journey as a programmer. Sometimes they do not move past this point as they only program in a language with automatic memory management (e.g. garbage collection or automatic reference counting), and when you are in such a language, you pretty much never think about these aspects as much.

Billions of dollars worth of useful software has been shipped in languages with garbage collection or ARC: roughly the entire Android (JVM) and iOS (ARC) application ecosystems, massively successful websites built on top of JVM languages, Python (Instagram etc.), PHP (Wikipedia, Facebook, ...).

In game development specifically, since there's a Casey Muratori video linked here, we have the entire Unity engine set of games written in garbage-collected C#, including a freaking BAFTA winner in Outer Wilds. Casey, meanwhile, has worked on a low-level game development video series for a decade and... never actually shipped a game?

Right, he says:

> If you want to make pointers not have a nil state by default, this requires one of two possibilities: requiring the programmer to test every pointer on use, or assume pointers cannot be nil. The former is really annoying, and the latter requires something which I did not want to do (which you will most likely not agree with just because it doesn’t seem like a bad thing from the start): explicit initialization of every value everywhere.

In Kotlin (and Rust, Swift, ...) these are not the only options. You can check a pointer/reference once, and then use it as a non-nullable type afterwards. And if you don't want to do that, you can just add !!/!/unwrap: you are just forced to explicitly acknowledge that you might blow up the entire app.

stacked diffs are the best approach and working at a company that uses them and reading about the "pull request" workflow that everyone else subjects themselves to makes me wonder why everyone is not using stacked diffs instead of repeating this "squash vs. not squash" debate eternally.

every commit is reviewed individually. every commit must have a meaningful message, no "wip fix whatever" nonsense. every commit must pass CI. every commit is pushed to master in order.

This just skips the:

> First, if you aren't writing device drivers/kernels or something very low level there is a high probability your program will have zero unsafe usages in it.

from the original comment. Meanwhile all C code is implicitly “unsafe”. Rust at least makes it explicit!

But even if you ignore memory safety issues bypassed by unsafe, Rust forces you to handle errors, it doesn’t let you blow up on null pointers with no compiler protection, it allows you to represent your data exhaustively with sum types, etc etc etc

The only thing I really found weird syntactically when learning it was the single quote for lifetimes because it looks like it’s an unmatched character literal. Other than that it’s a pretty normal curly-braces language, & comes from C++, generic constraints look like plenty of other languages.

Of course the borrow checker and when you use lifetimes can be complex to learn, especially if you’re coming from GC-land, just the language syntax isn’t really that weird.

I feel like it is the opposite, Go gives you a ton of rope to hang yourself with and hopefully you will notice that you did: error handing is essentially optional, there are no sum types and no exhaustiveness checks, the stdlib does things like assume filepaths are valid strings, if you forget to assign something it just becomes zero regardless of whether it’s semantically reasonable for your program to do that, no nullability checking enforcement for pointers, etc.

Rust OTOH is obsessively precise about enforcing these sort of things.

Of course Rust has a lot of features and compiles slower.

I think the standard convention if you just want a stringly-typed error like Go is anyhow?

And maybe not quite as standard, but thiserror if you don’t want a stringly-typed error?

Management not being a promotion doesn’t mean that managers aren’t (usually—I’ve both been at equal and higher levels than my managers at times) higher levels than their reports. It means that switching to a management role from IC is never a promotion itself (ie always L6 -> M1 in Google/Meta levels) and it never comes with any difference in compensation.

Google’s terminal level is one past new grad and it has a full parallel non-management IC track, I don’t think that they’re pushing people that hard into leadership roles.

Google lets people stay at L4 forever and Meta does at L5 with no expectation of further growth.

Yes the expectations are probably still higher, but these companies don’t expect everyone to grow past “mostly self-sufficient engineer” as the parent comment suggests, and for people that do want to do that there’s a full non-management path to director-equivalent IC levels. My impression is that small companies are more likely to treat management as a promotion rather than as a lateral move to a different track (whenever I hear “promoted to manager” I kinda shudder)

I don’t think being popular with the players is entirely irrelevant for players in team sports. Locker room cohesion matters.

It’s a little snarky and cynical but I’ve found little use for product managers in infra and devx teams because they typically don’t have the technical background to have relevant product vision and anyone that can make L7+ as an engineer on this sort of team should be able to figure out what the product should be.

This is different in a product team because engineers aren’t the customers, although I’d still argue anyone senior in a product engineering team should still have at least some product sense.

This completely matches my experience as an infra principal engineer in a coding archetype at another big company. I do impactful and good technical work and always try to defer credit to those “under” me even if it was my idea they are implementing. As long as my manager knows it was my idea everything works out fine.

That being said you do kind of end up in the spotlight anyways but it feels very different to do it through reputation of knowledge and technical competence rather than through PR-like selling.