[flagged]
Ask HN: What are you working on? (June 2026)
261–270 of 1001 posts
Re: Ask HN: What are you working on? (June 2026)
#262I've been working on my vision for a better web app development ecosystem. https://wildloop.dev/
It currently exists of 12 libraries/tool, most of which are pretty stable by now, though some are still very much in flux.
This is one of those things that turns out to be kind of a lot of work. :-)
Re: Ask HN: What are you working on? (June 2026)
#263I’m working on a tensor computing language/compiler called i with a simple explicit scheduling model (loop splitting, loop ordering, input “staging”). These mechanisms alone are enough to express complex algorithms like FlashAttention, generating target code with techniques like loop fusion, minimized intermediate allocations, and “online” reductions.
Right now there is a runtime and compiler targeting C, written in dependency-free Rust, and a minimal Python frontend. The project is very much proof-of-concept stage so not yet fast. Working on a CUDA backend now.
The goal is to enable automatic discovery of FlashAttention-style optimizations which is not feasible with current compilers.
Very open to feedback/discussion from anybody interested in or knowledgeable about tensor compilers!
Re: Ask HN: What are you working on? (June 2026)
#264safe/efficient junctions on the road network where I live:
Re: Ask HN: What are you working on? (June 2026)
#265Worked on awardlocker.com for a while, an award flight search engine. I ended up buying a bunch of business flights with points so my interested died down a bit, but quite useful!
Re: Ask HN: What are you working on? (June 2026)
#266I’m working on a coding agent that doesn’t have access to the shell. Essentially all it could do is edit and read code, verify and run tests. But due to that limitation I’ve made it target only rust projects for the time being.
Re: Ask HN: What are you working on? (June 2026)
#267Still plugging away on SourceMinder (https://github.com/ebcode/SourceMinder). I know, I know, everyone and their brother is working on token-saving schemes for LLMs. But I’ve found it to be useful even without the LLM. I’m working on a proper website for it now where you can try it out in the browser (wasm port) — try before you don’t buy (it’s GPL). Feedback welcome.
Re: Ask HN: What are you working on? (June 2026)
#268Working with a variety of AI models (Claude, Grok Build, various locally run models) and agents, I am scratching an itch.
When people deploy python and perl code, they have to either export their entire environment, or build a container. The latter is not possible in a number of deployment cases, and the former carries all manner of dependency radius gotchas.
So I am building (ok, I am prompting/testing/reviewing, the agent is doing the heavy lift) compilers for each of python 3.14.x [1] right now, and perl 5.42.x [2], that can generate static code.
Early stages, perlc does work well, pyc is a work in progress.
Re: Ask HN: What are you working on? (June 2026)
#269[dead]
Re: Ask HN: What are you working on? (June 2026)
#270I am making Cargo for C. I have 3/4 of a working demo; the tool can build itself, including some non-trivial dependencies which I've ported to build natively with the tool (instead of wrapping their Make or CMake or whatever).
The pitch: It's insane that we have to pull in Python or Lua to build C code. CMake is an abomination against god that has become usable in spite of itself. Zig cc is proof that this entire ecosystem is an embarrassment. My tool gives C projects a TOML manifest, and builds scripts written in C and JIT compiled by the tool. Now, you can write build scripts in the language itself, pull in dependencies you wanted to use anyway.
It also provides a stable ABI. There's an HTTP-backed index and a Git-backed index. And it generally does the same thing for C that, say, Bun did for JS/TS. You'll be able to run C files from source and have the entire ecosystem available. You'll be able to trivially generate single file static binaries, or dynamically link to an older glibc without arcane tricks. It will fix C.
I'm also still working on my "what if we wrote a real standard library for C"; I added some feedback I got from the release.