However I think assuming that Israel violating the ceasefire (as they have done multiple times in the past) is more reasonable than assuming a country with a ~400B GDP (similar to Hong Kong, Portugal) has leaders that "can't read".

[1] https://x.com/mb_ghalibaf/status/2041943537386958858

2. Iranians can't read.

Which do you think is more likely?

What is your use case for Flighty, and why would this information be important at all?

Both GCP and Gemini are products of this. Modern cloud was arguably built by Google (think Chubby, GFS, Bigtable as building blocks) - they just spent 10 years ceding it to Amazon before competing.

I doubt for other newer games the option would ever be worth it. Why host to servers and matchmaking pools for a tiny player base, who is will probably already be prone to complaining?

Anti-cheat is not used to "protect" bronze level games. FACEIT uses a kernel level anti cheat, and FACEIT is primarily used by the top 1% of CS2 players.

A lot of the "just do something else" crowd neglects to realize that anticheat is designed to protect the integrity of the game at the highest levels of play. If the methods you described were adequate, the best players wouldn't willingly install FACEIT - they would just stick with VAC which is user-level.

The Google Deepminds are incredibly smart - I just find it important to point out that the xAI guys spent a year assured they would beat Google because they slept in tents that they made in the office.

xAI (and Twitter) was the loudest about six-hour workdays, sleeping in the office, and always shipping. ~2 years later it feels like they have nothing to show for it. I'm sure the engineers at Google worked 4 days a week, 2 hours a day, with half of that being spent at the Google cafeteria and they dusted xAI years ago.

1. Go with a better type system. A compiled language, that has sum types, no-nil, and generics.

2. A widely used, production, systems language that implements PL-theory up until the year ~2000. (Effects, as described in this article, was a research topic in 1999).

I started with (1), but as I started to get more and more exposed to (2), you start looking back on times when you fought with the type system and how some of these PL-nerds have a point. I think my first foray into Higher-Kinded Types was trying to rewrite a dynamic python dispatch system into Rust while keeping types at compile time.

The problem is, many of these PL-nerd concepts are rare and kind of hard to grok at first, and I can easily see them scaring people off from the language. However I think once you understand how they work, and the PL-nerds dumb down the language, I think most people will come around to them. Concepts like "sum types" and "monads", are IMO easy to understand concepts with dumb names, and even more complex standard definitions.

We are currently in a thread, where a major application has a heap corruption error in its CSS parser, and it's not even rare for such errors to occur. This doesn't seem true.

>But automated package managers etc can bring in code under the covers, and you end up with something you didn't ask for.

Last year there was a backdoor inserted into xz that was only caught because someone thought their CPU usage a little too high. I don't think the whole "C is safer because people don't use dependencies" is actually sound.

What it actually is, if the car gets stuck someone can manually override - which, I imagine is normal? If the car gets stuck you can call someone and they can do "something", which can probably nudge the car into action. I doubt the latency is that good where someone can remotely drive the car.

I don't think this will happen - or rather I don't think you can ask someone, human or machine, to come in and "compact and clean" your codebase. What is "clean" code depends on your assumptions, constraints, and a guess about what the future will require.

Modularity where none is required becomes boilerplate. Over-rigidity becomes spaghetti codes and "hacks". Deciding what should be modular and what should be constant requires some imagination about what the future might bring and that requires planning.

Opus 4.5 changed that and like every programming tool I've used in the past, I decided to sit seriously with it and try and learn how to use it. If coding agents turn out to be a bust, then oh well, it goes into the graveyard of shit I've learned that has gone nowhere (Angular, Coffeescript, various NoSQL databases, various "big data" frameworks). Even now one of my favorite languages is Rust, but I really took the plunge into the language before async/await and people also called it overhyped.

If coding agents are real, I don't want to be struggling to learn how to use them while everyone else is being 10x more productive. There's no downside to learning how to use them for me. I've invested my time in many hyped software frameworks, some good and some bad.

There is a real advantage to having good code especially when using agents. "Good Code" makes iteration faster, the agent is unlikely to make mistakes and will continue to produce extensible code that can easily be debugged (by both you and the agent).

A couple months ago I refactored a module that had gotten unweildly, and I tried to test if Claude could add new features on the old code. Opus 4.5 just could not add the feature in the legacy module (which was a monster function that just got feature-crept), but was able to completely one shot it after the refactor.

So there is clear value in having "clean code", but I'm not sure how valuable it is. If even AGI cannot handle tech debt, then there's value is at least building scaffolding (or atleast prompting the scaffolding first). On the other hand there may be a future where the human doesn't concern himself with "clean code" at all: if the value of "clean code" only saves 5 minutes to a sufficiently advanced agent, the scaffolding work is usefuless.

My reference is assembly - I'm in my early 30s and I have never once cared about "clean" assembly. I have cared about the ASM of specific hot functions I have had to optimize, but I've never learned what is proper architecture for assembly programs.

When I look around today - its clear more and more people are diving in head first into fully agentic workflows and I simply don't believe they can churn out 10k+ lines of code today and be intimately familiar with the code base. Therefore you are left with two futures:

* Agentic-heavy SWEs will eventually blow up under the weight of all their tech debt

* Coding models are going to continue to get better where tech debt wont matter.

If the answer if (1), then I do not need to change anything today. If the answer is (2), then you need to prepare for a world where almost all code is written by an agent, but almost all responsibility is shouldered by you.

In kind of an ignorant way, I'm actually avoiding trying to properly learn what an ECS is and how the engine is structured, as sort of a handicap. If in the future I'm managing a team of engineers (however that looks) who are building a metaphorical tower of babel, I'd like to develop to heuristic in navigating that mountain.

I've found that there are two issues that arise that I'm not sure how to solve. You can give it docs and point to it and it can generally figure out syntax, but the next issue I see is that without examples, it kind of just brute forces problems like a 14 year old.

For example, the input system originally just let you move left and right, and it popped it into an observer function. As I added more and more controls, it began to litter with more and more code, until it was ~600 line function responsible for a large chunk of game logic.

While trying to parse it I then had it refactor the code - but I don't know if the current code is idiomatic. What would be the cargo doc or rust-analyzer equivalent for good architecture?

Im running into this same problem when trying to claude code for internal projects. Some parts of the codebase just have really intuitive internal frameworks and claude code can rip through them and provide great idiomatic code. Others are bogged down by years of tech debt and performance hacks and claude code can't be trusted with anything other than multi-paragraph prompts.

>I'm also curious how you test if the game is, um... fun?

Lucky enough for me this is a learning exercise, so I'm not optimizing for fun. I guess you could ask claude code to inject more fun.

My gripe with AI tools in the past is that the kind of work I do is large and complex and with previous models it just wasn't efficient to either provide enough context or deal with context rot when working on a large application - especially when that application doesn't have a million examples online.

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.

Overall it's going well, but one downside is that I don't really understand the code "in my bones". If you told me tomorrow that I had optimize latency or if there was a 1 in 100 edge case, not only would I not know where to look, I don't think I could tell you how the game engine works.

In the past, I could not have ever gotten this far without really understanding my tools. Today, I have a semi functional game and, truth be told, I don't even know what an ECS is and what advantages it provides. I really consider this a huge problem: if I had to maintain this in production, if there was a SEV0 bug, am I confident enough I could fix it? Or am I confident the model could figure it out? Or is the model good enough that it could scan the entire code base and intuit a solution? One of these three questions have to be answered or else brain atrophy is a real risk.

People not only tolerate, but I'd argue most people prefer it. I think, unlike Singapore or Tokyo, Americans, in cities, largely prefer a little lived in grime.

The Mission Bay is a relatively new neighborhood in San Francisco - mostly free of graffiti and is pretty much sterile, and most people would prefer to live in the Mission rather than Mission Bay. OpenAI likely pays a huge premium to HQ in the mission rather than settling in the more corporate offices of Mission Bay or even the Financial District.

I also noticed the same in Berlin - Kreuzberg, Neukolln, and other neighborhoods in East Berlin attract the most people, despite being drenched in graffiti.

If ever move to a city in America and tell people you live in the generally clean, spick and span, neighborhood in that city, half the people will look at you like you have 3 heads or simply assume you have no personality. Graffiti has largely become an accepted, or even valued, feature of a neighborhood. I believe internally it separates the "cool" city inhabitants from the "losers" out in the suburbs.

Edit: I just looked through all the images in the OP and one of them is a banksy. It's been there for over a decade. Graffiti isn't just tolerated, its practically protected.