The biggest jump was Opus 4.6. Since then they have gradually gotten better at finding issues in your reasoning, not hallucinating, and being rigorous with the code, but much much worse at explaining things and generally just talking in a way that a human can understand. All the models I've tried seem to be suffering from the same fate so it must be something going on with the training meta right now.
Disclaimer: I have not looked carefully at the permissioned data proposal, but I know atproto reasonably well.
Stepping back for a momement, it's clear that permissioned data is driven by real world use-cases (Bluesky needs DMs, Tangled needs private repos, etc). However, I think the synergies with the existing atproto needs to be pretty significant to warrant developing yet another encrypted space spec. We already have various double ratchet protocols, Matrix is having a huge boom. From the point of view of an app developer, does everything need to be handled by atproto, or could we accept that atproto is just for the public stuff?
I would prefer this to be more geared towards things like Private social profiles or shared with specific circles than DMs, which are already served by E2EE.
There's no issue in using ATProto to "link" an external service, like Tangled does with it's "knots" which host the git data.
All of the social stuff (issues, PRs, comments and so on) is on ATProto, and on ATProto you also have a "repository" object, linking to a "knot" object containing the address of the knot.
What's stopping an E2EE DM implementation to use ATProto to point to something like an "accepted matrix server" for all parties, and each having a "matrix identity" ATProto record ? (I don't know about Matrix so idk if this is exactly possible but you get the idea)
"If you mix raisins with turds, they're still turds" - Charlie Munger
Another consequence of US NatSec being gradually privatized is that once your income stream derives mostly from government spending, it becomes an imperative to influence politics to secure that stream. Yet some of these companies will remain vulnerable to shifting political winds.
> It never made sense to me how such a ruthless and inhumane culture is sustainable in the long run.
It’s pretty simple, actually. Once such a dominant market position is achieved, you can get away with almost anything, whether with customers or employees. This is true of all the BigTech companies.
I think there's more to it. When you're dominant, you make money whatever. Think of Amazon et al. as huge spigots of money. Now, it becomes optimal to fight for more of that money coming your way. It's like the resource curse for countries. Nobody gains from growing the pie; they gain from stealing the pie. At some point, parasites and parasitic behaviours invade.
Really? Premature stabilization is a much more recognisable problem. This is after all quietly why there's so much Rust adoption. Safety is nice, but perf is $$$.
C++ had this unhealthy commitment to stabilization and it meant that their "Don't pay for what you don't use" doctrine has always had so many asterisks it's practically Zalgo text or like you're reading an advert for prescription medicine. You're paying for that stabilization, everywhere, all the time, and too bad if you didn't need it.
Unwinding stabilizations you regret is a lot more work even in Rust, consider the Range types, landing improved Range types is considerable work and then they'll need an Edition to change which types you get for the syntax sugar like 1..=10
Or an example which happened a long time ago, the associated constants. There are whole stdlib sub-packages in Rust which exist either primarily or entirely as a place for constants of a type, std::f32::MAX is just f32::MAX but the associated constant f32::MAX only finally stabilized in 1.43 so older code uses std::f32::MAX nevertheless if you learned to write std::f32::MAX you may only finally get deprecation messages years from now and they're stuck with keeping the alias forever of course because it's stable.
This is probably my favorite programming language I would like to use if it had more backing. Their reference capabilities in particular seem like a very good match for the actor model. Alas, it does not appear to have a large corporation behind it pushing it forward, nor a compelling niche use case (e.g. it is still GC'd).
The guy behind the language - Sylvan Clebsch - seems to have a very solid background, and current professional situation. He works at "Microsoft Research Cambridge" in the Programming Language Principles group.
My point is - sure, it doesn't have a handful of massive companies stewarding it like Rust. But, on the other hand, it's made by a guy with really serious chops, who has a solid programming language related job. So while not being as industry-sanctified as Rust, or Java, it seems nonetheless like a language that could go places!
This is alas the chicken and egg scenario and the most common reason I hear for people not wanting to invest the time in pony.
The vast majority of people I discuss it with understand the value and the problems it is designed to solve, but they either don't have domain-problems that require pony's approach more than any other language - or the lack of supporting libraries makes them nervous over adoption.
As a pony developer for 5+ years, it can be frustrating - but I do understand.
I'm not sure I understand what you mean by "real-time safe GC algorithms", but pony is not a language that has being a "real time system" as a design goal.
This pony paper here describes the pony GC algorithms and compares their performance under various scenarios to other language GCs.
Real-time safe GC algorithms and data structures provide strong guarantees that any interruptions to the running program caused by GC activity will have a bounded duration, with strong guarantees on the upper bound of any pause. This is important in latency sensitive software and real-time software that needs to meet deadlines.
Thanks for the ORCA link. I'll have to study it more closely but from Fig 17 it looks to have quite unpredictable jitter up to at least 20ms. Which is obviously fine for many things but not useful for other things (e.g. processing AVB streaming audio packets at line rate every 125 us).
Yes, drastically. This means I'll have to wear Zuck's glasses I think, because the AI currently doesn't know what was discussed at the coffee machine or what management is planning to do with new features. It's like a speed typing goblin living in an isolated basement, always out of the loop.
reply