entrope

The regressions got fixed before a release. Do you count your internal integration branch as "shipped"?

0.02 defects per KLOC is a low density, even considering that it was "just" a port to a new language and before giving credit for the existing bugs it identified and fixed. That defect density will probably only generalize to other projects that have similarly extensive regression test suites, but it's a proof of what LLMs can do.

The article is explicit that addition is O(n), with n digits, which is cheaper than multiplication is believed to be. Naive multiplication is O(n*n) -- considerably less than your algorithm.

> The AI can't decide on notation.

It is sadly emblematic of how much SciAm has cheapened itself over the past decade. They used to care about technical details. Now they serve up poorly formatted rehashes of news (largely) from 65 years ago.

Did Bun mass-close issues that predated the rewrite? It doesn't look like they did, as the oldest open issue is from 2021 and there are many from 2022, but maybe they did something that killed most of the old issues.

> taking that into production with barely any announcement is what kills off the interest to me.

Did Bun v1.4.0 release weeks ago and I missed it? I would call a formal release the point that it goes "into production", and I think dogfooding it via Claude Code is yet another form of testing Bun-in-Rust before the latter goes to casual users.

I think the idea conflates price discrimination -- where people on individual subscriptions pay a much lower price per token than corporate accounts pay -- with using venture capital funding for opex. Both are subsidies in some senses, but the former is sustainable indefinitely.

At the risk of stating the obvious, California's law only requires property owners to declare the presence of hazardous substances, not to reduce or even identify them.

I would suggest that if you have two similar copies of sufficiently complex logic, it's fair to combine them after they have been stable for a long time. My gut feeling is that the threshold should be a function of complexity times stability in hours worked (on that part of the code), because the expected maintenance cost of duplicated code scales with its complexity.

Yes, but California requires prominent signs for any business premise where these materials are found, and the incentives are to not provide any further detail about which substances are present. So a gas station will have a Prop 65 sign; is there a hazard beyond automobile exhaust? It's legally less risky for the business to not say. Similarly for a store that sells alcoholic beverages; should customers take protective measures besides not drinking alcohol? It's less risky for the business to not say. The signs are too common, and too vague, to satisfy the intent of the law.

Go is similar: `for/range` has always worked on arrays, slices, maps, strings and channels, and they extended it to integers in version 1.22 and to user-defined generators in version 1.23. It generates one or two outputs depending on the type of the RHS, but one can assign the index value to _ to ignore it. Among standard types, only channels and integers generate one output; containers (including strings) give an index or key and a value.

I've read the list of materials that California knows cause cancer and birth defects. It lists things that people encounter every day. Alcoholic beverages, aloe leaf extract and aspirin are some of the most notable examples from the "A" section.

https://oehha.ca.gov/proposition-65/proposition-65-list

Go is similar:

  package main

  import "fmt"

  var vec = []string{"the", "quick", "brown", "fox", "jumped", "over", "the", "lazy", "dog"}

  func main() {
    for i, s := range vec {
      fmt.Printf("%d: %s\n", i, s)
    }
  }

Using `fmt.Println(i, ":", s)` inserts spaces on both sides of the colon, so the output is not quite right.

I find Go's `range` syntax easier to read than D's `(i, s; vec)` -- although generator functions that work with `range` have unaesthetic return types.

> I'd love to see them on snowy 2 today.

I can only imagine the comment warnings on that segment considering that, sadly, John Clarke passed away nine years ago.

When accusing someone of "good looking lies", it would help to provide an example or two with an explanation of why you think they're lies (rather than mistakes, oversights or differences of opinion). Complaints that the post "subtly and misleadingly throws shade at Zig" are hard to accept without that kind of support.

Can you point out exactly where it says that? As I read it, the claim is that AI boosts the productivity of writing code to the point that it's usually not productive for humans to write code directly. I think that boost only goes so far -- safety-critical code still needs to be well-understood by people, and a lot of the higher level thinking has insufficient ground truth to train AIs on it -- but it's fundamentally a claim about transforming software development rather than ending it.

Probably just you. I use them somewhat frequently to make it clear where a set breaks down into alternatives or parallel factors. If there's a preface and trailer around a list of complex items, I think writing the list in one paragraph is often ambiguous and hard to follow. Using a bullet list within that kind of paragraph (IMO) makes it easier to follow what I think is important.

Yes, people are entitled to their emotions, but the ways they behave in public and express their emotions reflects on them in a major way. The Bun blog post focused on the technical reasons to change, and was complimentary about Zig. The Zig blog post was heavy on personal attacks, with some technical claims that the Bun blog post had mostly addressed already. Between the two, the Bun post is a lot more compelling from technical and professional perspectives.

I'll admit to thinking that the Rust crowd often has a toxic atmosphere, but Zig came off as worse in this exchange.

U2F was always an option, because I used it since they added the MFA requirement (and like others here never gave Github my phone number). I think TOTP was also available from the start. The warning to not use SMS for MFA might have been added later.

Those are the ratios for memory bandwidth, but the GPUs have a much higher ratio for compute, and that affects prefill rate / TTFT, right?

Yes, all of those and more. Our measurement precision is much better than the year-to-year first and second derivatives of day length. https://datacenter.iers.org/singlePlot.php?plotname=Bulletin... has the most relevant plot to this; the vertical jumps reflect leap seconds. (IERS has other plots for other dimensions of rotation, but I like this one.)

IMO, "make your servers fungible" is a better way to express the intent: slightly shorter, no metaphors, although "fungible" is a less common word. Maybe that's just me. (Edited to add: "make your tests fungible" has I think the wrong connotation; I think the original wording on the blog is about test executions -- and "make your test executions fungible" does seem like a good goal, similar to ACID guarantees for database transactions.)

Can you elaborate on the distinction between "eliminate the hazard" as the first choice and "engineering out the hazard" as a fallback approach?

In my safety background (recently aerospace, ARP4754/4761), removing and avoiding the hazard are essentially equivalent, with reducing the likelihood and mitigating its effects acceptable if you can't remove or avoid the hazard, and procedure is also the least preferred mechanism.

My experience is that AI agents write 20-33% more code than I would for a given feature set, mostly because they are worse at remembering what utility functions already exist and less likely to merge similar functions into more generic ones. They generate that code 2-10 times faster than I could. Defect density is harder to compare: I probably generate more "dumb" defects due to oversight or missing unit tests, but fewer defects that violate domain rules or architectural objectives.

I think you're overlooking the lesson of Goodhart's law: you can use a metric, but if you make it a target, it stops being a good metric. Neither "tons of aircraft" nor "lines of code" should be the measuring stick -- and if they're not, then they can still be used as metrics.

To be fair, the hazard with AI agents is that they generate fluent output that is often facile, so it's easy to do a lot of things while having a lot of defects. That's a sign that quality control is not prioritized enough. A change in quality will also reduce the utility of SLOC as a metric, but the mechanism is different than what Charles Good hart pointed out.

It is hard to have much sympathy for someone who complains about seeing a Git commit they never made but presumably clicked "publish" for a blog post that says "a North Korea-aligned group who targets software developers specifically. Not banks. Not hospitals. Devs." Supply chain security is a huge concern nowadays, and JavaScript in config/build-chain files is a sadly long-lived threat vector against a supply chain.

In this case, "Zero-JS" seems to mean that you write short bits of JavaScript that look like a domain-specific language, and you include a relatively small JavaScript file that translates certain server-sent events into DOM updates. The documentation for Datastar is less assertive; for example: > The value of the data-text attribute is a Datastar expression that is evaluated, meaning that we can use JavaScript in it. (from https://data-star.dev/guide/reactive_signals)

I personally would call this a minimal-JS approach to an SPA. The use of Nim as a server language and YottaDB as a storage engine seem incidental, except that the overall page is advertising for the database.

A single benefit usually has an appropriate incentive structure, but a lot of people get multiple benefits -- even from different levels of government (local, state, federal) -- and adding up phase-outs in different systems can result in marginal phase-outs rates above 100%. It's hard to avoid that entirely given that we want to have a lot of transfers to the bottom of the income distribution while phasing those out by roughly the median. It would be easier to avoid phase-outs above (say) 80% of marginal income is we only had federal and state aid as predictable money transfers, but for various reasons we provide a lot of transfers in-kind or with limited authorized uses. Those limitations aren't necessarily wrong, but they do mean that transfers aren't fungible, so there's an incentive to provide transfers for other "good" uses, and that diversity is what makes it hard to bound the marginal phase-outs for everyone.

Perhaps to support demand for the products with recent price hikes, and/or the upcoming Mac Studio with M5 Ultra, rather than have customers sit on the sidelines thinking they'll wait this generation out.

I am still skeptical that Apple intentionally leaked this because they normally are so tight-lipped, but there are reasons in favor of leaking this.

The mechanism is that generating tokens (the "decode" phase) in an LLM is limited by memory bandwidth for the weights, so computing multiple streams amortizes the bandwidth over streams as long as you can keep the contexts in RAM. This is most true for dense models and the always-on expert in MoE models, or when you have significantly more streams than experts for MoE models.

In contrast, prompt prefill is more easily compute-bound, so there are interesting trade-offs for latency of decode vs prefill when the LLM utilization is high.

> The DGX Spark has basically the same memory bandwidth as a M5 Pro, and far more than a M5.

I see ~274 GB/sec for the DGX Spark[1], versus 307 GB/sec for M5 Pro and 460 or 614 GB/sec for M5 Max[2]. One might call 90% "basically the same", but there are nominally two tiers above "Pro".

Yes, a MacBook Pro with 128 GB and M5 Max costs $5100 (14") or $5400 (16") versus currently $4700 for the DGX Spark, but the MBP includes keyboard, mouse, battery and portability. I believe its prefill is slower and you get 2 TB vs 4 TB SSD, but overall one gives up a lot to save 10% of the cost.

[1]- https://docs.nvidia.com/dgx/dgx-spark/hardware.html [2]- https://support.apple.com/en-us/126319