Sir Overstreet still seems insistent on having done no wrong on account of fixing user bugs taking priority over literally everything, so clearly there’s a mindset clash that’s gonna prevent a re-merging unless that Torvalds decides to change the same procedure he’s been doing for the past 2 decades or Overstreet knocks his own ego down a peg.
I was wondering, do you think its possible to use something like SAM 3 (segment anything from FB) + Laya to create a super efficient and fast computer use tool?
I don't know anything about homebrew, but have a question ...
I see some parallels between homebrew and Gradle ... for the longest time Gradle was using Groovy for build scripts. The Gradle / Groovy build script DSL was a little too magic and dynamically typed. It looked cute, but led to issues in developer UX (awful stack traces), tooling (documentation and autocomplete), robustness, and performance.
There are other reasons why Gradle is moving away from Groovy. I suspect that the number of people that use and know Groovy is steadily declining. Declarative Gradle, which is the future, is not Turing complete.
I can't help but notice the parallels between Gradle / Groovy and Homebrew / Ruby: using a dynamically typed Ruby DSL with Turing completeness like the olden Gradle ways, and Ruby is declining in popularity like Groovy.
I would have to imagine at some point, the people who know Ruby well enough to create / debug formulae will dwindle. What are the plans?
Ultimately you don’t need to know much Ruby to maintain or contribute to Homebrew. Ruby makes it very easy to write custom DSLs that don’t feel like Ruby. I didn’t really know any before working on Homebrew and it’s now my primary language.
That said, yes we have already moved away from our DSL being Turing Complete. This release drops for official taps the ability for packages to run arbitrary postinstall/uninstall/etc. Ruby in favour of DSLs and our JSON API.
This will likely get extended over time to eventually allow package definitions to themselves be in JSON.
> I suspect that the number of people that use and know Groovy is steadily declining
One big surprise for me at a genomics/bioinformatics company was that of the three main technologies for orchestating bioinformatics workflows, Snakemake, Cromwell, and Nextflow, Nextflow was in a language based on Groovy. It took me back.
Except ~nobody uses declarative gradle in production yet, and groovy is mostly declining in favour of also turing complete Kotlin. It's yet to be discovered how declarative gradle fares and how much of imperative glue real-life projects will need
Google is crushing it! They’re going toe to toe against the European giant Mistral with all these small useful models and they have a chance of winning! Never have I been more excited about Google’s capabilities.
Apple has a dedicated "neural engine" which is designed as an inference NPU. Where as Google's TPU has a dual focus, both inference and training, which is a more complex design.
Unfortunately the codex plans don’t offer the same amount of tokens as they did before. This changed around a week ago. There’s been a lot of user reports noticing this issue, and I’ve noticed the same pattern on my account. Previously I would never reach my weekly quota but last week I managed to finish it it one day. Same project, same single session sequential work. Not sure if there’s an issue or if it’s on purpose, and not even sure it applied to all accounts. Curious if other users on HN noticed the same problem.
Great primitive, I’m a big fan of prolly trees! You mentioned git like filesystem snapshots? How would you retrofit that on an existing filesystem? Or you’re talking about writing a new one?
Thank you for your kind words, yes, I do have lots of ideas on top of prolly, actually I'm building some of them like crab(a serverless git remote, will be open-source soon), compass(a versioned code graph https://compass.crab.build/), trail(a low-level version control tooling for AI agent https://github.com/crabbuild/trail) silo(a versioned S3 client to make S3-compatible bucket version-controllable https://github.com/crabbuild/silo)
I’ve been keeping an eye on hypen.space and hope it succeeds. What is the level of maturity now and are there any multiplatform app examples that are not trivial?
Oh wow, thanks! I never would have thought anyone was keeping an eye on it!
Regarding maturity level - I would yet say it's mature for serious applications with OAuth, local storage etc. Late alpha/early beta stage.
There are some semi-trivial examples on the landing page - most are just UI + input with DB or API fetching in the background, so nothing spectacular.
All of these are crossplatform and render in both web/desktop/mobile and web SDK's or inside the Hypen Gallery apps.
Biggest obstacles to maturity currently are:
- Does not have native platform channels yet
- Renderers need more optimization work
- Ecosystem needs more stability - i.e. test mode and studio still have hiccups
- Error handling and retry story needs improvement
- Some components are still a bit off across desktop/mobile and need syncing
- Resource references derived from state need implementing for better DX
- Protocol isn't binary yet so performance isn't all it could be
But recently things landed that improve maturity quite a lot:
- Accessibility defining & automatic inference has landed, where framework does the best it can to figure it out for you with no intervention
- Animation API has landed with a minimal DX to enable transitions and animations
- Most of tailwind surface is supported and implemented
- Performance improvements being released this week land it in "often 30-50% slower, but sometimes 50% faster than react". Will add benchmarks to docs for visibility.
- CLI improved by a large margin, with expanded template support and easy building
- Cloudflare worker adapter so you can host your app on a worker
reply