YuechenLi

Yeah, I still don't understand why they don't just use enums and have to invent a special "union" keyword instead. C#'s enums are extremely underpowered to begin with and the syntax they designed here way more convoluted and uglier to say:

    enum Pet { 
    Cat,
    Dog,
    Bird
    }

    var description = Pet switch
    {
        Dog d => d.Name,
        Cat c => c.Name,
        Bird b => b.Name,
        _ => "no pet"
    }

So... the verbosity of Go without the compile speed of Go? Go is not a language I would associate with ergonomics, and this doesn't even have most of modern C#'s best features: does xUnit.NET work? Does immutable records work? Do collection expressions work? Does LINQ work?

Calling a language with `let` instead of `const` and async/await and iterators and classes "Go" is plain just incorrect. This G# is more similar to TypeScript than Go.

The ONE feature that C# really needs is payload enums with `match` instead of C#'s current pattern matching with `switch` anyways, and Rust is more similar to Go anyways so why not copy from Rust instead? I'm honestly baffled.

I got tired of Codex/Claude not being able to write good UI reliably, so I made a TypeScript library toolbox to help with that.

https://github.com/yuechen-li-dev/MachinaLayout.JS

Pretty much just SwiftUI-like layout/style in TypeScript with a bunch of utility tools from other languages I like, like Rust's payload enums, table helpers, LINQ-like queries, state management, etc. It's framework neutral so it works with React, React Native, and Vue right now. Everything is just plain TypeScript that compiles to the DOM, so no HTML or CSS needed for most normal web apps, they can all be written in plain .ts or tsx files.

Just personal experience, I just find it way easier to do frontend work with Claude than it is with Codex.

The answer is it depends. Claude's generally better at frontend and debugging tasks, while Codex is stronger at backend features and exploratory work. They have very different coding styles and thus very different strengths.

Fair point, I phrased that too broadly, and you are right about the loose correlation.

What I was gesturing at, badly, was more that Zig’s low-abstraction / explicit-by-default syntax tends to have you write more boilerplate-y code in general that are more annoying to write and maintain, while not buying you enough over a language with better tooling and ecosystem and compiler optimization like Rust.

Combined with the Rust rewrite, ICU changes, and identical code folding, Bun's binary size shrinks by ~20% on Linux & Windows.

People who are surprised by this probably has not seen what Zig code actually looks like. Zig's explicitness and lack of abstraction have a real cost that it is basically one of the most verbose programming languages I've ever seen, it's somehow even more verbose than Go. Basic features of modern languages like pattern matching and generics, and as you can see, having to manually clean up everything means that if you forget once, it's a memory leak. Having SOME abstraction is actually good if it prevents you from making mistakes.

Ironically, Zig is a programming language that's probably best written by LLMs, since they can actually tolerate the verbosity.

I'm sure you know that JSON are object literals in TypeScript, there isn't really even a serialization process that's needed there. The AST/IR can still be in JSON, but the authoring surface can be a restricted subset that does not allow logic to execute, that way you can still get the type safety and functionality of TS when you need conditional/loops/logic without throwing away what TS already gives you.

I mean, it would be great if you guys would have like a "TSON" that is basically "JSON with type declaration and comments" from TS, which I think would just solve a lot of problem straight up. JSON itself is just too restrictive and comes with its own bracket verbosity tax.

Instead of requiring verbose low-level parameters such as scales, axes, spacing, and layout.

Ok, Microsoft is conflating two different things here: LLMs don't really care about code being low level and verbose, they can read things like Assembly and SPIR-V just fine: visualization is the real issue in that LLMs have no natural understanding of spatial composition through visual comparison because they literally "see" things differently than humans, so the way to get around that is provide them with "visualization" in code form that they can easily reason about and understand, so basically anything that's not deeply nested and has hidden states that they have to reason about.

Also, Flint being stringly typed in JSON is a decision that I don't think I agree with. Looking at the actual spec, this could have just been a normal, human usable TypeScript library, and it would have been 100x better. Using their own example (excuse the formatting):

type SemanticType = "Category" | "YearMonth" | "Profit";

type ChartType = "Heatmap" | "BarChart" | "LineChart" | "ScatterPlot"; // extend as needed

interface ChartEncodings { x: string; y: string; color?: string; size?: string; tooltip?: string; }

interface ChartProperties { colorScheme: string; [key: string]: unknown; // allow other optional properties }

interface ChartSpec { chartType: ChartType; encodings: ChartEncodings; chartProperties: ChartProperties; }

type SemanticTypes = Record<string, SemanticType>;

interface ChartConfig<TData = Record<string, unknown>> { data: TData; semantic_types: SemanticTypes; chart_spec: ChartSpec; }

// The actual typed object literal: const chartConfig: ChartConfig = { data: {}, // replace with your actual data shape/type semantic_types: { game: "Category", period: "YearMonth", newUsers: "Profit", }, chart_spec: { chartType: "Heatmap", encodings: { x: "period", y: "game", color: "newUsers", }, chartProperties: { colorScheme: "redblue", }, }, };

EDIT:

Went and actually looked at the source instead of just eyeballing it from the docs, and it was a lot more complete and sophisticated than my assumed mockup already.

Core complaint (string-keyed JSON vs. a real generic authoring surface) still stands, but the specific types I posted aren't what Flint has. My bad.

I mean, the key is to stop trying to one-shot everything: The main problem I found with LLM code is more that they always try to take the shortest path to the solution possible, so a lot of time Codex would write code that meets the requirements of the prompt but misses something that cause it to not work in the non-ideal scenario.

The solution for that is pretty easy too, it's just iteration: you describe the exact problem you have with the code and why it is not running correctly and ask them to provide a narrow fix that addresses the bug. It's not that complicated.

Yeah, one of the big problems with that is that Claude/ChatGPT doesn't perceive images the way humans do at all, so when you upload an image to them, it gets tokenized in some form. This is why most LLMs are really, really bad at spatial recognition for image editing purposes for example.

So, unless you can turn the image into a natively tokenized format like JSON or something that somehow accurately tokenizes what's on there, I would NOT trust Dr. Claude's analysis. If you want a second opinion, talk to another doctor. A human doctor.

Oh, I wasn't referring to emitting LLVM IR directly from Nim, but that you should consider adding an MIR layer between your Nimic subset of Python and Nim instead of emitting Nim from Python directly. Otherwise, compilation would get difficult and adding new supported Python will get painful.

If it's possible and you intended for it to be a long-term project, I would suggest looking at designing an MIR for the Python to lower to and then lowering it to Nim, and that is probably the most valuable feature you can add to Nimic. That's what Rust had to learn the hard way, and that's how LLVM works, and having an intermediate representation means your compiler is going run into a lot less edge cases during development.

So... has Google provided a Codex/Claude Code equivalent to Gemini yet? I would like to use Gemini for coding tasks, but that's kind of difficult to do as I don't even know how to get Gemini to even "clone this repo and read the code in it for static analysis", much less open PRs in repos.

ChatGPT/Codex can do it, Claude can do it, why can't Gemini?

And no, I don't mean going through Antigravity, and personally I'm wary about LLMs having unsupervised access on my computer without explicit policy, so I really think Google is putting the cart before the horse here.

I honestly think Mojo would be better served if it is just a high-level language for GPU programming that compiles down to PTX with clear Python/Rust interop boundaries instead of trying for the "one language, multiple computational model" thing that they seem to be going for. The programming model between CPU and GPU programming is very different: code that runs best on CPU with heavy branching behaviors should not be written the same way as massively parallel matrix multiplication oriented GPU code, which I think they will be forced to do in the MLIR level anyway.

So, you end up with a language that looks like Python, but doesn't behave like Python, and companies that adopt Mojo early with the promise of Python compatibility may find themselves running into edge cases with difficult to trace compiler error messages that would be nearly impossible to debug, especially with the addition of Zig style `comptime` as their metaprogramming model.

I would say it is definitely a form of context, but when people think of LLM context windows in terms of coding is more technical context related: "what has been done before, what's the coding task at hand." etc.

However, I think that there is a philosophical portion to that context as well: "What problem is this feature supposed to help with? How would you verify that passing unit tests means that the code is working as intended? Does this feature need to exist at all?" LLMs usually need these to be provided to them explicitly since they are not good at inferring the correct intent compared to humans, otherwise they just make something that looks right but doesn't work right.

Learning computer science theory is probably going to be more important for the future than writing code yourself, because LLM coding is here to stay, and the human's job is going to be guiding the LLMs effectively: the AIs are writing code that pass tests, but how would you know that you are having the LLMs coding the right things?

Personally, I think learning specific implementation of algorithms probably should take less of a priority compared to fundamental architectural understanding why these things are done in the first place: data structure, automata theory, interpreter/compiler methodologies, etc. You still have to learn how to code, even if you won't be doing a lot of coding directly yourself, because the fastest way to learn how to evaluate code is by writing code yourself.

Strangely, I found that LLMs responds better to philosophical explanations alongside instructions when writing code than simple imperative tasks of "do this". For example, if you tell a frontier model "This is the feature I'm trying to implement, and this is the problem I intend to solve with it and the reasoning behind it.", you usually get a lot more reliable results that both pass tests as well as function as you intended, even if your spec isn't as detailed overall.

Are you sure? I'm pretty sure .deb and .rpm packages both allow that Learned something new today. Thanks.

I think the other significant issue with the NPM ecosystem that makes it bad in particular is NPM's dependency management is genuinely the worst out of any package manager because of phantom dependency is the default: you can be using a package without ever knowing that you are using it because it is imported implicitly, and the JS ecosystem dependency is so weird that taking down a small package that that a major project depends on cripples the entire JS ecosystem, as shown in left-pad, and launching a cyberattack via npm can be as easy as putting malicious code in any small package that large, popular packages depend on and watch it propagate. This is not hypothetical, it has been done, repeatedly in fact, over the years.

TS is a good programming language, however NPM is a security nightmare, and somehow the collective reaction of everyone depends on the JS/TS ecosystem seems like a shrug and "oh well, what can you do".

This seems to be primarily a problem with NPM, since it's the only package manager that I know of that allows for package authors to essentially run arbitrary post-install scripts silently package install.

Shai Hulud/Mini Shai Hulud happened because of this obvious glaring hole in the system, they even had the script to download an official copy of Bun to spread itself in case the targeted machine has hardened their security. So, the real question is not what other security features does a package manager need, it should be: why does a package manager have the ability to let package authors run arbitrary scripts silently on other people's computer in the first place?

It doesn't really matter how good your security system is if the front door is left wide open for anyone to walk through.

I'm proud to say, I've managed to slay one of the giants, the only successful effort to my knowledge, and this only happened last year. But I did so by basically delegating to another of the giants; they turned out to be twins and we could do without one. The dirty way is the clean way because the alternative contains Lovecraftian geometries.

If you are interested, I've built an open source project specifically to solve this issue in game AI and it resolves the switch/if-else ladders pretty cleanly. It's C#, so it should work for .NET version of Godot as well, and I have a couple of sample MonoGame project on there to demonstrate that it works: HSFM + utility AI. Works not just for games, but weirdly for LLM orchestration too.

https://github.com/yuechen-li-dev/Dominatus

Try it out, I don't want people to think I'm here just to self-promote, but I think this could be the thing that helps you slay the switch statement giants once and for all. If it helps you for your work, hey, powers to you.

You should be skeptical of industrial use case as well. Allowing any device with internet access and a camera on it onto the floor of most electronics manufacturing facility is a nonstarter, phones, smart glasses, or anything of that sort. The other thing is, smart glasses buy nothing over having PCs/assembly line machines with screens for HMI, and standard operating procedures can be printed on paper. Also, if you are actually an operator on an assembly line, wearing these glasses for 10 hours a day is the last thing you want at your job.

The case for them gets even worse for heavy manufacturing industry/trades, since you have to think about safety and liability now: what if these smart glasses fall into the machines and cause an accident? Can these smartglasses can withstand the environmental conditions in the workshop?

They are extremely common actually. Why do you think the standard iPhones only does USB 2.0 transfer speed? The high-speed signal pins are simply not there, but the connectors themselves are still standard compliant.

Lower transfer rate means less shielding is needed for the cable as well as the overmold, and enables longer and more flexible cables, as extra shielding stiffens the cables.

The industry will realize that while getting LLMs to write code is easy, getting LLMs to write good, production ready code is a skill all on its own, which simply must be done by a human and is not automatable to an LLM in any sense effectively. That will be the differentiating factor software engineering in the future, I think.

If I'm being blunt, if you are in the game industry, you probably have nothing to worry about in terms of LLM coding replacing you, because the tooling used in the gaming industry is as unfriendly to LLM coding as it gets: Heavily visual scripting based, extremely reflection heavy, and the code, Unreal C++ and Unity C#, looks like regular C++/C#, but doesn't behave like normal C++/C#. LLMs simply cannot reason about hidden implicit states effectively, so if the code looks right but doesn't act right, LLMs will simply get confused and start hallucinating.

Not quite right, USB-C ports are generally cheaper nowadays because they are smaller, consumes less material for plastic/metal, more easily automatable production wise in terms of tooling, and scale for them is a lot higher because of mobile usage. You don't really need extra production chips since the console USB-C ports are designed for PD and crippled 14/16 pin versions that only supports the USB 2.0 speed, because the high-speed pins literally do not exist on those.

Surprised that they have 4 USB-A and only 1 USB-C. With their power profile, Steam Machine should be powerable by a single USB-C cable on extended power range which should reduce the need for the power supply altogether and greatly simplify mechanical as well as thermal design, although the power electronic design would be more complex as a result.

I would also be expecting Wifi 7 support as well as unified memory considering they ordered custom AMD silicon. Understandable that it is a rather conservative design for their first generation though.

I think the more valuable topic to study is feedback control loop in general as a part of control theory: gain, stability/oscillation damping, overshoot, hysteresis/minimum commit, and noise filtering strategies (low pass, Kalman, etc). Those are just very useful general concepts applicable to any kind of long running systems.

The actual PID controllers ,however, are actually really finicky to tune, and hard to reason about directly. Good for simple linear systems, but it falls apart as real life systems tend to be complex and nonlinear.