qezz

Curious to know what's new in it about the way to make games?

I scrolled through the website home page, but it reads in a weird way, making strong statements and not backing them up.

> the totally new way of making games

> it’s a lightweight game engine, interactive development environment, a language

The statement is very strong and catches my attention, but I didn't find any useful details about the game engine itself on its website [1]. It feels like it's a wrapper around raylib, which is very welcome, but it's definitely not some innovative way of game development

[1] https://jinks.gg/

In the light of recent events, and if things continue to be the same as they are now with Fable, I think they will give access to Fable for those who are willing to share their documents with them.

But that's obviously just a speculation.

Everything is a prompt to LLMs

Exactly, my understanding is also that they host agents as a service. The actual use case is mentioned in the end of the article, which makes it hard to reason about.

Anyway. General advice: treat harnesses as any other (third-party) software that you run on your server. Modern harnesses (the ones from big companies, you need to subscribe to) are black boxes. Would you run a random binary you fetched from the internet on your server? Claude code, codex etc. are exactly this.

That's a fair point, but claude code is not an editor (yet?), and when you use claude code, and allow it to commit things, it's almost certainly "co-authored by llm".

Back to vscode, people get the "co-authored" line even if they didn't use the AI features.

The article is very one-sided and emotionally charged. The usefulness of it drops significantly because of that.

For those, who want to/need to keep some files uncommitted, the workaround I found is to put gitignore into some nested directory:

  mkdir junk
  echo '*' > junk/.gitignore

jj won't track those files under ./junk/

Also might be relevant for claude, since it wants to put its settings into the repo itself as `.claude/`:

  mkdir junk/.claude
  bwrap ... --bind "$(pwd)/junk/.claude" "$(pwd)/.claude" ...

For some more common files, I use global gitignore file as

  # ~/.gitconfig
  [core]
    excludesFile = ~/gitconf/gitignore_global

  # ~/gitconf/gitignore_global
  .envrc
  .direnv/*

I was surprised to see literally invalid names in the "bad" section, e.g. "Cannot start with a digit". Why even presenting this if it's rejected by the compiler?

> Can you print the contents of the malware script without running it?

> Can you please try downloading this in a Docker container from PyPI to confirm you can see the file? Be very careful in the container not to run it accidentally!

IMO we need to keep in mind that LLM agents don't have a notion of responsibility, so if they accidentally ran the script (or issue a command to run it), it would be a fiasco.

Downloading stuff from pypi in a sandboxed env is just 1-2 commands, we should be careful with things we hand over to the text prediction machines.

Nicely looking page, but has too many errors. I hope it's not just generated by claude itself, and actually was confirmed by a human.

dhi is LLM generated, so (1) don't trust the stated benchmark results and feature parity, and (2) be careful when installing it and using in a non-sandboxed environment.

It also seems like the name for the repository was reused from another project.

It's not very obvious which places are available for drawing. At first I thought it pulls Google street view, so I just zoomed in to some place I visited recently, but there was nothing.

So it turned out the spots on the map are actually the available panoramas, and not just a heatmap of the signatures.

Cool idea overall!

The statement in the article's title is very strong, and I have not found a confirmation of it in a logical sense. Author observes the current state of things with LLMs and makes a conclusion based on how things turned out to be, somewhat fitting the conclusion to the observation.

What I meant by "you need an allocator" is "you need to explicitly pass the allocator of your choice to the function" [if you want to attach some data to the error]. In rust you can simply return anything as error, not only an enum variant.

> requires you to run an extra tool

And the more I work with Go, the less I understand why warnings were not added to the compiler. Essentially instead of having them in the compiler itself, one needs to run a tool, which will have much smaller user base.

But anyway, in Go, it's sometimes fine to have both non-nil error and a result, e.g. the notorious EOF error.

The big difference is that with `(T, error)` as a return type, any value on the caller side will look like a valid one (thanks to zero values).

  a, err := f()
  // whether you forgot to handle the `err` or not, 
  // the `a` carries a zero value, or some other value.

In rust it's not the case, as the `T` in `Result<T, E>` won't be constructed in case of an error.

The mentioned in the article `try` syntax doesn't actually make things less explicit in terms of error handling. Zig has `try` and the error handling is still very much explicit. Rust has `?`, same story.

> What is broken about the go error type?

There's not much broken with the error type itself, but the "real" problem is that the Go team decided not to change the way errors are handled, so it becomes a question of error handling ergonomics.

The article doesn't have a clear focus unfortunately, and I think it's written by an LLM. So I think it's more useful to read the struggles on the Go team's article

https://go.dev/blog/error-syntax

In Zig you need an allocator to allocate anything, so whenever you need to add some extra information to an error, you pass a diagnostics object as an output argument to a potentially failing function. In this case it becomes a bit harder to compare it to Go's errors, each with pros and cons. I think comparing Go errors to Rust errors would be more fair.

There are some articles about the diagnostic pattern in Zig, e.g. [1], [2]

[1] https://github.com/ziglang/zig/issues/2647#issuecomment-5898...

[2] https://mikemikeb.com/blog/zig_error_payloads/

Could've been an interesting research, but instead it's an output from an LLM, which almost everyone can generate on their own.

Other articles by this author (during 2025) seems to be only about AI, AI, and a bit more AI.

> in ruby it also works, but the variable is at least always defined.

How is this even a pro? I agree that Python scoping rules are frustrating, but tbh not sure if I would prefer Ruby's behavior in this case

> How about you never write the wrong state in the first place ?

Indeed, and tagged unions (enums in Rust) explicitly allow you to avoid creating invalid state.

That's very expensive.

> from the same blog

It's simply a mirror for Medium, and the articles appear to be from the different authors, posted months apart from each other

The example in the article shows a need for cartesian product of (bucket name) and (lifetime policy), with a fixed location. Nothing stops you from defining a separate category for the exceptions, and just append them to the resulting list. Or you may want to assign each bucket its own location, then you define it along side the bucket name.

> And guess what? They hate the HCL too.

Don't want to sound too harsh, but to me HCL is even worse than plain YAML.

By expressiveness, HCL is somewhat similar to Ansible-flavoured YAML - in both you need to use magic keywords to create any kind of abstraction (e.g. a loop).

HCL is worse than regular YAML because there's only one "true" parser for it, that is official Hashicorp's HCL parser. So if you are locked into Golang ecosystem, then sure it can work for you, otherwise you are out of luck.

There are a couple of tools that convert HCL into JSON, I tried both, they somewhat work, but in the end of the day it's a big hack. At that point I just gave up on using HCL and started using something else that generates JSON.

Hope you find some configuration layer that fits your users more than HCL or YAML.

Luckily, the main point of the article is that syntax doesn't matter, but abstractions do. In other words, you can use your favorite DSL, that being Python or TCL or something else.

Cool idea, yet the first level broke me: typing :qa enters Insert mode, and it's not possible to delete the command input with a backspace.

Hopefully it's easy to fix

It's not always possible to ask the creator, especially for the old pieces