Initial thoughts are it's a meh protocol that does not look well thought-out, has fewer features than SSH, to the point I'm not sure it deserves to be called SSH3 and not telnet-over-websockets. Also, there's already an SSH3 https://marc.info/?l=openssh-unix-dev&m=99840513407690&w=2 so I _really_ think the thing you're thinking of is just some namesquatter assuming it has any connection to openssh or ssh.
I also know how to use SRV records so this is a non-issue for me and everyone I work with.
> Each agent is a TOML config with a focused job. Such as code reviewer, log analyzer, commit message writer. You can run them from the CLI, pipe data in, get results out.
I'm a bit skeptical of this approach, at least for building general purpose coding agents. If the agents were humans, it would be absolutely insane to assign such fine-grained responsibilities to multiple people and ask them to collaborate.
It is easier to trust in the correctness and reliability of an LLM when you treat it as a glorified NLP function with a very narrow scope and limited responsibilities. That is to say, LLMs rarely mess up specific low level instructions, compared to open-ended, long-horizon tasks.
This is the second time I've seen somebody use the word "clankers" in the last couple days to refer to AI. Is that a thing now? Where'd that come from?
Gonna be honest, it has taken away from the message both times I've seen it. It feels a bit like you're LARPing your favorite humans vs robots tv show.
We have been rewatching Clone Wars as a family, and I, for one, find this terminology hilarious given the use of it in the series towards the separatist droids.
There was a post last week about the best programming language for LLMs, and in the comments people loved Go, with the claim being it's very opinionated and there's really only one way of doing things. I'd say the same is mostly true for Rails apps as well.
However having worked with Typescript for 8 years now... I'm not sure I could go back to Ruby without types. For LLMs thats important as well, the more guard rails you can give them the better. What's the state of type checkers today?
> However having worked with Typescript for 8 years now... I'm not sure I could go back to Ruby without types.
Very true for me as well. I've never worked with Ruby but feel the same way about Django.
Btw, if you're looking for a "Rails but with TypeScript," my colleagues and I are working on almost just that: https://wasp.sh/.
The main difference, besides the ecosystem, is that we're more in the "configuration over convention" camp. Wasp has a simple DSL for specifying said configuration, but it's about to be replaced with a TypeScript file.
Wasp is still in beta and nowhere near Rails-level polish. But, depending on your early adopter tendencies, you might find it interesting regardless. If you do try it out, please reach out and share your thoughts.
TS is very AI native to the point i'd agree it's near magical in terms of contract.
However, the fact its still the js ecosystem with react, thing is even though it's super productive in churning out the code, there's too many possible ways to do something. it's unwieldy.
For example Claude is obsessed with making react context providers. it'll make tons of them to power every feature. and your app will happily hold 20 layers of russian doll'd state in memory with no way to link to anything.
you have to tell it, no don't do that. i need you to power this thing through the router, through the url. and that has to be designed cohesively. and that's very different from the context free-for-all.
> TS is very AI-native, to the point I'd agree it's near magical in terms of contracts.
I agree.
Not only that, I feel like TypeScript is currently the only popular high-level language with a type system capable of communicating all meaningful information. It seems to have hit an LLM sweet spot.
Looking at other candidates:
- Rust is popular and has a powerful type system, but it forces you to program at a level that's lower than necessary for most projects, hindering usability.
- Go is much more usable and very popular, but its type system can't communicate much.
- Haskell has an excellent type system, but it's nowhere near popular enough, and its usability suffers due to esoteric constraints (laziness, purity).
- etc.
I don't know the recent developments in Python's and Ruby's type systems. They may be able to compete these days, but they were nowhere near TS's level in terms of contract a few years ago when I last tried them out.
And I admittedly have no idea what's going on with C# and Java, but I'd love to hear about it.
Ruby has types with RBS and Steep now. It's a lot like using .d.ts sidecar files alongside JavaScript, via jsconfig.json configuring tsc. I like it a lot!
>The claim seems quite clear to me: "convention over configuration allows coding agents to be more effective".
The agents pick up conventions from the extensive code in their corpus and aggressively follow them. I don't think Rails being explicit about it adds a lot unless someone is prone to prompting towards absurdity.
doesn’t forcing your agent to think in ruby put it at huge disadvantage though? since the language isn’t that popular it can’t have learned it as well as say python or Java?
Python does have a bigger pool of examples, but agents usually get tripped up by missing context about specific frameworks more than by language syntax. The real obstacle for LLMs is understanding Rails' implicit conventions and magic, not the Ruby language itself.
> Cloud challenges can be as or more complex than bare metal ones.
Big +1 to this. For what I thought was a modest sized project it feels like an np-hard problem coordinating with gcloud account reps to figure out what regions have both enough hyperdisk capacity and compute capacity. A far cry from being able to just "download more ram" with ease.
The cloud ain't magic folks, it's just someone else's servers.
(All that said... still way easier than if I needed to procure our own hardware and colocate it. The project is complete. Just delayed more than I expected.)
> The cloud ain't magic folks, it's just someone else's servers.
The cloud is where the entire responsibility for those servers lives elsewhere.
If you're going to run a VM, sure. But when you're running a managed db with some managed compute, the cost for that might be high in comparison. But you just offloaded the whole infra management responsibility. That's their value add
But any serious deployment of "cloud" infrastructure still needs management, you're just forcing the people doing it to use the small number of knobs the cloud provider makes available rather than giving them full access to the software itself.
not sure what you mean by a serious deployment, but a lot of companies will be perfectly fine with, some compute, object storage and a managed rdbms.
Will that be more expensive than running it yourself? Absolutely. Does it allow teams to function and deliver independently, yes. As an org, you can prioritize cost or something else.
I don't in ow if I'd say it's "easy". The Python ecosystem in particular is quite hard to get working in a hermetic way (Nix or otherwise). Multiple attempts at getting Python easy to package with Nix have come and gone over the years.
tl;dr it will put one package per layer as much as possible, and compress everything else into the final layer. It uses the dependency graph to implement a reasonable heuristic for what is fine grained and what get combined.
That layering algorithm is also configurable, though I couldn’t really understand how to configure it and just wrote my own post processing to optimize layering for my internal use case. I believe I can open source this w/o much work.
The layer layout is just a json file so it can be post processed w/o issue before passing to the nix docker builders
> If there was really true 'progress', then you wouldn't need a one-party system that suppresses all dissent.
This makes no sense. It is possible for a totalitarian government which is threatened by dissent and concepts like "democracy" to also work in the interest of improving overall quality of life.
Sure. There's always going to be someone opposing something. But I'm not aware of cases where a disagreement in an environment good for everyone was large enough that it caused the leadership/government collapse. Similarly on a small scale, the number of grumpy people at companies I worked at scaled more or less with how good things were for everyone.
In other words, if things are good enough, there will be more people disagreeing with the totalitarian part than with the overall conditions.
Foreign state-actors love to sow discontent in enemy territories. It doesn't matter what they say to rile up the population and cause instability -- they'll just do it.
NixOS "suffers" from this. It's really not that bad if you have solid bandwidth. For me it's more than worth the trade off. With a solid connection a major upgrade is still just a couple minutes.
I think you misunderstand my point. Nix basically forces dynamic linking to be more like static linking. So changing a low level library causes ~everything to redownload.
> Yes, and my point is that thinking the cost of subscriptions is only inference, and not the research, is mistaken.
Of course they are losing money when you factor in R&D. Everybody knows that. That is not what people mean when they say that they "lose money" on subscriptions.
[0]: https://www.ietf.org/archive/id/draft-michel-ssh3-00.html
reply