nikeee

I don't like this:

    String body = ... REST response body, which is a JSON document ... ;
    JsonValue json = Json.parse(body);
    json.get("properties").get("periods").asList().stream()
        .mapToInt(j -> j.get("temperature").asInt())
        .average()
        .ifPresent(IO::println);

Why am I able to call `.get(string)` or `.get(int)` on a JsonValue? Shouldn't these be on the JsonObject and JsonArray instead?

> If the JsonValue instance is of the wrong type, or if the requested member or element does not exist, the access methods throw a JsonValueException.

So if I get an exception, I can't tell whether the value was of the wrong type or the object didn't have the requested key? This looks like a footgun to me.

They just brought pattern matching to Java. Why not move those .get to JsonArray and JsonObject? That would solve this confusions. So we could just use something like `if (json instanceof JsonObject o) o.get("properties")`

I suspect that, too. But to me, it signals the exact opposite.

In that case I still want to see exactly this prompt. Then I know that the person didn't even think about my question thoug I asked _them_ for their opinion and I could have asked ChatGPT myself (and already probably have).

When I'm encountering some WoT like that, I'd like to have a button like "view source", but for "view prompt".

Most ai generated messages or docs are unnecessarily verbose and just reading the prompt would suffice. I don't really get why some people seem to think that it's somehow better to have their bullet point prompt as a huge text.

It just wastes my time. And probably only makes it look like it took more effort than it actually did (it may be the exact opposite).

Zig is a moving target that has breaking changes in every release (which is fine as they are sub-1.0). But that means that AI tools have been trained on outdated syntax/etc. Zig isn't that common, so there is even less training data to begin with.

Rust on the other hand is pretty established by now and has less breaking changes. It also has more compile-time safety-guarantees that makes vibe-coding a bit more confident.

In top of that, Zig has rejected their upstream contributions. So they'd have to maintain their own compiler in the long run, which is probably just technical debt to maintain.

What matters for LLMs is what matters for humans, which usually means DX. Most Microservice setups are extremely hard to debug across service boundaries, so I think in the future, we'll see more architectural decisions that make sense for LLMs to work with. Which will probably mean modular monoliths or something like that.

It is called Duration.

> the only viable use cases were compute-heavy workloads like codecs and crypto,

I tried using it for crypto, but WASM does not have instructions for crypto. So it basically falls back to be non-hw-accelerated. Tried to find out why and the explanation seems to be that it's not needed because JS has a `crypto` API which uses hw intrinsics.

That could probably be solved by opting in to the permission model of Node. But that won't work for everybody, especially in legacy applications.

Having trusted dependencies at least drastically reduces the risk that 'git clone && npm install' takes over the entire system.

Cooling down dependencies would certainly help, also.

Some tools also install pre-commit hooks. I don't like this practice, but I get why people are using it.

So if i happen to know the numbers of other file descriptors of the process (listed in /proc), i can redirect to other files opened in the current process? 2>&1234? Or is it restricted to 0/1/2 by the shell?

Would probably be hard to guess since the process may not have opened any file once it started.

Or you don't use the defualt case and rely on definite assignment analysis or checks for returns in every code path.

I find the never type in TS actually being a proper bottom type + having control-flow based types vastly superior to what rust offers.