Posted by david927 15 hours ago
Ask HN: What are you working on? (June 2026)
I think the main reason is that the West has quite limited access to pro-level teachers (similar to how chess is like in Asia, just the other way round). Most pro-level Go teachers in Asia do not speak/read any foreign languages (e.g. English), so I want to remove the language barrier and make high level of Go teaching more accessible to the Western world (so that the Go population there will increase). Several European users used it and the feedback was good (and recurring purchases). The translation part is working quite well (Go-specific domain translation), and I hope it will help more foreign Go enthusiasts improve their game.
However what happens when you actually build and launch your agent is customers try it, do some initial runs and then go ask your manager to automate their use case. That is why I have been building https://toolscaled.com/ The goal being work through your problem space using agentic chat (like Claude Desktop) and then at the end convert it to a workflow. I am pretty close to launching and have been testing. If you're interested send me an email! (if you do sign up just fyi its still in beta so YMMV.
The concept was, what if Theme Hospital was about Victorian-esq research institution instead of a hospital? You hire strange scientists, have them explore dangerous fields of research, collect messy findings, turn them into theories, prototypes and eventually products, all the while trying to convince investors they're worth funding before they hit the market and work out what they might actually be worth
The gameloop is broken down into two parts, Exploration / Discovery and Exhibition, the closest comparison I have for the first part is take Kerbal Space Program, but focus it on Mission Control rather than the astronauts
While the mad scientists are going into weird, unstable research domains, the player is managing the institution around them, funding, equipment, research direction, safety
On the other side as you discover interesting things or successfully develop prototypes worth showing off, have investors show up and see what excites them, will they give you more funding? Push a grant your way? How are you going to keep this circus going?
You're balancing two plates, you need to invent tools to delve deeper and if you don't keep finding exciting new discoveries, your investors will slowly get bored of you
So I've been working on https://fringeflypost.com/, an event tracker with maps, search and filter, scheduling, and sharing with friends that's offline first. It syncs down a locally stored sqlite database and caches assets pretty aggressively.
(You don't actually need to sign up, and you can just jump into the list of shows directly here https://fringeflypost.com/shows).
Repo is here if anyone wants to have a look: https://github.com/deosjr/unreal-talk
And a browser-based version can be found here: https://deosjr.github.io/dynamicland/live
I discovered this week, while the paper was being reviewed by SG1, that I've accidentally stumbled into tackling a rather important problem. Senders as shipped in C++26 can really only express the async equivalent of inline functions because, except for `task`, all the standard senders fully encode the shape of their computation in their type. With something like the `function` I'm proposing, you can use senders to express async algorithms that are separately compiled, just like sync functions.
If the feature lands in a shape similar to what I've proposed in P4223R0, then I think an obvious extension is to modify the core language to support a newer kind of "coroutine" that allows you to define a sender with imperative code. My vision here is that we act on the observation that `std::execution` is a language feature implemented in the library by teaching the compiler how to turn imperative C++ with `co_await`s sprinkled through it into the corresponding sender and operation state. I think this would open the door to putting async object lifetime analysis and optimization where it belongs (in the compiler) without the overheads and inconveniences of C++20 coroutines. It would even let us apply the inliner to async functions when the compiler can see the body of an async callee, not just its declaration.
For now, my next step is to write P4223R1 to incorporate feedback from this past week's WG21 meeting, and continue exploring the design space around specifying sender attributes for a `function`—I'm thinking the current approach of specifying query function signatures needs to be replaced with a key-value object like receiver environments, but I'm not sure yet what consequences that change would have on the design.