If you then Ctrl+A to select all and press backspace, I wonder if that would delete all those 3-line chunks...

I only used once, in February, so hopefully they didn't break it since then.

I guess I could be the odd one out but I'm not keen on the 'localisation' efforts that replace the cultural elements of the underlying media, e.g. how in Ace Attorney ramen is replaced with t-bone steaks (iirc?), prompting the meme 'Eat your hamburgers, Apollo'

Saying that, token-based pricing has misaligned incentives as well: as the editor developer (charging a margin over the number of tokens) or AI provider, you benefit from more verbose input fed to the LLMs and of course more verbose output from the LLMs.

Not that I'm really surprised by the announcement though, it was somewhat obviously unsustainable

maybe, but not entirely sure. 'Two wrongs don't make a right' kind of thinking on my side here.

But if they call it GFY and do what they want, then that would probably be better for everyone involved.

> they don't have the "Norway" problem because they intentionally don't apply the boolean value rules from YAML.

I think this is YAML 1.2. I have not done or seen a breakdown to see if GitHub is aiming for YAML 1.2 or not but they appear to think that way, given the discussion around merge keys

--

(though it's still not clear why flattening the YAML would not be sufficient for a static analysis tool. If the error report references a key that was actually merged out, I think users would still understand the report; it's not clear to me that's a bad thing actually)

I am not sure you can do this whilst having the granular job reporting (i.e. either you need one YAML block per job or you have all your jobs in one single 'status' item?) Is it actually doable?

Kind of a hard disagree here; if you don't want to conform to a specification, don't claim that you're accepting documents from that specification. Call it github-flavored YAML (GFY) or something and accept a different file extension.

https://github.com/actions/runner/issues/1182

> YAML 1.1 to be an important goal: they still don't support merge keys

right, they don't do merge keys because it's not in YAML 1.2 anymore. Anchors are, however. They haven't said that noncompliance with YAML 1.2 spec is intentional

I think it makes way more sense for GitHub to support YAML anchors given they are after all part of the YAML spec. Otherwise, don't call it YAML! (This was a criticism of mine for many years, I'm very glad they finally saw the light and rectified this bug)

There are performance footguns (like recursion, for which you'd have to consult your GraphQL server library for mitigations). There is often a built-in 'introspection' endpoint, which many consider a security faux-pas (to which I disagree — I think it's pretty noble, like having built-in OpenAPI docs) BUT you can easily craft a recursive query using just this endpoint that will take (some) GraphQL servers down. There are plenty of posts written on the matter and I'm sure there are mitigations, but my first exposure to GraphQL was on someone else's project (a respectable engineer who I consider very skilled) and within the first day I had noticed this intriguing structural hazard and taken the server down...

It therefore seems to be a tool that is possibly difficult to 'hold correctly'; at least people should be cautious about going in without doing their research about these things. Probably a maturity issue, but one that people ought to be aware of?

Other gripes:

It's displeasing how the HTTP status code does not correlate with the actual success response of the API, which makes typical request logging less useful.

I guess it also makes it harder to provide optimised hot paths on the server (because your client team might shift their queries around, or whatever).

In previous experience I also find that having easily-recognisable names for API endpoints (like `GET /repositories`) makes talking about them, and recognising them, easier than the more-opaque-feeling GraphQL approach.

Perhaps some of the page-level Copy-on-Write databases (LMDB?) might do this, since they have to rewrite ancestor pages anyway.

Would be interested in doing something similar

I think the blog post is not focussing on error handling too much, but in any case this is 'safe', just could likely be handled better in a real-world case.

the question mark `?` denotes the fact that the error is bubbled up (kind of like an exception, but with stronger typing and less silent)

Or if you wanted to do it on bytes, you could also do this, with (`b'+'`).

Unsure if that would provide a meaningful boost or not

[1]: https://doc.rust-lang.org/std/primitive.str.html#method.pars... [2]: https://doc.rust-lang.org/std/str/trait.FromStr.html

`n` has the same type as the input of the `match` block. In other words, it's a fallback case. (In this case, it's `&str`; the same as `"+"`, `"-"`, etc)

If you're wondering how `n.parse().unwrap()` has its type computed, well that part is because type inference is able to look at the definition of `Token::Operand(u32)` and discover that it's `u32`.

From my experience: The compiler can do this, as long as the first usage of the unknown-typed-thing gives it a type. If the first usage of it doesn't, then it won't try any harder to infer the type and it won't compile unless you add your own annotations on.

This auto-dub-translation feature is also problematic in that viewers don't realise it's happening. I think that is unreasonably misleading. It could be great as an option, but it should really prompt you before switching it on.

That way people would not be forced to use it, and people would be aware of it.

> “I’d say maybe 20%, 30% of the code that is inside of our repos today and some of our projects are probably all written by software,” Nadella said during a conversation before a live audience with Meta CEO Mark Zuckerberg.

— https://www.cnbc.com/2025/04/29/satya-nadella-says-as-much-a...

'maybe', 'probably', 'some of our projects', 'by software'

'software' would include many sorts of tools that are not AI.

Either the CEO talks like a primary school child unintentionally or it's on purpose to drive some clicks without saying anything 'technically' wrong.

And this is the CEO of a company that benefits from the doubt.

Am I too cynical?