JackYoustra

Is this not the same thing?

No, it sounds like mythos is just doing parallel trajectories. that's pretty distinct!

> Isolated the relevant code

I mean isn't that most of it? If you put a snippet of code in front of me and said "there's probably a vulnerability here" I could probably spend a few hours (a much lower METR time!) and find it. It's a whole other ballgame to ask me with no context to come up with an exploit.

nit: it's a zettaflops, not a zettaflop

fun fact kropotkin's entire thesis was "yeah so this is wrong social darwinism is always motivated reasoning"

and you can see it in your thing! Environmentalism is good because it turns out burning millions of years of information as well as our only source of medicine and life sciences is not worth you feeling persecuted because you wanted to have a dirt bike that smells awful.

It's sure not cost anymore! LCOE of solar is the lowest!

AI systems far weaker than GPT-2 have had terrible effects. The result of how information and power is distributed mostly flows along the lines of reward hacking recommendation engines, powered by even weaker models.

And yet, somehow, it is beyond disagreeable but unbelievable that other people may have and may still reasonably believe that these things are too dangerous for widespread release?

century energy ransomware no?

What would Trump have to do for you to not give him the benefit of the doubt from that point forward?

Well yeah social trust is worse in autocracies, you'd imagine that corruption would be lower on the list of problems you perceive having when 1) you don't have a good press to report on them 2) you can be sent to jail basically wherever

like people in democracies do not know how good they have it!

The answer to this is just changing the law as enforcement becomes different, instead of leaning on the rule of a few people to determine what the appropriate level of enforcement is.

To do this, though, you're going to have to get rid of veto points! A bit hard in our disastrously constitutional system.

Because noncitizens can be motivated or not and / or resign and, frankly, there isn't that deep of a well of top tier AI talent. The threat of mass resignations led to OAI re-hiring sam altman, after all.

Also why would the department of war care about what citizens think specifically?

I'm sorry I read this a lot and this is kind of an insane thing to say? Classified OLC memos giving legal cover to any military action has been a fixture for the last over twenty years! Congress never abdicated power, it just, by the nature of the constitution, practically has SO much less power than the president! The president is a single person that people elect, they expect the person to be a leader, and congress will always, always play a following role so long as the president has unilateral power over the military, is directly elected, and just in general has expansive interpreting authority over laws.

You know who doesn't have as much power? The swiss head of state, so weak you can't even reliably name them! THATS what it looks like to defeat personalization, not some hand wringing hoping a system does something that it wasn't designed to do.

Then you would get zero H1B and, frankly, green card signatures. There is real risk and real dependents at stake, I understand people who can't in good conscience put that at risk.

tbh mostly dismissive of Scott Alexander for fun, couldn't quite help myself

> researchers

that's certainly one way to refer to Scott Alexander

Data centers in space make sense because its nigh impossible to build things terrestrially. NIMBYism is so out of control the largest solar array in the US in the middle of the mojave got cancelled because it would interfere with the view.

"Just change the law" ok sure we'll get right on it.

iirc you can't do this for extensions which being a huge amount of compiler constraint resolution time

As your app scales, you're going to want to break out different parts into their own packages in order to keep compile times in check, so you're gonna be forced to go through SPM unless you use tuist or bazel.

You can't really easily use explicit types in much of idiomatic SwiftUI. The expression that the compiler is trying to solve is really complicated, I agree, but the solution to that is either changing how SwiftUI is architected or restricting how the language built on SwiftUI infers types.

Hijacking your comment because this is a common point that's made on the superiority of Swift syntax against the union syntax.

At least with |, you're attempting to model the state space. You're saying "this is one of these things." You might get the exhaustiveness wrong, but you're in the right ballpark. As it's normally done right now, the Swift developer with five optional properties is modeling state as "maybe this, maybe that, maybe both, who knows, good luck." which is just worse than a bar. If you need to discriminate explicitly, add a `__kind` field!

If you look at most swiftui views, there will be a mass of optionals, rather than enum cases for every possible state that the view can occupy and a state machine transitioning between each state.

If you actually try and write it all out (like go full-on and use TCA to model all the states and actions such that all and only valid states can be represented in the state types) the compiler is going to have a hard time, you're going to write masses of boilerplate, and just in general it's much rougher than zustand and expo.

Xcode (and as of a couple years ago the vscode spm integration) tends to have difficulty when scaling this solution.

Being explicit with types is very disruptive when used in SwiftUI or TCA.

Adding on, its also a bit much to say that Swift has a good level of sugar and reference an enum of all things. Swift's union type story is so poor that, instead of properly modeling state, people to this day still use masses of optional types in their views rather than an enum because actually using swift enums and protocols is so painful.

You can develop Swift without it. I assume you mean SwiftUI / apple's sdk, which is what most people assume (a note, I'd say, to advocates of Swift who wish not to address SwiftUI: it's the biggest target, and its poor performance on it should speak volumes about the language).

You can also sometimes avoid xcode, see https://github.com/xtool-org/xtool

although, at this point, just use expo!

Broadly agree but, as is most things, the devil is in the details!

- Xcode. A really rough ide that has a hard time at scale, choking on package refreshes, many targets, and more. It has a special entitlement so you can't even binary patch it if you want to fix it!

- Build systems. Cargo is _much_ easier to work with than SPM.

- Macros support, codegen is still largely done outside of the macro system, which should indicate its use.

- Linter / format support. Yeah, it exists, last I checked it's just a good bit worse.

- Performance. There are MANY performance cliffs in Swift; most can be fixed by a sufficiently determined compiler developer, but at this point we've kinda departed talking about the language as-is.

- Type inference time. Swift's bidirectional type inference causes a ton of choking on complex expressions, which is a real problem with its number one use case, SwiftUI.

- An exacerbating factor on the above, imports are all implicitly module-scoped, meaning that changing a single file means recomputing the types for all files in the module. And because SPM and Xcode have such a rough time with multiple targets, that usually means that a single change can lead to recompiling all Swift files.

- Weirdness around classes and structs? I understand that they had to do it for objc compatibility, but I would've found it much cleaner if they'd just from the start had something replacing class, like a fully-sugared `final class Box<T>` that replaces all uses of class.

I agree that for the most part it _could_ be an easier rust, but between including bidirectional type inference without a cut operator and poor tooling I struggle to find where it's actually easier in cases that you can't just use typescript and dodge all the non-typecheck compilation headaches entirely.

Because white supremacists are, from some abstract level, undesirable? And some have white supremacist tendencies, so there has to be some way of, at the very least, ignoring them and ensuring that its possible to ignore them.

> The former is abusing the latter as a pretext for a (social) lynch mob.

what would your alternative be?

SwiftUI is almost certainly the biggest application of Swift; even if we relax it to just iOS applications you'll see the same issues appear with invalid state combinations.

I agree that you should evaluate languages in their domains. At the end of the day, Swift is mainly used for systems and iOS apps. In this, it is inadequate, as you can tell by, again, most apps not using the type system to enumerate valid views but instead (because enums and union types more broadly are so clunky to use!) masses of uncoupled types in their views, allowing for many, many implicitly invalid states.

I mean there should be _some_ sugar in a language like swift, no? It has sugar in many parts of the language, being able to define a simple type union should not require custom declaration of every forwarding accessor, a protocol, an enum, bridging back and forth between them, etc.

It would be one thing to say that the vertical bar is a shortcut for these more exhaustive constructs (setting aside whether these constructs are actually exhaustive - they're not really for the purposes they're used for in practice), but as it is right now, you have no bar! If it were simple and easy to use you'd have enums dictate the state of every app which, as any app developer knows, is not how its currently done! Swift enums are so hard to use you have just a mess of optionals on view state instead of how it should formally be done, where almost every non-trivial view has a single state that's an enum of all possible configurations of valid states.

Indeed, if you put in a ton of effort to try and go down this route defining views "properly" with something like Swift TCA, you're not going to be able to get there even if you break up your app into 40 different targets because incremental recompilation will take a few minutes for something as simple as a color change.