Hacker Newsnew | past | comments | ask | show | jobs | submit | m12k's commentslogin

The typescript team themselves rewrote the compiler in Go to get better use of coding agents.

They started that migration years ago. I don't remember them citing agentic coding as a reason. Do you have a source?

Not sure about the compiler but prominent users of llm agents (Mitchel Hashimoto, Armin Ronacher etc) has mentioned that Go gives better results for agentic coding.

They did it for speed, and Go was the language with the closest syntax to migrate to.

Headquartered in Stockholm, so "bear-yet" should get you fairly close.

So we've basically taken the concept of branch prediction from CPUs and applied it to LLMs?


The concept of predicting future elements in a series is not specific to CS. It's older than computers.


Speculative execution techniques in software & hardware exist everywhere,

- Speculative multi threading

- Data Value Speculation

- Speculative Memory Disambiguation

- Runahead Execution

- Speculative Prefetching

- Multi-path (Dual-path) Execution (goes beyond branch prediction by computing both paths)

- Optimistic Concurrency Control (for database transactions etc)


Maybe at very high level of abstraction, but there's no branching involved.


Well, there are multiple token proposals processed in parallel, from which only one is picked, seems like branching to me. The only difference is that in case of CPU there is always only one possible branch that is correct.


Well, not exactly, but that was the dream we were sold (here be dragons)


Well, the TPUs they're running on don't have branch prediction, so that had to end up somewhere in the stack.



I feel like this article leaves out the latest research pointing to acetaminophen having a negative effect on fertility, hindering embrionic development and potentially also also follicular development in baby girls. It's a trade-off for sure, but if you're trying to have a baby, you may want to swing back to ibuprofen.

[1] https://pubmed.ncbi.nlm.nih.gov/40819833/

[2] https://ddeacademy.dk/ddea/what-new-research-reveals-about-p...


Not my comment but my guess is they might be referring to the research that shows that intermittent fasting has various health benefits. And one of the most popular ways to do intermittent fasting is 16:8 (16 hours where you fast, 8 hours where you eat), typically where you only ever eat from 12 noon until 8 in the evening, and then fast from 8 pm until noon the next day. Under those conditions, breaking the fast with a breakfast means losing out on the health benefits, and you're better off waiting until lunch.


But there's other research that, at least when it comes to weight loss, there is no measurable difference between intermittent fasting and reduced calorie intake.


I think the main point of intermittent fasting is to help with diabetes prevention


Of all the Internet hype around it, including many threads here, not once I saw anyone actually spelling this out.


brunch is the most important meal of the day, I guess.


But what about second breakfast?


Remember, having the dot com bubble burst did not prevent the internet from being integrated more and more in society over the next couple decades. What it did was stop the headless investment where money was thrown at anything that tangentially could be called "online". We went from "nobody knows what this is, but everyone wants a piece of it" to "we know what it is, and we sure did pursue a lot of bad ideas when we didn't". Expect something similar to happen with AI - having the bubble burst will not stop it in its tracks, but it will change what gets invested in.


I used to think the future of version control was semantic: E.g. I renamed a method, while someone else concurrently added another call to that (now differently named) method. Git doesn't catch this, nor would this new system. The solution seems obvious to a human: Use the new name at the new call-site too. But it requires operating at the level of the semantic meaning of a change, and not just the dumb textual changes. I used to think this would require a new version control system that encodes the semantics of the changes in the commits, in order to have them available at merge-time. But these days, it seems much more realistic to stick to git, but loop in LLMs when merging, to re-create the semantics from the textual changes.


This is more than just a version control though, they only thing any VC uses that's important is the diff and the timestamps, you would be adding in project context awareness which is a whole other thing.

I'm sure there are smarter people than me who could create some hooks to automagically update those references on merge/rebase though. Not sure I would pay a whole LLM each time personally.


Darcs did this decades ago with the "replace" command. It's not a legitimate semantic replacement, though - it's more just telling your VCS to do a find/replace.


As far as I remember, that's just because only the find/replace was implemented, and it could have more sophisticated (semantic?) features.


> I renamed a method, while someone else concurrently added another call to that

This is the most common use case for any compiler or linter


If you find this interesting, you might also be interested in this video of someone diving even deeper into how to make the dither surface stable: https://www.youtube.com/watch?v=HPqGaIMVuLs


IMO, the holy grail of 3d dithering is yet to be achieved. runevision's method does not handle surfaces viewed at sharp angles very well. I've thought a lot about a method with fractal adaptive blue noise and analytic anisotropic filtering but I don't yet have the base knowledge to implement it.


My take on it is to use some arbitrary dithering algorithm (e.g. floyd-steinberg, blue noise thresholding, doesn't really matter) for the first frame, and for subsequent frames:

1. Turn the previous dithered framebuffer into a texture

2. Set the UV coordinates for each vertex to their screenspace coordinates from the previous frame

3. Render the new frame using the previous-framebuffer texture and aforementioned UV coords, with nearest-neighbor sampling and no lighting etc. (this alone should produce an effect reminiscent of MPEG motion tracking gone wrong).

4. Render the new frame again using the "regular" textures+lighting to produce a greyscale "ground truth" frame.

5. Use some annealing-like iterative algorithm to tweak the dithered frame (moving pixels, flipping pixels) to minimize perceptual error between that and the ground truth frame. You could split this work into tiles to make it more GPU-friendly.

Steps 4+5 should hopefully turn it from "MPEG gone wrong" into something coherent.


This really is a fantastic video. I don't think I'd considered many of the ideas behind dithering before seeing how it could be extrapolated to this degree.

The video ends in a place where I suspect even further advances could still be made.


There's a follow up video with variations of the technique (some of them with color) demonstrated in a game: https://www.youtube.com/watch?v=EzjWBmhO_1E

But yes, there's still the issue of oblique angles looking different that still remains open AFAIK.


Very cool! The dither is no longer in screenspace though, which kills the retro charm.


Fair point, though I think that when it's low rez enough, it becomes less apparent that it's not in screenspace, and it gets closer to a retro look: https://youtu.be/EzjWBmhO_1E?t=102


Discussed on HN in January 2025: https://news.ycombinator.com/item?id=42808889


I just wish more of these projects would be a bit more ambitious and put more focus in their communication on being good at what they do, rather than being free and made by idealists. They're branding themselves in a way that only really appeals to other techy idealists, while accidentally putting off a lot of potential users who are neither technical nor philosophical enough to know or care what a term like libre means. There's a lot of good, free software that is selling itself short by communicating more about being the latter than the former.


I think there's some truth to what you say - at the same time, a lot of successful products have names that basically have no meaning at all, or at least none that's related to what the project actually does ("Windows", "Cursor", "Firefox", etc...)

Of course, a point could be made that any inoffensive but basically fluffy name is still better than a geeky sounding tech babble name...


"Windows" actually is related to what it does. As you might already know, before Windows, you just had DOS, which was 100% full screen all the time. Then Windows came along an let you run DOS programs (and Windows programs, of course) inside of their own windows, and let you have multiple windows open at once. Then, only after that was hugely successful, it became its own standalone OS. So at least at the time it was created and became popular, its name was very related to what it did.


The most succesful open source projects (firefox, blender, linux, krita,..) do not have libre in their name, the most famous of those who have is probably libreoffice, but it is not exactly loved.

So I totally agree on rather having a name that appeals normal users, than a certain tech bubble who will rather use the terminal wherever they can anyway ..


Hey, no terminal shaming here!


Apologies, not my intention ..


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: