HNHacker News
TopNewBestAskShowJobs

LightMachine

2,083 karma · joined September 27, 2015

submissionscomments
LightMachine··on Bend – a language that blocks AI mistakes via proof and runs on GPUs
no, that's a good question. half of the point of HVM is to be an incredibly fast evaluator, in the "raw speed" sense. the other is to be an incredibly fast evaluator, in the "asymptotical" sense. in the first sense, Bend2 supersedes HVM. in the last sense, HVM is still king. on higher order computations that involve λ-calculus and the like, nothing beats the HVM. but I also realize most people aren't doing λ-calculations. so, Bend is made for the general public and lower-order programs, while HVM remains for the niche group of researchers and λ-calculus enthusiasts
LightMachine··on Bend 2 and the Vibe-Coding Trap
You just vaguely called the language "worse" without bringing a single concrete point. I can't defend my design choices without knowing what you don't like about it
LightMachine··on Bend 2 and the Vibe-Coding Trap
I don't know either :(

I'm not a celebrity and I don't like celebrities

LightMachine··on Bend 2 and the Vibe-Coding Trap
I think people are genuinely bitter about it, that's usually how my projects are received
LightMachine··on Bend 2 and the Vibe-Coding Trap
(author here) Bend1 indeed has no significant active userbase

I don't think that means it was "unsuccessful" in the sense you imply, though, because the project was never meant to be used in production. It was there to display a milestone (running inets on the GPU) and I was very clear it wasn't ready to be used yet. For example, it had only 24-bit integers, a 2 GB memory cap, and other limitations that made it unpractical. I still don't know why it has so many stars. I posted it to hacker news and that just happened. I guess it just went viral without really being ready yet, which got us to where we are now.

Anyway the commit history is back now. I apologize for nuking it

LightMachine··on Bend 2 and the Vibe-Coding Trap
It will, there is just too much to do! It is a programming language. With a consistent, non-standard proof system. That compiles to GPUs. We're a small team. Please be patient
LightMachine··on Bend 2 and the Vibe-Coding Trap
Victor here. I haven't "worked" on Formality. I've founded it. Designed every part of it. Before LLMs!

sighs

Here's my response to this ridiculous accusation: https://news.ycombinator.com/item?id=49753898

I can't internet anymore. I need a beach

LightMachine··on Bend 2 and the Vibe-Coding Trap
Note that using linked lists for strings is actually more "parallel friendly" because you can take the head/tail and spread it around 16k GPU cores in O(1), unlike in Haskell, unlike arrays, which require a linear copy, becoming quadratic. So, the right "default type" isn't that clear on Bend, because GPUs behave very differently from CPUs.

That said, yes, we definitely should have a compact Text type. I'll add it over the weekend.

LightMachine··on Bend 2 and the Vibe-Coding Trap
1. LLM inference is cheap compared to the cost of a bug, and you can use tools to automate the proof-work, as you said so yourself.

2. Why would it? The AI shouldn't load already completed proofs, only their type signatures (which are one liners). Sounds like you're projecting bad context management?

Caching only works until you change a deeply nested constant. Then you must wait 2 hours as Lean re-checks every transitive dependency of a massive simp-ridden codebase. Also, first time check time IS relevant to UI. Nobody wants to wait 2h to start using a library after they first download it. Perhaps you don't mind that but I do; that's the kind of bad UX that made me go for that design choice on Bend. Which again, may be wrong or may be right. But it was intentional.

Having a checker that is just fast by construction, regardless of caching, was a top design priority, and I weighted it over verbosity in a layer I believe nobody will be reading anyway.

LightMachine··on Bend 2 and the Vibe-Coding Trap
The history is back...
LightMachine··on Bend 2 and the Vibe-Coding Trap
(Author here) What about it isn't working for you?

Also, wrote a response to this whole thread here:

https://news.ycombinator.com/item?id=49753898

LightMachine··on Bend 2 and the Vibe-Coding Trap
So are Haskell's, since 20 years ago, with no options for years?

We will introducing binary buffers eventually. The project is new...

LightMachine··on Bend 2 and the Vibe-Coding Trap
"The developer has built an entire language around a field seemingly without realising that said field exists."

That is incredibly funny.

Here's a talk about formal verification I made 7 years ago @ DevCon:

https://www.youtube.com/watch?v=0fg1QbeeqNU

Here's Cedille Core, my implementation of Aaron Stump's self types, a Computer Science professor who taught me a lot, ~8 years ago:

https://github.com/VictorTaelin/Cedille-Core

I also implemented Kind-Lang 5 years ago, way before LLMs:

https://github.com/higherorderco/kind

I dropped out of Federal University of Rio de Janeiro to study this subject independently, because I was passionate about it, and I spent nearly 10 years doing so, daily, on weekends. That's what I do.

Bend proofs being verbose has nothing to do with me not knowing that inference, unification, or program search exists. Kind had these, 5 years ago. In fact, I've also been researching the later, and I built SupGen, which overperforms every published symbolic program synthesizer in the literature by 10x or so. This is unpublished yet, but you can find my posts about it 2 years ago on X (I'm @VictorTaelin).

So, why is Bend verbose???

Because it makes it fast. It is intentional. It is my vision that a good proof language should be fully explicit, because this reduces proof-checking time significantly. That is what makes Bend realistically 10x-100x faster than every alternative.

But wouldn't that mean it is much harder to write it?

No. As you said it yourself, we have tools that can fill these proofs today! Not just AI models. You can apply these tools to produce Bend proofs, while the language itself remains a thin, dumb proof kernel that does one thing, and does it well.

If nobody is reading these proofs (because they're written by AI and automated tools), then, it is, in my opinion, irrelevant, as proofs will eventually become a layer nobody looks at, just like generated assembly.

Of course, I could be wrong here!

But it is misleading, if not just a bit malicious, to claim I "vibe-coded" a language without knowing about a field I've spent a decade researching about.

Every single part of Bend is an intentional choice I made after considering every alternative. I use LLMs to fill code after I make all hard architectural decisions because they type faster than me, and I'd rather spend my time doing useful experiments than typing trivial functions, even though I could.

Incidentally, deciding what I should NOT include took me way more time and effort than any line that was shipped, and there are perhaps millions of lines of code, manually written by me, that I threw away, backing up these 4k that went into the final design. An artist once told me you must first paint a Rembrandt before you can draw a cartoon that's simple in the right way, yet that might mislead someone who has never drawn into thinking you don't know what you're doing. I guess.

LightMachine··on Bend – a language that blocks AI mistakes via proof and runs on GPUs
yeah that makes sense, thanks for the feedbacks!
LightMachine··on Bend – a language that blocks AI mistakes via proof and runs on GPUs
commit history is back now!
LightMachine··on Bend – A language that blocks AI mistakes via proof, on CPU and GPU
the entire language is based on linear types! it says so in the GUIDE yes
LightMachine··on Bend – A language that blocks AI mistakes via proof, on CPU and GPU
Ty! Commit history is back now
LightMachine··on Bend – A language that blocks AI mistakes via proof, on CPU and GPU
Commit history is back!
LightMachine··on Bend – A language that blocks AI mistakes via proof, on CPU and GPU
Commit history is back!
LightMachine··on Bend – a language that blocks AI mistakes via proof and runs on GPUs
Commit history is back!
LightMachine··on Bend – a language that blocks AI mistakes via proof and runs on GPUs
Commit history is back!
LightMachine··on Bend – a language that blocks AI mistakes via proof and runs on GPUs
1. I do, but probably not in the current version, since I believe these proofs probably need full closure cloning to be ergonomic.

2. You can express anything actually, because you can clone data, just not functions. So, anything you could implement with datatypes (i.e., without cloned closures), you could probably also prove. But again, people use and abuse closure cloning a lot in Lean. So, how ergonomic would that be? I don't know. It is less about expressivity and more about ergonomics.

3. No, just in the runtime for now. Checking proofs on the GPU will happen when we implement Bend in itself.

LightMachine··on Bend – a language that blocks AI mistakes via proof and runs on GPUs
The project got a lot of attention at launch, but it wasn't really ready to be used back then. There were too many limitations, like u24 numbers (yes), 2 GB memory limit, pervasive strictness (if-then-else executed both branches). It was just not practical.I think (hope) that explains a lot of it. But honestly there is also my own failure into making the language actually be used, rather than just a viral moment :( I hope it will be different this time!
LightMachine··on Bend – a language that blocks AI mistakes via proof and runs on GPUs
I honestly had no idea people would be so upset about commit history. I just wanted to avoid leaking sensitive info, that's all. I'm running through the commits to ensure nothing personal leaks and I plan on putting the history back.

Also Bend's stars came on the V1 launch. This is V2. It already had 20k before.

LightMachine··on Bend – A language that blocks AI mistakes via proof, on CPU and GPU
should I read this as "I wish I could find a guy like you" :')
LightMachine··on Bend – A language that blocks AI mistakes via proof, on CPU and GPU
good question we'll try
LightMachine··on Bend – a language that blocks AI mistakes via proof and runs on GPUs
Thank you!!

Currently, parallelism works in any multi-core CPU, and in Apple M-series and NVIDIA GPUs.

LightMachine··on Bend – a language that blocks AI mistakes via proof and runs on GPUs
fixed ty
LightMachine··on Bend – a language that blocks AI mistakes via proof and runs on GPUs
Ohhh. Ok. I see the confusion. That's bad syntax then. The 'a' parameter is not the type of the elements. 'A' is the type of the elements. 'a' is just the "quantity of the type of the type of the elements". Yes, that's a mouthful, and somewhat abstract. This is similar to Agda's universe polymorphism. The reason it exists is because there are two "types of types" (i.e., kinds). Copiable types, and non-copiable types. So, this argument allows you to parametrize a function on both of these kinds. That way, you don't need to write List.length twice: one for copiable types, and once for non-copiable types. Think of Rust generics. 'a' is playing the same role as a "Copiable" trait would in Rust. It is just an extra compile-time argument to avoid boilerplate. But yes, I see how this can be confusing and I think I know how to improve that syntax.

Yes, `Array<U32> & U32` is just `(Array<U32>, U32)` and now that you point it I believe I made a bad choice, no excuses. Also, `arr[3]` doesn't return a number. It returns a copy of the same array, plus a number. So, if the element at index 3 is 123, tthen, `arr[3]` will return `(arr, 123)`. Now, you might be thinking: that's terrible. And yes, it is. I realize it now. I should have made the `arr[3]` syntax return 123. It is there for a very good reason though. It preserves linearity. It is part of the termination argument that makes Bend consistent. But yes, exposing it to the end user was most likely a mistake. I will redesign that syntax. Sorry about it.

LightMachine··on Bend – a language that blocks AI mistakes via proof and runs on GPUs
2 isn't a big claim though, I think anyone developing Lean or Agda would agree these would be much faster with zero inference, unification or search? They'd just complain the language would become unergonomic, and that's true. Bend is very verbose.

Thanks and your feedbacks are reasonable, I appreciate

Page 1 of 9Next →