This is interesting but I wonder if you would accept that this also has the downside of moving at the speed of humans.
In a situation where you're building, I find the orphan rule frustrating because you can be stuck in a situation where you are unable to help yourself without forking half of the crates in the ecosystem.
Looking for improvements upstream, even with the absolute best solutions for option 1, has the fundamental downside that you can't unstick yourself.
This is also where I find it surprising that this article doesn't mention Scala at all. There are MANY UX/DX challenges with the implicit and witness system in Scala, so I would never guess suggest it directly, but never have I felt more enabled to solve my own problems in a language (and yes the absolute most complex, Haskell-in-Scala libraries can absolutely an impediment to this).
With AI this pace difference is even more noticeable.
I do think that the way that Scala approaches this by using imports historically was quite interesting. Using a use statement to bring a trait definition into scope isn't discussed in any of these proposals I think?
The problem is existentials, or rather the existence of existentials without the ability to explicitly override them. Even in Haskell, overriding typeclass instances requires turning off orphan checks, which is a rather large hammer.
So once you've identified this, now you might consider the universe of possible solutions to the problem. One of those solutions might be removing existentials from your language; think about how Scala would work if implicits were removed (I haven't used Scala 3, maybe this happened?). Another solution might be to decouple the whole concept of "existential implementations of typed extension points" from libraries (or crates, or however you compile and distribute code), and require bringing instances into scope via imports or similar.
Two things are true for sure, though: libraries already depend on the current behavior, whether that makes sense or not; and forcing users to understand coherence (which instance is used by which code) is almost always a giant impediment to getting users to like your language. Hence, "orphan rules", and why everyone hates Scala 2 implicits.
That said, I would love to see a solution in my favorite class of solution: where library authors can use and benefit from this, but the average user doesn't have to notice.
I tend to think that the non-existential Scala system was _so close_, and that if you _slightly_ tweaked the scoping rules around it, you could have something great.
For example, if - as a user - I could use `.serialize(...)` from some library and it used _their_ scoped traits by default, but if I _explicitly_ (named) imported some trait(s) on my side, I could substitute my own, that'd work great.
You'd likely want to pair it with some way of e.g. allowing a per-crate prelude of explicit imports that you can ::* import within the crate to override many things at once, but... I think that with the right tweaks, you could say 'this library uses serde by default, but I can provide my own Serializer trait instead... and perhaps, if I turn off the serde Cargo feature, even their default scoped trait disappears'.
That was my first thought! I never had this problem with Scala (2.x for me, but I guess there's similar syntax/concepts in 3).
The article author does talk about naming trait impls and how to use them at call sites, but never seems to consider the idea that you could import a trait impl and use it everywhere within that scope, without extra onerous syntax.
Does this still solve the "HashMap" problem though? I guess it depends on when the named impl "binds". E.g. the named Hash impl would have to bind to the HashMap itself at creation, not at calls to `insert()` or `get()`. Which... seems like a reasonable thing?
Unfortunately, we're all stuck moving at the speed of the model labs because of the subscription models that they've provided.
The rest of us were able to implement things like push a long time ago, but because Claude Code and Codex stubbed those things out, we couldn't really use them for 'most agent users'.
In fairness to OpenAI, they have been generous in allowing for example OpenCode to sign in with your ChatGPT subscription – so you _could_ build a more powerful agent (which OpenCode is... not) – but unfortunately GPTs' instruction following just isn't up to snuff yet. Hopefully they pre-train something amazing this year!
Great interaction. Very refreshing after some of the past problems I've encountered with maintainers treating forks as hostile or "stealing our work".
The message also exposes a reality of how hard it can be to upstream internal changes: They admit they don't have the time to go back and re-submit all of their work as tiny incremental patches that could be reviewed and approved upstream. They estimate it would be on the order of 100 PRs necessary to break it up and get it reviewed. That's a very large time investment for a company that needs to keep moving forward.
Hopefully they stay close in the rest of the implementation details of the project they forked from. After a fork becomes battle-tested enough it might be reasonable to start merging things in larger chunks rather than treating them as incremental development again.
disclosure: I work on the team behind noq. Can't emphasize enough that the quinn maintainers are really lovely people, and quinn is an excellent project.
I think that the point about building with agents though. Your ideas meet reality sooner and you actually get feedback on whether they are worth anything or not. So you're not really being an ideas guy in the sense of just throwing ideas out there. You're being an ideas guy in the sense of testing your ideas, which is really the essence of what building startups is: figuring out what people want.
That's true. I was just responding to the post above, which seemed to be inferring a different meaning (i.e. that there are no bad or good ideas guys) than how I interpreted it.
> Be Proactive: The user is highly technical (a VFX professional/coder). Skip basic tutorials and dive straight into advanced implementation, but be sure to document math thoroughly.
Back when I played with animation and post pipelines, I was writing a decent amount of python. It's part of how I got into programming. At the time I would have said I can't program, and I suspect this guy is similar.
This is fun! I switched to https://github.com/manaflow-ai/cmux for a while, but had to switch back to Ghostty due to its unreliability, high memory and CPU usage and a bunch of bugs.
This makes a lot of sense, but... it'd be great to allow pulling out of a canvas into a second canvas for those of us with multiple screens (you at least end up needing one window per screen).
In general it feels like... more structure rather than less feels like it'd be the smoothest experience. I'll play with your Ctrl+K shortcut and see if it ends up feeling like I can get everywhere that I need quickly.
But... nice work!
Note for jj users like me: you need to `git lfs pull` if you want to `cargo run --release`!
Update: No luck creating any 'shell' workspaces (it looks like you use GNU-only flags to script) – I'll push a fix once I find it.
Also: the AGENTS.md is wrong JFYI - it points to portable-pty, when this is using alacritty_terminal's tty (on rustix-openpty)
This is the only reason I stick to Terminator, but none of the othet terminal emulators are coming close. I wouldn‘t even be searching for an alternative if Terminator wouldn‘t crash every other week.
It kinda... does? The problem is that folks have been flailing on the right UX for this.
This is what build vs. plan mode _does_ in OpenCode. OpenAI has taken a different approach in Codex, where Plan mode can perform any actions (it just has an extra plan tool), but in OC in plan mode, IIRC write operations are turned off.
The screenshot shows that the experience had just flipped from Plan to Build mode, which is why the system reminder nudged it into acting!
Now... I forget, but OC may well be flipping automatically when you accept a plan, or letting the model flip it or any other kind of absurdity, but... folks are definitely trying to do the approval split in-harness, they're just failing badly at the UX so far.
And I fully believe that Plan vs. Build is a roundly mediocre UX for this.
The switch from plan mode to build is not always clearly defined. On a number of occasions, I've been in plan mode and enter a secondary follow up prompt to modify the plan. However, instead of updating the plan, the follow up text is taken as approval to build and it automatically switches to building.
Ask mode, on the other hand, has always explicitly indicated that I need to switch out of ask mode to perform any actions.
But often I am using Claude to investigate a problem like this “why won’t this mDNS sender work” and it needs a bunch of trial and error steps to find the problem and each subsequent step is a brand new unanticipated command.
The OpenCode plan experience has been pretty bad (the community has accepted this, at least on Discord). The community's adopted a handful of plugins to make the experience better, and also guardrail when the agent switches versus doesn't
In a situation where you're building, I find the orphan rule frustrating because you can be stuck in a situation where you are unable to help yourself without forking half of the crates in the ecosystem.
Looking for improvements upstream, even with the absolute best solutions for option 1, has the fundamental downside that you can't unstick yourself.
reply