This is fairly impressive, at least at first glance and hits a niche that is interesting. I think a big challenge in finding adoption for a new lang is in the application, or more specifically, when/why/where it's used. This is something I'd love to hear from folks involved in this (if reading) what they think those are and if/how that helped them shape the lang. Good luck!
Tungsten is terse and fairly token efficient (20-30% less than Python). I've found it works well for prototyping with LLMs - even though they haven't been trained on it.
I've been using it lately for some scientific exploration, made a flip-graph search for matrix multiplication algorithms (low-rank decompositions of the matmul tensor over GF(2)). It has independently matched the world records for 3x3, 4x4, and 5x5.
Oddly enough, even though it's fresh out the gate, I think it makes a good fit for language implementation (at least as a stage1). I have a few reference lexers, an arena-slabbed AST layout, and a NaN-boxed 64-bit layout in the repo.
The bignum math is nearly as fast as GMP, without GPL license issues. The native regex engine was matching PCRE.
There's a scrubbing feature in the REPL that is pretty fun as well - inspired by a paper and talk from Bret Victor a while back.
Can LLMs generate only one style of website? Inter font, dark background, elements that fade in, code in a macOS shell container, neverending lists of features, too many buzzwords.
God they all look the same, and I have permanently associated this style with slop.
That said, a fully vibe coded language created 7 hours ago and published 6. Have you built anything with it in the intervening hour to try it out at least? To make sure it does what it says on the tin. Or you just one shot the thing with Claude and published without review?
So I want to preface my next point by stating actually really like how syntax reads, hitting a sweet spot of leaning just enough into APL's symbol-focused terseness without losing the familiar structure of literally every other popular programming language ever that makes it easy to follow the code. I imagine it could be a great language to pick up for working out an algorithm with pen & paper (the best limus test for how well a language functions as pseudocode imo).
Having said that, I have my doubts about the reduced token claims because of a lack of "begin" and "end" or "{" and "}" delimiters. Surely, if your language is identation based, LLMs will treat significant whitespace as a token too, since they need to keep track of it? Which would result in an extra token per newline compared to using explicit begin/end token?
I suspect that to really optimize for tokens one would have to go the concatenative route, which significant whitespace very much isn't.
5 comments
[ 3.2 ms ] story [ 19.7 ms ] threadTungsten is terse and fairly token efficient (20-30% less than Python). I've found it works well for prototyping with LLMs - even though they haven't been trained on it.
I've been using it lately for some scientific exploration, made a flip-graph search for matrix multiplication algorithms (low-rank decompositions of the matmul tensor over GF(2)). It has independently matched the world records for 3x3, 4x4, and 5x5.
Oddly enough, even though it's fresh out the gate, I think it makes a good fit for language implementation (at least as a stage1). I have a few reference lexers, an arena-slabbed AST layout, and a NaN-boxed 64-bit layout in the repo.
The bignum math is nearly as fast as GMP, without GPL license issues. The native regex engine was matching PCRE.
There's a scrubbing feature in the REPL that is pretty fun as well - inspired by a paper and talk from Bret Victor a while back.
God they all look the same, and I have permanently associated this style with slop.
That said, a fully vibe coded language created 7 hours ago and published 6. Have you built anything with it in the intervening hour to try it out at least? To make sure it does what it says on the tin. Or you just one shot the thing with Claude and published without review?
Having said that, I have my doubts about the reduced token claims because of a lack of "begin" and "end" or "{" and "}" delimiters. Surely, if your language is identation based, LLMs will treat significant whitespace as a token too, since they need to keep track of it? Which would result in an extra token per newline compared to using explicit begin/end token?
I suspect that to really optimize for tokens one would have to go the concatenative route, which significant whitespace very much isn't.