4 ms·

I cant wait to have no dependencies. An extreme example is now when I make interactive educational apps for my daughter, I just make Opus use plain js and html

by jackdoe 5mo ago

I cant wait to have no dependencies. An extreme example is now when I make interactive educational apps for my daughter, I just make Opus use plain js and html; from double pendulums to fluid simulations, works one shot. Before I had hundreds of dependencies. Luckily with MIT licensed code I can just tell Opus to extract exactly the pieces I need and embed them, and tweaked for my usecase. So far works great for hobby projects, but hopefully in the future productions software will have no dependencies.

Aperocky 5mo ago
I am torn because I like rust over go, and rust is better from an LLM perspective. But the dependency philosophy on rust is basically a security blackhole whereas go is much better.
- kblissett 5mo ago
  I have found Go is an amazing language for LLMs. What do you prefer about Rust?
  - Aperocky 5mo ago
    A portion of context and vibe protection that are required is exported to the compiler. In addition rust binaries are generally smaller both in terms of size and footprint.
    - Imustaskforhelp 5mo ago
      I sort of agree with you but for me, I prefer golang because I believe that for most use cases, Golang fits perfectly (I run a 500mb 7$/yr vps with debian and use golang binaries) Cross portability and compilation and its very few dependency/stdlib approach with simplicity, I just really love golang. I had built[0] a cuckoo.org alternative at https://fossbox.cloud https://fossbox.cloud which has only one dependency of gorilla web sockets aside from stdlib If I were to rewrite it in rust, I couldn't say the same. Golang's stdlib is that good. My point is, although I understand Rust can have some advantages in other areas, the advantages of golang outweigh rust for me by a very high margin. There is also the factor that I just feel more comfortable reading golang code and picking through it than rust. It is my opinion that you can go a very very long way with a garbage collector than people imagine even on constrained systems. Unless absolutely necessary, thinking about GC feels like it might be a premature optimization in many instances which is worth thinking about. [0]: More like (vibecoded?) as this is just a single file main.go which I had prompted on gemini 3.1 pro sometime ago. It was just a prototype which works surprisingly well that I had made because I was using the cuckoo website with friends but it kept on lagging.
      - Aperocky 5mo ago
        Well I almost have the same story, my agent harness is a 5mb rust binary that runs as systemd service and occupy 10mb of memory after days. This handles all communciations between 100+ agents. Now I think go will come close to this number, so in reality, there might not be a real difference. But a leak somewhere is far more likely especially as these are mostly vibe coded (my binary has multiple functionality). The biggest advantage that go have over rust is the stdlib and ecosystem that doesn't depend on 100 packages. And maybe that will be the deciding factor in the future or someone (I'm getting increasingly itchy for it) will need to reinvent the ecosystem to be less like npm.
  - hombre_fatal 5mo ago
    You can encode so much design and intent in the Rust type system. It’s one of the best things about Rust. I prefer to write Go if I were doing everything by hand. But now everything is Rust. And a quick scroll through my Rust types, the discriminated union types, the discriminated error types, the high level application types, it’s just so much better for spec’ing out a system and leaving no question about what some bit of code is trying to do and the states it’s trying to prohibit. And with an LLM, the hard things about Rust that would’ve had me asking questions on IRC are not hurdles anymore. Granted, it has its own cultural NPM/RubyGem dep spam problem when you watch cargo install’s output.
- mamcx 5mo ago
  Vendoring don't basically copy what go does?
  - Aperocky 5mo ago
    You can trust a single big stdlib more than the 100 dependency that tokio pulls at any given time.
    - RALaBarge 5mo ago
      Yeah then you can version lock changes to one thing post-evaluation vs or even easier as noted above, download the stdlib and host it yourself.
mandevil 5mo ago
The problem with this is now you are solely responsible for managing all of the changes, all of the variation of life. Chrome changed the shape of this API, you are responsible for finding it and updating it. Morocco changed when their daylight savings took effect, now you need to update your date/time handling code. There are a lot of these things that we take for granted because our libraries handle it for us, and with no dependencies you have to do all the work. Not a big deal for making a double-pendulum simulator for your daughter to play with that will stop mattering next week, but is a concern for a company which is trying to build something that can run indefinitely into the future.
- zdragnar 5mo ago
  As a general principle, I agree with you that large companies and teams benefit from common runtimes (i.e. libraries and frameworks). I don't buy the notion of things breaking down over time, though. For "first-party" code that sticks to HTML and CSS standards, and Stage 4 / finished ecmascript standards, the web is an absurdly stable platform. It certainly used to be that we had to do all sorts of weird vendor hacks because nobody agreed on anything and supporting IE6 and 7 were nightmares, and blackberry's browser was awful, but those days are largely behind us unless you're doing some cutting-edge chrome-only early days proposed stuff or a browser specific extension or something else that isn't a polished standard. Even with timezone changes, you're better off using the system's information with Intl.DateTimeFormat.
  - skydhash 5mo ago
    I don’t know where the fear of breaking changes in deps comes from, but most good projects tries to keep their API stable. Even with fast-evolving platforms like Android and iOS sdk.
    - awakeasleep 5mo ago
      It comes from trying to use Python apps you found on GitHub before uv tool install was a thing
gib444 5mo ago
Your LLM isn't a dependency?
- stronglikedan 5mo ago
  It's a tool for building things. I can build those things equally well with or without it, maybe saving some time with it (arguable)), but I'm not dependent on it.
  - gib444 5mo ago
    No, I'd posit the average developer who pulls in hundreds of deps but now uses LLMs to effectively replace them can not build things equally well without either. Of course most devs lie to ourselves because of our ego that pulling in deps is /just/ a time-saving measure, but of course we know there are some incredibly high quality libraries and frameworks that we don't have the skills or experience to replicate to the same level
    - redsocksfan45 5mo ago
      [dead]
v4nderstruck 5mo ago
well surely Opus would never introduce vulnerabilities into the code so that sounds like the solution.
- 2ndorderthought 5mo ago
  So true. Whenever I run opus I absolutely do not look at the code at all. That's for luddites.
solid_fuel 5mo ago
And of course, you will go over every line of code that Opus produces with the same scrutiny we expect of open source maintainers, right? Right? I'm going to go publish some MIT-licensed remote access code and get that into Opus's training data.
- fastball 5mo ago
  Correct (and secure) code is possible and readily doable. It is unclear if supply chain attacks can ever be fully mitigated.
- hombre_fatal 5mo ago
  Yes, I trust my LLM codegen and review process far more than the code I was never going to read from all of my transitive deps and every sequential update to them forever. This is a trivial bargain for most libraries we were using not long ago out of convenience. Like a library just for setting ansi colors for your TUI. Ideally you have minimal deps scoped to the truly hard things: libghostty, btrfs, luks, postgres, etc. Then you focus on the application and generate the mechanical glue code on demand with a solid harness that keeps the important stuff well-tested. Though you’ll need to figure out how to build that harness/process before it really delivers.
OtherShrezzing 5mo ago
I think in the relatively near future we’re going to start seeing sophisticated supply chain attacks into language model training data. It should be feasible to design vulnerabilities which look benign individually in training data, but when composed together in the agent plane & executed in a chain introduce an exploit. There’s nothing technical really stopping that from existing right now. It’s just that nobody has put the effort in yet.
- lacunary 5mo ago
  The develop-test-refine feedback loop for this kind of attack is so long (or expensive) that it seems likely to limit its real world use. Poison training data, wait months? a year? for the model to come out, see how well it worked, refine... or do you see a faster way to iterate?
  - sieabahlpark 5mo ago
    [dead]
  - OtherShrezzing 5mo ago
    Continual learning is the next major architectural milestone for the frontier labs. That’d reduce the iteration loop to days instead of years. If your attacker assumes that all or most software will be generated from language models, the time penalty is worth paying.
contingencies 5mo ago
Love it :) Excellent quippy summary of the zeitgeist. Added to https://github.com/globalcitizen/taoup https://github.com/globalcitizen/taoup
beacon294 5mo ago
Do you have this on a shareable place / forge? I have a farm animal spelling game and want to extend my library and build more ideas.
BigTTYGothGF 5mo ago
Now you're exposed to the real dependency, the browser.
- srcreigh 5mo ago
  Not to mention Claude
selfmodruntime 5mo ago
Comments like these are so incredible far fetched from reality. Are you really going to implement your own PyTorch? Why even compare your cute examples to enterprise solutions?

by jackdoe 5mo ago

Aperocky 5mo ago

I am torn because I like rust over go, and rust is better from an LLM perspective. But the dependency philosophy on rust is basically a security blackhole whereas go is much better.

kblissett 5mo ago
I have found Go is an amazing language for LLMs. What do you prefer about Rust?
- Aperocky 5mo ago
  A portion of context and vibe protection that are required is exported to the compiler. In addition rust binaries are generally smaller both in terms of size and footprint.
  - Imustaskforhelp 5mo ago
    I sort of agree with you but for me, I prefer golang because I believe that for most use cases, Golang fits perfectly (I run a 500mb 7$/yr vps with debian and use golang binaries) Cross portability and compilation and its very few dependency/stdlib approach with simplicity, I just really love golang. I had built[0] a cuckoo.org alternative at https://fossbox.cloud https://fossbox.cloud which has only one dependency of gorilla web sockets aside from stdlib If I were to rewrite it in rust, I couldn't say the same. Golang's stdlib is that good. My point is, although I understand Rust can have some advantages in other areas, the advantages of golang outweigh rust for me by a very high margin. There is also the factor that I just feel more comfortable reading golang code and picking through it than rust. It is my opinion that you can go a very very long way with a garbage collector than people imagine even on constrained systems. Unless absolutely necessary, thinking about GC feels like it might be a premature optimization in many instances which is worth thinking about. [0]: More like (vibecoded?) as this is just a single file main.go which I had prompted on gemini 3.1 pro sometime ago. It was just a prototype which works surprisingly well that I had made because I was using the cuckoo website with friends but it kept on lagging.
    - Aperocky 5mo ago
      Well I almost have the same story, my agent harness is a 5mb rust binary that runs as systemd service and occupy 10mb of memory after days. This handles all communciations between 100+ agents. Now I think go will come close to this number, so in reality, there might not be a real difference. But a leak somewhere is far more likely especially as these are mostly vibe coded (my binary has multiple functionality). The biggest advantage that go have over rust is the stdlib and ecosystem that doesn't depend on 100 packages. And maybe that will be the deciding factor in the future or someone (I'm getting increasingly itchy for it) will need to reinvent the ecosystem to be less like npm.
- hombre_fatal 5mo ago
  You can encode so much design and intent in the Rust type system. It’s one of the best things about Rust. I prefer to write Go if I were doing everything by hand. But now everything is Rust. And a quick scroll through my Rust types, the discriminated union types, the discriminated error types, the high level application types, it’s just so much better for spec’ing out a system and leaving no question about what some bit of code is trying to do and the states it’s trying to prohibit. And with an LLM, the hard things about Rust that would’ve had me asking questions on IRC are not hurdles anymore. Granted, it has its own cultural NPM/RubyGem dep spam problem when you watch cargo install’s output.
mamcx 5mo ago
Vendoring don't basically copy what go does?
- Aperocky 5mo ago
  You can trust a single big stdlib more than the 100 dependency that tokio pulls at any given time.
  - RALaBarge 5mo ago
    Yeah then you can version lock changes to one thing post-evaluation vs or even easier as noted above, download the stdlib and host it yourself.

mandevil 5mo ago

The problem with this is now you are solely responsible for managing all of the changes, all of the variation of life. Chrome changed the shape of this API, you are responsible for finding it and updating it. Morocco changed when their daylight savings took effect, now you need to update your date/time handling code. There are a lot of these things that we take for granted because our libraries handle it for us, and with no dependencies you have to do all the work. Not a big deal for making a double-pendulum simulator for your daughter to play with that will stop mattering next week, but is a concern for a company which is trying to build something that can run indefinitely into the future.

zdragnar 5mo ago
As a general principle, I agree with you that large companies and teams benefit from common runtimes (i.e. libraries and frameworks). I don't buy the notion of things breaking down over time, though. For "first-party" code that sticks to HTML and CSS standards, and Stage 4 / finished ecmascript standards, the web is an absurdly stable platform. It certainly used to be that we had to do all sorts of weird vendor hacks because nobody agreed on anything and supporting IE6 and 7 were nightmares, and blackberry's browser was awful, but those days are largely behind us unless you're doing some cutting-edge chrome-only early days proposed stuff or a browser specific extension or something else that isn't a polished standard. Even with timezone changes, you're better off using the system's information with Intl.DateTimeFormat.
- skydhash 5mo ago
  I don’t know where the fear of breaking changes in deps comes from, but most good projects tries to keep their API stable. Even with fast-evolving platforms like Android and iOS sdk.
  - awakeasleep 5mo ago
    It comes from trying to use Python apps you found on GitHub before uv tool install was a thing

gib444 5mo ago

Your LLM isn't a dependency?

stronglikedan 5mo ago
It's a tool for building things. I can build those things equally well with or without it, maybe saving some time with it (arguable)), but I'm not dependent on it.
- gib444 5mo ago
  No, I'd posit the average developer who pulls in hundreds of deps but now uses LLMs to effectively replace them can not build things equally well without either. Of course most devs lie to ourselves because of our ego that pulling in deps is /just/ a time-saving measure, but of course we know there are some incredibly high quality libraries and frameworks that we don't have the skills or experience to replicate to the same level
  - redsocksfan45 5mo ago
    [dead]

v4nderstruck 5mo ago

well surely Opus would never introduce vulnerabilities into the code so that sounds like the solution.

2ndorderthought 5mo ago
So true. Whenever I run opus I absolutely do not look at the code at all. That's for luddites.

solid_fuel 5mo ago

And of course, you will go over every line of code that Opus produces with the same scrutiny we expect of open source maintainers, right? Right? I'm going to go publish some MIT-licensed remote access code and get that into Opus's training data.

fastball 5mo ago
Correct (and secure) code is possible and readily doable. It is unclear if supply chain attacks can ever be fully mitigated.
hombre_fatal 5mo ago
Yes, I trust my LLM codegen and review process far more than the code I was never going to read from all of my transitive deps and every sequential update to them forever. This is a trivial bargain for most libraries we were using not long ago out of convenience. Like a library just for setting ansi colors for your TUI. Ideally you have minimal deps scoped to the truly hard things: libghostty, btrfs, luks, postgres, etc. Then you focus on the application and generate the mechanical glue code on demand with a solid harness that keeps the important stuff well-tested. Though you’ll need to figure out how to build that harness/process before it really delivers.

OtherShrezzing 5mo ago

I think in the relatively near future we’re going to start seeing sophisticated supply chain attacks into language model training data. It should be feasible to design vulnerabilities which look benign individually in training data, but when composed together in the agent plane & executed in a chain introduce an exploit. There’s nothing technical really stopping that from existing right now. It’s just that nobody has put the effort in yet.

lacunary 5mo ago
The develop-test-refine feedback loop for this kind of attack is so long (or expensive) that it seems likely to limit its real world use. Poison training data, wait months? a year? for the model to come out, see how well it worked, refine... or do you see a faster way to iterate?
- sieabahlpark 5mo ago
  [dead]
- OtherShrezzing 5mo ago
  Continual learning is the next major architectural milestone for the frontier labs. That’d reduce the iteration loop to days instead of years. If your attacker assumes that all or most software will be generated from language models, the time penalty is worth paying.

contingencies 5mo ago

Love it :) Excellent quippy summary of the zeitgeist. Added to https://github.com/globalcitizen/taoup https://github.com/globalcitizen/taoup

beacon294 5mo ago

Do you have this on a shareable place / forge? I have a farm animal spelling game and want to extend my library and build more ideas.

BigTTYGothGF 5mo ago

Now you're exposed to the real dependency, the browser.

srcreigh 5mo ago
Not to mention Claude

selfmodruntime 5mo ago

Comments like these are so incredible far fetched from reality. Are you really going to implement your own PyTorch? Why even compare your cute examples to enterprise solutions?