lifthrasiir

In the three examples below, the model accurately renders Japanese, Korean, and Spanish respectively.

And yet the Korean text is not accurate... [1]

[1] E.g. "드레스 컬렉션 dress collection" has vowels ㅔ mixed with ㅐ, "초웜한" should be "초월한 exceeding", "신키한" should be "실키한 silky", "디자언되다" should be "디자인되다 have been designed", "로얼" should be "로열 royal", and so on.

I used to make a hybrid bitmap-vector font called Unison [1] a decade ago and I made it in that way so that I don't have to learn the fine art of (vector) typography. Or at least that I could skip most of it (for example, kerning is still required for proportional fonts, but that doesn't have to be very precise in bitmap fonts). I'm now working on Unison once again after 11 years of time, this time armed with a dedicated font editor called Uniform. I haven't publicly released Uniform in public yet but anyone interested can already download and compile it.

[1] https://github.com/lifthrasiir/unison

Probably, but knowing that redirection operators can be freely moved within normal arguments [EDIT: thank ButlerianJihad for pursuing me to make this more accurate] is useful.

Don't do this:

  cat file | wc -l            => wc -l < file
  cat file | head -n 5        => head -n 5 file
  cat file | awk '{print $1}' => awk '{print $1}' file
  cat file | sort             => sort file

  cat file | wc -l            => <file wc -l
  cat file | head -n 5        => <file head -n 5
  cat file | awk '{print $1}' => <file awk '{print $1}'
  cat file | sort             => <file sort

How does it compare with utf8proc [1]? I'm aware that Mojibake does a bit more than utf8proc (e.g. bi-di) but that seems marginal to me.

[1] https://juliastrings.github.io/utf8proc/

Context: 码 means "code" in Chinese and prominently appears in words like, e.g. 源代码 (source code).

exfiltrating user data (including env files, entire source code etc) which is what grok-build did here

I think env files are filtered out [1]. Anyway, the most suspicious code would be `upload_session_state` which is currently a stub function, though it is hard to say if it was only planned (badly) or has been removed as a damage control.

[1] https://github.com/xai-org/grok-build/blob/c1b5909ec707c069f...

Is this the infamous "cloud upload" routine? I'm not sure it is indeed insidious, though it is of course possible that the code has been filtered out. https://github.com/xai-org/grok-build/blob/main/crates/codeg...

Sharing those things to coding agents and model providers is probably inevitable for the use. The memory with random tidbits is not.

I think it is already done via a subagent, otherwise the context window would be flooded with long responses. In this case the subagent should've reported that a (attacker-controlled) authorization is required anyway.

That's why I don't turn memory on. (Claude Code too though for a different reason.) After all the current memory system is too crude to be useful anyway.

You are right. (Ziv's rounding is essentially a method that keeps error bounds and increases the precision on the inconclusive result.) I think atan2 suffers from the same problem as well, but haven't actually looked up.

as was famously the case with glibc's pow at one point

Pow is famously hard anyway because it's bivariate and there is no currently known way to work around the table-maker's dilemma (TMD). CORE-MATH even crashes upon a new required precision record, because it intentionally avoids Ziv's rounding.

Personally I don't think that matters, because the article is problematic enough when it can be read like ad hominem. Assuming that the question was phrased reasonably neutrally (but not necessarily free of hidden biases), the fact that LLM concluded so is an enough evidence here. Also as a non-LLM data point, I felt roughly same (especially the "softening" bit).

Reality check. The confirmation that the author is not alone in having this particular feeling by using an LLM as a proxy.

While I understand ZSF's bittersweet relationship with Oven and agree to several points (especially preparedness), this writing is badly structured and that shows something. Hope to see him turning around.

The project in question needed lots of near-instant human judgements and the iteration loop had to be extremely tight. Maybe Rust should be reconsidered once it gets stabilized enough, but not right now.

Oh, yeah that might be confusing. I meant "you can say the same thing for GC language if that's true, which isn't necessarily true, so that must be false".

More precisely speaking: GC languages are said to delay memory problems far beyond the horizon, which is often unreachable throughout the project's history. Zig can be a similar case.

Claude Code is entirely vibe-coded for a long time. Bun isn't. You go read and compare the actual Bun code; it reads reasonably well [1].

[1] For example, as a random sample, https://github.com/oven-sh/bun/blob/bun-v1.3.14/src/css/medi... -> https://github.com/oven-sh/bun/blob/4924862cffbf671792d47c92...

Hey, a typical person should be intelligent because we human have used ourselves as a de-facto definition of intelligence anyway. That sentence probably means something like "no intellectually disabled person here". Even though we don't normally feel so because higher educations seem "typical" to us.

There's less and less reason to use GC'd languages in the agentic coding era.

Faster iteration, maybe? Rust's safety guarantee isn't exactly free (while still being very excellent) and does affect iteration time. I have a private project (>300K LoC) that has been translated from Python to TypeScript and the reason we couldn't use Rust was definitely the iteration time.

The article explicitly mentions the maintainability as a foremost concern.

The same concern applies to every GC language, so it's not necessarily bad for Zig. Bun can have been grown too large for Zig to be effective, while moderately sized projects may still greatly benefit from Zig.

Claude itself (Opus) gave me the following conclusion:

The article frames Claude Code as the latest step in a lineage from punch cards → ed → modern editors → AI agents. Multiple team members say they no longer write any code by hand. The overall tone is "we built the right primitive (read/edit/bash), bet on future model improvements, and it paid off."

Honestly I don't want to endure an awkward terminal interface and/or questionable design to just arrive at this conclusion.

Beeg is just a respelled version of "big" ("ee" for /i:/). Apparently it is also a name of a certain questionable website (I didn't know!), but it is a common enough word that such unfortunate conflicts are to be expected.

The second fact, pi^2 ~= g, is famous enough that it has a separate section in Wikipedia [1].

[1] https://en.wikipedia.org/wiki/Mathematical_coincidence#Gravi...

Clever students can do anything without steering anyway ;-) Typical, I mean median, students would rather struggle to learn C.

A universal document converter is expected to expand via adding support for additional formats---that's okay (same for your other examples). I'm much more worried about the widening scope of the project.

Rust compiler is famously backward compatible all the way to 1.0 (after almost a decade of zero guarantees). My codes targeting early 1.x releases still work in the modern Rust, though the convention may significantly differ from the modern Rust. Your point might be true for some other languages but there is a good reason to refute that for Rust.

Ah, and many F77 libraries are still in active use. Nowadays they are used via C or Python wrapper, and I guess you said "using it as it is" to disregard that, but we were talking about what original maintainers are expected to do and the original F77 authors have nothing to do in order to stay relevant here.

Creating a part of C compiler, most frequently a working optimization pass, is a regular assignment. The entirety of C compiler is too large to give it as a student assignment.