mccoyb

I see -- so this is the "paid" AI studio plan?

Does that have any relation to the Gemini plan thing: https://one.google.com/explore-plan/gemini-advanced?utm_sour...

?

I truly do not understand what plan to use so I can use this model for longer than ~2 minutes.

Using Anthropic or OpenAI's models are incredibly straightforward -- pay us per month, here's the button you press, great.

Where do I go for this for these Google models?

> Bajillions of dollars invested in the development of some of the most powerful computational artifacts to date.

> Fork VS Code, add a few workflow / management ideas on top.

> "Agentic development platform"

I'm Jack's depressed lack of surprise.

Please someone, make me feel something with software again.

I used Julia for 4 years. I'm not a moron: I'm familiar with how it works, I've written several packages in it, including some speculative compiler ones.

You claimed:

> Allowing invokation of the compiler at runtime is definitely not something that is done for performance, but for dynamism, to allow some code to run that could not otherwise be run.

I asked:

> why not just compile a static but generic version of the method with branches based on the tags of values? ("Can't figure out the types, wait until runtime and then just branch to the specialized method instances which I do know the types for")

Which can be done completely ahead of time, before runtime, and doesn't rely on re-invoking the compiler, thereby making this whole "ahead of time compilation only works for a subset of Julia code" problem disappear.

Do you understand now?

My original comment:

> The problem (which the author didn't focus on, but which I believe to be the case) that Julia willingly hoisted on itself in the pursuit of maximum performance is _invoking the compiler at runtime_ to specialize methods when type information is finally known.

is NOT a claim about the overall architecture of Julia -- it's a point about this specific problem (Julia's static ahead-of-time compilation) which is currently highly limited.

I don't believe it, otherwise why not just compile a static but generic version of the method with branches based on the tags of values? ("Can't figure out the types, wait until runtime and then just branch to the specialized method instances which I do know the types for")

Perhaps there is something about subtyping which makes this answer ... not correct -- and if someone knows the real answer, I'd love to understand it.

I believe that this answer is because of performance -- if I can JIT at runtime, that's great -- I get dynamism and performance ... at the cost of a small blip at runtime.

And yes, "performant Julia code" -- that's the static subset of the language that I roughly equated to be the subset which is trying to be pried free from the dynamic "invoking the compiler again" part.

Why not just disallow PRs from non-vetted contributors?

Why not just disallow issues without a vetting process?

Many of these things could be explored -- you're right: it's a spam issue. But we have solutions to spam issues ... filters. LLMs have shown that "praying for the best" with permissive repository settings is not sufficient. We can and will improve our filters, no?

> Julia's "secret sauce", the dynamic type system and method dispatch that endows it with its powers of composability, will never be a feature of languages such as Fortran. The tradeoff is a more complex compilation process and the necessity to have part of the Julia runtime available during execution.

> The main limitation is the prohibition of dynamic dispatch. This is a key feature of Julia, where methods can be selected at run time based on the types of function arguments encountered. The consequence is that most public packages don't work, as they may contain at least some instances of dynamic dispatch in contexts that are not performance-critical. Some of these packages can and will be rewritten so that they can be used in standalone binaries, but, in others, the dynamic dispatch is a necessary or desirable feature, so they will never be suitable for static compilation.

The problem (which the author didn't focus on, but which I believe to be the case) that Julia willingly hoisted on itself in the pursuit of maximum performance is _invoking the compiler at runtime_ to specialize methods when type information is finally known.

Method dispatch can be done statically. For instance, what if I don't know what method to call via abstract interpretation? Well, use a bunch of branches. Okay, you say, but that's garbage for performance ... well, raise a compiler error or warning like JET.jl so someone knows that it is garbage for performance.

Now, my read on this work is the noble goal of prying a different, more static version of Julia free from this compiler design decision.

But I think at the heart of this is an infrastructural problem ... does one really need to invoke the compiler at runtime? What space of programs is that serving that cannot be served statically, or with a bit of upfront user refactoring?

Open to be shown wrong, but I believe this is the key compiler issue.

Sounds like a lot of FUD to me — if major projects balk at the emergence of new classes of tools, perhaps the management strategy wasn’t resilient in the first place?

Further: sitting down to discuss how your project will adapt to change is never a waste of time, I’m surprised you stated it like that.

In such a setting, you’re working within a trusted party — and for a major project, that likely means extremely competent maintainers and contributors.

I don’t think these people will have any difficulty adapting to the usage of these tools …

I don’t think open source is going anywhere. It’s posed to get significantly stronger — as the devs which care about it learn how to leverage AI tools to make things that corporate greasemonkeys never had the inspiration to. Low quality code spammers are just marketing themselves for jobs where they can be themselves: soulless and devoid of creative impulse.

That’s the thing: open source is the only place where the true value (or lack of value) of these tools can be established — the only place where one can test mettle against metal in a completely unconstrained way.

Did you ever want to build a compiler (or an equally complex artifact) but got stuck on various details? Try now. It’s going to stand up something half-baked, and as you refine it, you will learn those details — but you’ll also learn that you can productively use AI to reach past the limits of your knowledge, to make what’s beyond a little more palatable.

All the things people say about AI is true to some degree: my take is that some people are rolling the slots to win a CRUD app, and others are trying to use it to do things that they could only imagine before —- and open source tends to be the home of the latter group.

Are you `robject` on Stack Overflow -- or perhaps you might explain why you copied verbatim their response to https://stackoverflow.com/questions/3561145/what-is-a-smallt... without citing your source?

Sonnet 4.5 is way worse than Opus 4.1 -- it's incredible that they claim it's their best coding model.

It's obvious if you've used the two models for any sort of complicated work.

Codex with GPT-5 codex (high thinking) is better than both by a long shot, but takes longer to work. I've fully switched to Codex, and I used Claude Code for the past ~4 months as a daily driver for various things.

I only reach for Sonnet now if Codex gets cagey about writing code -- then I let Sonnet rush ahead, and have Codex align the code with my overall plan.

I'm working on such a thing, but I'm not interested in money, nor do I have money to offer - I'm interested in a system which I'm proud of.

What are your motivations?

Interested in your work: from your public GitHub repos, I'm perhaps most interested in `moor` -- as it shares many design inclinations that I've leaned towards in thinking about this problem.

To clarify my comment: I agree that multiple dispatch is a very good language feature. I enjoy it, and I’m well-versed in the expression problem, yada yada.

That’s not what I meant by “method JIT architecture” — I meant calling back into the compiler at runtime to specialize code when the types are known.

These are exactly the feelings that I left with from the community in ~2021 (along with the AD story, which never really materialized _within_ Julia - Enzyme had to come from outside Julia to “save it” - or materialized in a way (Zygote) whose compilation times were absolutely unacceptable compared to competitors like JAX)

More and more over time, I’ve begun to think that the method JIT architecture is a mistake, that subtyping is a mistake.

Subtyping makes abundant sense when paired with multiple dispatch — so perhaps my qualms are not precise there … but it also seems like several designs for static interfaces have sort of bounced off the type system. Not sure, and can’t defend my claims very well.

Julia has much right, but a few things feel wrong in ways that spiral up to the limitations in features like this one.

Anyways, excited to check back next year to see myself proven wrong.

Economically rational, but bereft of identity or _soul_ -- which, paradoxically, becomes highly valued when economically rational agents all regress to a mean of mediocrity.

It comes off as someone who lives their life according to quantity, not quality.

The real insight: have some fucking pride in what you make, be it a blog post, or a piece of software.

I think this is a strictly worse name than "agentic harness", which is already a term used by open-source agentic IDEs (https://github.com/search?q=repo%3Aopenai%2Fcodex%20harness&... or https://github.com/openai/codex/discussions/1174)

Any reason why you want to rename it?

Edit: to say more about my opinions, "agentic loop" could mean a few things -- it could mean the thing you say, or it could mean calling multiple individual agents in a loop ... whereas "agentic harness" evokes a sort of interface between the LLM and the digital outside world which mediates how the LLM embodies itself in that world. That latter thing is exactly what you're describing, as far as I can tell.

Congratulations: it's faster, but worse, with a larger context window.

Anecdotally: I tried hook and crook to get the best flagship model at the time (Opus) to help with technical writing for a submission.

First, these models are not good at technical writing at all. They have no sense of the weight of a single sentence, they just love to blather.

Second, they can't keep the core technical story consistent throughout their completions. In other words, they can't "keep the main thing the main thing".

I had an early draft with AI writing, but by the time we submitted our work -- there was not a single piece of AI writing in the paper. And not without trying, I really did some iterations on trying to carefully craft context, give them a sense of the world model in which they needed to evaluate their additions, yada yada.

For clear and concise technical communication, it's a waste of time right now.

Is that not exactly plan mode?

Have you used these tools at all? It's incredibly obvious. It was obvious for weeks during August, where several people posted about degradation on r/ClaudeAI ...

There's a thousand and one reasons why a company valued in the billions, with the eyes of the world watching, would not be completely honest in their public response.

Many of the "look at what I did programming LLMs" blog posts on Hacker News have been developed and put out in academic papers and groups. The posts which gain traction here seem to be perennially behind the state of the art.

Excellent response, completely agree.

Share, if you please.

That I could, except it hangs in the current version of Claude Code when switching from false to true ...

I read this as changes to quantization and batching techniques. The latter shouldn’t affect logits, the former definitely will …

Here’s a report: Claude Code (the software) is getting worse by the day.

Removing the shown token comsumption rates (which allowed understanding when tokens were actually being sent / received!) … sometimes hiding the compaction percentage … the incredible lag on ESC interruption on long running sessions, the now broken clearing of the context window content on TASK tool usage

Who the fuck is working on this software and do they actually use it themselves?

Maybe the quality of Claude Code on any given day is indicative of whether their models are degraded …

Does Clojure solve this to a satisfying degree? One gives up static typing to embrace Clojure’s solutions.

On the other hand, Rust / Haskell provide partial solutions with static typing — but run into annoying boilerplate related to the orphan rule.

I’m not sure if there’s a true solution, given the level of thinking which has gone into these two forks in the road.

My optimism says the good new stuff is coming slowly because people who care about their craft and taking things slowly aren’t in any rush to get to market.

Share some references, friendo. Claims require evidence.