From the article:
> The U.S. government is still reporting that its gold reserves are unchanged, so these exports look to be coming from current mine output and recycling operations.
Not sure if "The U.S governments gold reserves" also includes the ones from other countries though.
They should concentrate on their models instead. If claude code is any measure, their software engineering is atrocious. I would only use something like source control from them if they force me to, at which point I would rather do something else.
Double dash long options are basically a GNU extension. BSD utilities generally don't support them. Apparently macOS does not either (since it's based off of FreeBSD)
And the received wisdom about long options in the BSDs is a quarter of a century out of date. When the BSDs gained a getopt_long() in their C libraries thanks to Klausner and Baron, long options quietly started appearing. This process has been gradually and quietly on-going for the whole of the 21st century.
Over a decade after macOS/Mac OS X was initially released:
> macOS (previously OS X and originally Mac OS X) is a proprietary Unix[7][8] operating system, derived from OPENSTEP for Mach and FreeBSD, which has been marketed and developed by Apple since 2001.
> Darwin is the core Unix-like operating system of macOS, iOS, watchOS, tvOS, iPadOS, audioOS, visionOS, and bridgeOS. It previously existed as an independent open-source operating system, first released by Apple in 2000. It is composed of code derived from NeXTSTEP, FreeBSD[3] and other BSD operating systems,[7] Mach, and […]
I posted my original comment based off my pre-existing knowledge, but here's a more in-depth explanation of the macOS and FreeBSD situation (which aligns with my understanding):
Essentially, macOS was indeed based on NeXTSTEP originally, but over the years they copied quite a bit of BSD code over (mostly FreeBSD I think). I don't think the Unixy parts of the original NeXTSTEP survives much in modern macOS.
Much of the macos Unix userland is from FreeBSD as are some parts of the kernel, such as the ip stack. Check the man pages for cp and friends in mac and I believe they still reference FreeBSD.
> And the received wisdom about long options in the BSDs is a quarter of a century out of date.
Incidentally, so is much of the FreeBSD code. Many things were taken once, never updated from upstream again. I think a lot of the userland did get an update somewhere around 2014... all of a sudden, cal would highlight the current date, years after that happened upstream. But the IP stack hasn't gotten any updates from upstream AFAIK, probably because Apple customized it and it's too much work to merge in improvements that probably won't be noticed on client systems (things like syncookies).
There are implementations of cp out in the wild that do not recognise the --recursive flag. OpenBSD was mentioned in the article and there’s also busybox cp https://busybox.net/downloads/BusyBox.html
I don't think any new languages will easily beat the existing ones, simply because of the mass of training data that is available. An LLM will have a much easier time one-shotting Java than even Rust today because it doesn't have to look up much and the ecosystem was stable for many years, so the internet is filled with content that is still up2date. Building a new language (or even altering existing ones) will take much longer to get into the models.
LLMs that have to constantly fix their code and look up libraries or features are much slower, more expensive and more prone to create inefficient and slightly wrong code. Sure, an LLM can just create a new web framework from scratch, but you usually don't want to spend your tokens on that.
I also think that with LLMs, new languages will have more trouble building an ecosystem, because until now, the popular libraries had a "proof of work" that kinda also made sure that they were well-trodden and maintained. Now, anyone can just push their new generated library and we have no clue on how to compare (and tbh reading LLM-generated READMEs is also not pleasant).
"LLMs dont create anything new, if programmers stop reading the code technology will be forever frozen to 2022, no new programming languages, operating systems, concurrency primitives, databases, networking protocols, UI frameworks everything will be based on the training data and future generations will forget about all the primitives we now take for granted.
If someone creates a new programming language/ framework or new better way to do async or whatever, no one will use it because it is not in the training data and it wont take off because everyone is using LLMs. It will be like using the same Lego pieces over and over."
Mmmm idk. I used an LLM to write assembler in my made up API so I don’t think what you say is true. The value in LLMs is precisely that they are not just regurgitating training data, but rather inferring concepts extracted from trained data. If a programming language used concepts completely disconnected from existing paradigms you’re probably right… but that would also be quite challenging for humans to learn to use, since by intrinsic construction it would also be widely separated from human language.
Esoteric languages like BrainFuck are esoteric and difficult precisely because they go out of their way to eschew conceptual links to existing languages or paradigms.
So if you invented a new type of esoteric language with arbitrary syntax and strange operators (not sure how you’d do that, exactly, iirc all fundamental binary operators are known) it might be impossible to use with an LLM even if the user manual was in context… but aside from that, languages and the underlying concepts are extremely generalizable.
Yeah. I have my own file formats for music, pixel art, and levels in a little game I’m building with the kids. LLMs are really good at understanding these proprietary formats that exist nowhere else in the world except on my old laptop.
> I used an LLM to write assembler in my made up API so I don’t think what you say is true.
I think you are underestimating the amount of data/context that is required to use a battle tested general purpose language, for both humans and LLMs. The ecosystem requires official docs, stack overflow answers, blog posts, tutorials, existing source code, subreddits, issue/PR discussions of undocumented features, obscure mailing list threads with rare insights, books, youtube videos, benchmarks, tests suits... and the ecosystem of libraries for the language that also need their own official docs, stack overflow answers...
You also need the collective audit by the community and assurance that this language has been used in production by countless others.
In the age of intelligence on tap, any new language not specifically designed for human-only use will be born into the world with an attendant plague of documentation. And languages are shockingly generalizable. There are few things in any language that cannot be done in any other. Even those are computationally equivalent to some other set of instructions.
What might be the case though, is that new languages will use more context to think about until they are well represented in the training set.
> I don't think any new languages will easily beat the existing ones, simply because of the mass of training data that is available.
Seems like a solvable problem though by generating synthetic data that’s guaranteed to be accurate through linters, compilers and tests.
If it’s ~9 figures to train a frontier model, it seems like training on a new language could be a rounding error if it was a priority.
I could see the appeal of a new agentic-friendly language that’s focused on minimizing tokens. The standard library could be massive with no concern of making the language easily readable or learnable.
> Seems like a solvable problem though by generating synthetic data that’s guaranteed to be accurate through linters, compilers and tests.
This makes sense and is very insightful, thank you. But with that solution it seems that only LLM companies will be in the position to create new languages.
Tremendous amounts of the Java out there in the training corpus would be based on outdated patterns, especially anything pre-Java 8 or pre-Java 21 (Pattern Matching, Project Loom). I don’t think this negatively impacts the quality of LLM Java code but it sort of calls into question whether this is simply a case of more is better.
My personal experience is that LLMs are quite good at one-shotting complex solutions in both Rust and Go, and tend to be idiomatic.
I've been playing around with a new DSL, and I've had good luck adding a "describe" feature, eg,
newdsl describe some_feature
This returns the docs for that language feature. So instead of a giant SKILL.md containing the language spec, it exposes a way for an LLM to introspect.
DSLs climb the ladder of abstraction and constrain the solution space at the language level, which IMO provides tighter feedback to both humans and machines.
The frontier models are exceptionally good at one shoting rust. I find them to be even better at writing rust than python (and the dataset for python must surely be bigger). I think there might be a threshold of enough data for a programming language to make it useful for an agente
All of those verbs basically mean "degrade an existing system, after the fact". If anthropic states beforehand that certain use cases are not possible, it should be fine, no?
To give another (bad) analogy: The Pens aren't made to be weapons themselves, they are not intended for that. If the DoD now tries to shoot pens as projectiles and they just melt, that's no reason to classify the pen manufacturer as a supply chain risk, the product was not altered after the fact.
Of course, there _is_ a difference in "It could do that, but it shouldn't" and "It cannot do that". But it is not that large. That's why I don't see it as that clear cut.
Most of the environmentalists will tell you that it's dumb to shut down nuclear, but building new plants just takes too long and is too expensive. Why then not just put the money into things that are cheap now and will get even cheaper tomorrow?
Hedging against downtime is comparatively easy, just diversify by location and improve the grid, which is way less expensive than building out power plants.
Every source of power has pros and cons. They all have risks and benefits.
If there is a push to do a specific clean energy I think we should go for it regardless of the cost. If you think the climate issue is going to be a very severe issue then you should take every option at our disposal and encourage every push for an alternative to fossil fuels. Since you are refusing this, then I assume you don't think it is severe.
Large countries may be able to hedge against downtime, but smaller countries can't. Also, like I said, we don't really know the impact of all of this which is why we should diversify as much as possible. One of those diversifications should be nuclear as well as solar, wind, and hydro.
Where in comparable countries (= in europe) did new reactors take less than 10 years (from scratch even)? So we are at at least 10 years. But more realistically, taking recent megaprojects into account, its 20 years. In that time, batteries are way ahead and you can overbuild _so_ _much_ renewables and people even do it without subsidies (strangely, nobody builds nuclear plants without subsidies).
regarding the "stable energy" point: germany has one of the most (if not _the_ most) stable grids in the world and that is even with 50+ % renewables. And given it sits in the center of europe with grid connections all around, it's far cheaper to buy from whomever has the most favourable weather anyways (and sell to them if they don't). Thats why one of the biggest issues right now is not nuclear, but grids.
- fully-customizable emojis (think of a RPG-like character customization screen)
- heck, why not full jpegs/gifs?
- some unicode programming script (running Doom)
- ?
That said, some very minor (HN-style) nitpick:
> Otherwise for an n byte code unit this is (5n+1) / 8n, that is 5n+1 content bits out of a total of 8n bits from n bytes. We can rewrite this as (5/8) + 1/(8n) which moderately quickly approaches 5/8 = 62.5%. It is nice that this limit is nonzero and does not depend on n.
Isn't a limit by definition no longer dependent on n?
U+E000–U+F8FF, U+F0000–U+FFFFD, and U+100000–U+10FFFD can already provide you with your own emoji, as that range has been reserved for private use. Extending the range further might make sense if you need even more space in your program, but that's a lot of space already.
2-3 bytes are not much space for anything. Sure, you could use multiple successive ones of these code points and define your own "continuation" encoding in these ranges, but that doesn't seem right to me somehow
That combination is how it already works. You can build combined "characters" (grapheme clusters) from multiple code points, e.g. you could have a "base emoji" followed by a "modifier" emoji, and AFAIK that's how emojis with different skin colors work (one code point for the base emoji (e.g. 'thumbs up'), and a number of skin color modification code points which can be applied to all emojis that involve skin color.
I agree with you that Unicode urgently needs a scripting capability (*), but my plan was to just implement it using invisible tag characters [1] or something like that - but of course allowing a script to be written in a single codepoint is the much more elegant solution.
It also neatly solves the problem of how to write Unicode strings inside scripts inside Unicode strings and also scripts inside Unicode strings inside scripts inside Unicode strings.
Another one: encode instructions on how to draw the glyph into the text itself. The string becomes both the text and the font. Why not make it turing complete and as powerful/complex as TTF.
Imagine someone using the same fully customized emoji multiple times in the same text. Seems like a waste of space. Maybe better to encode just a UUID, and send the image codebook separately.
Not sure if "The U.S governments gold reserves" also includes the ones from other countries though.
reply