Grok had the potential of being the #1 LLM if they actually went through with Elons original promise of an "uncensored model". Meaning no guardrails, it does what you tell it, no matter what. Sadly Grok is even more restricted than even OpenAI's models, and despite being marketed as "edgy and ruthless" it is THE MOST politically correct model on the market. ChatGPT or Claude will gladly go along with religious or nationality based roleplay, while Grok outright refuses. Oh and you can't even use it for any pentesting whatsoever because a) it's far worse than the competition b) it completely refuses to even LOOK at low level code.
But this goes along with Elons same promises for X; "X will support free speech" etc even though it's trivial to get banned for the most pointless things.
> if they actually went through with Elons original promise of an "uncensored model". Meaning no guardrails, it does what you tell it, no matter what.
When will HNers realize that this is a fever dream? This is an edgy teenager's interpretation of "good".
The second someone uses a frontier model to attack other entities or hurt innocent people it will get (rightfully) shut down by the government.
We already saw this with the Fable export controls (and no one had even used these models offensively).
Open models will reach the same fate once the gov't realizes they are good enough. They will just ban weight hosting, require safeguards for any model routers that accept US payment, and embargo anyone that doesn't do these things.
There is a reason we don't let everyone in the world own RPGs.
1. The censoring goes much further than refuting to participate in a felony.
2. The censoring is done by private companies outside the democratic process.
3. Censoring requires a single source of truth. Somone who has then the power to decide what is true. Also most people will blindlessly beliefe everything an LLM says.
No company will be able to get away with offering a completely unconstrained commercial model. The legal risk and pushback from governments is too high.
No guardrails? So, what? Someone can get grok servers to attack critical infrastructure out of boredom? Take down a hospital network during an emergency or something? There was never a world where musk and co were going to take that risk.
And people thought swatting was bad! Just imagine that jfc
My guess is, within the next 3-5 years, most ALGOL descendant languages will become obsolete, and S-exp based Lisp dialects will take over. Objectively superior.
Behold a native kernel, no inline asm or linker scripts, of any kind. The full compiler pipeline is controllable through the compiler (you can arbitrarily target, devise, or enable/disable various optimization passes, for instance you can enable LICM at will). Also has a hard 1:1 correspondence to C/C++/Rust/adding more languages soon.
This does look interesting, although I did get a chuckle from the "no inline assembler" claim and then seeing x86 intrinsics in the source for seeing some special registers like the segment registers, GDTP, setting IO ports, and some such. Those are of course necessary, but at least in terms of portability, they're not that far off from inline assembler.
From a quick glance over your example, it looks like a hodgepodge of Scheme, Clojure, and Common Lisp with some Rust-y constructs in it. If you don't mind elaborating, why not take some existing "embedded" dialect like Pre-Scheme and compile that? Because currently this looks a lot more like Rust-with-parenthesis rather than a Lisp. Of course if that's the goal then that's fine, but I'd like to hear some elaboration on that.
>My guess is, within the next 3-5 years, most ALGOL descendant languages will become obsolete, and S-exp based Lisp dialects will take over.
In AI-driven world, programming languages have become more of a hobby, especially in regards to syntax/semantics. Importance is now mostly solely on tooling quality features and compiler-enforced guarantees. Rust has always been popular "written in" target, even more now, and probably the last language shift for a long time, offering compiler-time memory safety, excellent compile messages, packaging/deployment ergonomics, etc.
My guess is, your language (as is the submitted one) compiler/tooling is written in Rust and made by/in-assistance-with AI, probably Claude.
Curious why you’re so bullish on S-Expressions now of all times.
It seems like the idea of the macro, and more generally of expressing code succinctly, is the closest to obsolete in my memory?
The other half of the Lisp sales pitch (image based development, constantly inspect state, hot swap code, REPL, etc) seems like what has retained currency in the LLM age.
If you write a compiler for a low level Algol-family language in a LISP, then LISP's homoiconic nature makes certain patterns possible which do not come so easy in other languages.
The compiler becomes a library in the host language. As you can use the syntax of the host language for the compiled language, you can create host-side defining forms like (define-compiled-function [NAME PARAMS & BODY]) which parse the body of the compiled function into an AST and bind the resulting data structure into a namespaced variable of the host language. This way you can rely on the host's namespacing mechanisms and probably reuse even its packaging and code distribution model for your low level language.
Another interesting feature which just "falls out" is compiler macros: you can use ordinary functions of the host language as macros (code transformers) in the compiled language.
Then you can write a lowering function which takes one of these AST vars, walks its call graph, resolves references and lowers the whole thing into your target language, be it Python, Go, LLVM IR, assembly, whatever.
If you pass a context to your lowering function which binds settings dynamically like target arch, word size, C calling convention, etc. then the code generators can emit the corresponding lowerings and you get portability using the dispatch/polymorphism facilities of the host language.
This way you can push most of the complexity of the language to the LISP side. Basically you get a programmable compiler for your low level language.
I expect to see a lot more examples of this pattern in the coming years.
> It seems like the idea of the macro, and more generally of expressing code succinctly, is the closest to obsolete in my memory?
That seems true in a world where we completely stop looking at code. Right now my reality is giant verbose PRs written by agents in Java, and it sucks to review.
Yeah, I mean this is somewhat compelling, although the old arguments people brought out (macros are obfuscatory) seem to grow more teeth if agents are writing the macros.
So I guess the idea is tastemaker humans spend all their time coming up with sweet macros and telling agents to refactor the ever shrinking code base.
But even still I think the main argument for S-Expressions (it’s easiest for humans to create DSLs by working on serialized AST) has become weaker. If DSLs are the best way to make a code base readable, you can now have your agent create one with whatever syntax you like!
> If DSLs are the best way to make a code base readable, you can now have your agent create one with whatever syntax you like!
I think these things are going to be true:
- For a specific well-defined coding task, an LLM coding agent will be able to execute it quicker than humans, regardless of how it does it.
- Codebases which are well organised will be easier for an LLM to manipulate than codebases which are obscure and surprising.
I mean.. I think it's plausible that something like "lisp makes DSLs easy, DSLs are a great way to arrange code" is especially true with LLMs; but I'd also think you'd need to know when to use (& when to not use) DSLs to get effective results from this.
Whereas, say, you could have the LLM come up with a DSL in a way which is high friction for the LLM to do it ... but, you'd get the result a bit slower, & maybe worse.
Thinking along these lines myself lately. Even better than dsls is dsls directly descended from recognizable formalisms, which achieves compression for humans and agents at the same time, and is even more effective than any other kind of dsl’s at restricting the bad kind of ai “creativity”.
I’ve been experimenting with stuff like “this project is a Kahn process network, every change is strict conformer to that model, add features only by adding nodes”. As a bonus if you’re strict then porting the specific implementation to a new language should be easy.
To me stuff like this feels like the future of programming.. details don’t matter but design language does. not leet code of fancy data structures from scratch but at least a basic familiarity with LOTS of them, a working knowledge of vast zoos of expressive patterns and automata, etc.
> It seems like the idea of the macro, and more generally of expressing code succinctly, is the closest to obsolete in my memory?
Seems more important than ever? Every model degrades the more context you use, programs that can be described more succinctly will be better made, at least when using LLMs to create these, as it's much easier to fit more "meat" per token.
I'm on the same "S-Expressions taking over is inevitable" but to be fair, I've been on this train for the last decade so maybe I'm slightly biased.
Token efficiency is good, but in practice, model familiarity is more important.
Look at what happened with TOON. They came up with a format meant to replace JSON for agents, but despite being way more succinct, its novelty meant that LLMs spent just as many tokens correcting mistakes while using it.
TBF, that was several months ago, an eternity in LLM time. Someone should rerun those language studies, it's possible the SOTA has changed.
That’s a plausible story, but doesn’t seem to bear out in terms of models being amazing at Lisp. Like, Sonnet 4.5 was writing me emacs Lisp with unbalanced parentheses.
I don’t really have faith that I could write macros of such incredible brilliance that it would outweigh the models’ facility with Python.
ArtCraft lies. It makes extensive use of crates, which to me defeats the "from scratch" argument. The whole point of doing it from scratch is that you get full control of every line of code in the compiled binary.
This is an example of a true "from scratch implementation" (as long as you target the freestanding compile option, hosted still depends on pthread for threading). Absolutely zero external code or references anywhere outside the stated repo. (Not even compiler builtins or includes are needed). You can drag and drop it wherever you'd like hit compile and you're done.
"Written from scratch" just means that no external code or existing libraries were used in producing something. Nowadays it's preferable to reusing code/crates/whatever because a) you avoid supply side attacks b) the implementation is likely going to be more correct and performant than alternatives c) it's actually easier to write your own thing than to download an existing lib and wrangle it into your project.
Yep. Not only that but the quote (even if taken out of context) is factual. >99% of people load up their computers with comical amounts of ram when they really, really don't need it. This excess then only fuels the creation of memory inefficient apps. People are in shock when I tell them they could take the whole OS state when running any AAA game, reduce memory usage by an order of magnitude (if optimized correctly) and they couldn't spot a single difference. Most of those >200GB game installs could literally be reduced to a few hundred MB (no, you don't need massive textures + you can generate most on the fly).
The frontier labs are entirely AI generated at this point. By entirely I mean ~100% of the code and supplementary training pipelines are AI created, with ZERO human guidance or oversight. And compare the results, look at Opus 5.5 vs the original Opus (which was human made). See the difference?
In fact, my personal prediction is that OpenAI and Anthropic will let go of all their human employees by Q1 2027.
There are a lot of views on current AI progress amongst smart people. Not everyone is convinced they are improved in all areas. What specific difference are you gesturing at? the improved coding performance? differences in writing style? Agentic ability?
But this goes along with Elons same promises for X; "X will support free speech" etc even though it's trivial to get banned for the most pointless things.
reply