hyper57

But Bun is mentioned three times?

Also Hunter S. Thompson:

If you type out somebody's work, you learn a lot about it. Amazingly it's like music. And from typing out parts of Faulkner, Hemingway, Fitzgerald - these were writers that were very big in my life and the lives of the people around me - so yea I wanted to learn from the best I guess.

You don't get reams of wishy-washy code unless you ask for it.

I've found that they get pretty wishy-washy when you correct them. As an example, yesterday I was working on porting a function from the open-source CUE4Parse project from C# to Python (for a hobby project), and the LLM (Gemini 2.5 Pro) suggested the following translation of a C# method:

    @staticmethod
    def from_name(name: str) -> 'FPackageId':
        # C# Encoding.Unicode is UTF-16 LE in Python
        lower_name_bytes = name.lower().encode('utf-16-le')
        hashed_id = CityHash64(lower_name_bytes)
        return FPackageId(hashed_id)

This custom ToLower(), does that produce the same result as .lower() in Python?

Gemini answered with a lot of text and concluded: "You should use Python's standard lower() method for your port."

I pushed back with:

Right, but for this to work (looking up an asset by its hash as contained in global.utoc), I probably have to match the behavior of Unreal Engine...

  Gemini: You are absolutely right. My apologies, your insight is spot on. For the purpose of matching hashes that are pre-calculated by Unreal Engine and stored in files like `global.utoc`, you **must** replicate the engine's behavior exactly. My previous advice to use Python's `.lower()` was incorrect in this specific context.

  You need to implement a function that behaves identically to the C# `ToLower` you highlighted. The engine uses this specific, non-Unicode-aware, ASCII-only lowercasing function before hashing the path to generate the `FPackageId`. Using Python's standard `.lower()` would produce a different byte sequence for any path containing non-English characters, leading to a hash mismatch.

Loved using OCaml for a compiler course at uni when I was a student. But I've always felt that the tooling side is pretty rough, especially on Windows. Opam recently added Windows support, but it involves installing MinGW, and when following the official docs https://ocaml.org/docs/installing-ocaml#install-platform-too... the process breaks down with an error when trying to install utop due to a path separator error, which one has to fix manually (at least that was the case last time I tried). By comparison, installing Python or Rust on Windows is a breeze.

"The pen is an instrument of discovery rather than just a recording implement." ~ Billy Collins

According to Microsoft's own license terms for VS Code, you can't opt out of all telemetry; see Section 2a: https://code.visualstudio.com/license

You may opt-out of many of these scenarios, but not all, as described in the product documentation located at https://code.visualstudio.com/docs/supporting/faq#_how-to-di....

Also, each extension (including Microsoft's) may collect its own telemetry. The blog post https://www.roboleary.net/tools/2022/04/20/vscode-telemetry has more details.

Personally, I think it's a shame that JetBrains get such flack for collecting telemetry in their free products when Microsoft do the same in VS Code with hardly anyone voicing the same level of criticism for it.