I did give up as well though, all of this is just too much of a faff. Hopefully Intel continues to make strides with their discrete graphics. They are the only manufacturer without DRM blocking this feature which the hardware can obviously do.
Through the magic of Claude, here is what the two hundred and eleven javascript files that GitHub loads on accessing an empty repo with just .md files (https://github.com/github-samples/.github):
┌─────────────────┬───────┬────────────┬────────────┐
│ Category │ Files │ Total Size │ Total Time │
├─────────────────┼───────┼────────────┼────────────┤
│ Copilot │ 32 │ 1,749 KB │ 1,141 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ GraphQL / Relay │ 4 │ 1,629 KB │ 190 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ Primer Design │ 4 │ 1,617 KB │ 329 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ Highlighting │ 4 │ 1,048 KB │ 414 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ Code View │ 14 │ 966 KB │ 1,226 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ React Core │ 6 │ 692 KB │ 446 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ UI Components │ 26 │ 674 KB │ 1,541 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ SVG │ 2 │ 634 KB │ 51 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ Code Editor │ 9 │ 615 KB │ 366 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ Vendored │ 17 │ 608 KB │ 986 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ Issues │ 13 │ 589 KB │ 504 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ Markdown │ 8 │ 321 KB │ 198 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ Runtime │ 12 │ 263 KB │ 807 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ HTML Parsing │ 2 │ 235 KB │ 152 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ Navigation │ 11 │ 230 KB │ 362 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ Web Components │ 7 │ 229 KB │ 540 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ Comments │ 4 │ 131 KB │ 146 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ Analytics │ 5 │ 103 KB │ 348 ms │
├─────────────────┼───────┼────────────┼────────────┤
│ Other │ 32 │ 484 KB │ 2099 ms │
└─────────────────┴───────┴────────────┴────────────┘
Times given for a 150 Mbps WiFi connection.
Some personal highlights:
- Syntax Highlighting for every obscure language under the sun. Seems like the language analysis they do the repository does nothing.
- Shipping the editor on pages where there is no editor
- Shipping Copilot prompts. Incredible. { prompt:\"Analyze the test coverage of this codebase. Identify areas with missing or insufficient tests and add comprehensive test cases to improve coverage.\" }
- Just a javascript file with a massive 500K SVG.
- I don't really know anything about GraphQL & Relay. But 1.4 megabytes of generated ASTs?
In my experience LLMs (I speak mainly of Claude Code & Cursor) write very poor quality Rust.
They treat it like it's JavaScript, falling back to using String/&str needlessly instead of making new types. They do ugly `static Mutex<Refcell<` a-la global JS variables for info sharing instead of working out the lifetimes to do it properly. It loves making functions infallible and then panic-ing within them and certainly I wouldn't use them for unsafe at all - they hallucinate safety comments which are in fact, totally unsound.
Of course these are all surmountable with an experienced developer to regularly step in and unfuck the code, but forcing them into 'harder' territory where every problem is not solved by a .clone() and an Arc<Mutex<>> means they will spend minutes 'thinking' about basic lifetime issues until I step in and add the missing `move` in a closure.
We’ve developed incredibly strict and comprehensive clippy rules and found that to drastically improve the quality of the code as the LLM now should pass all clippy checks. You can add a clippy skill as well to attempt to turn “should” into “must.”
That is interesting. I make LLMs write C with the general hope that a simpler language they can manage well. That is not entirely true, though. They reason about C fluently indeed. The problem is, Claude pumps lots of bad C into the codebase if left unattended for 5 min.
So, I need some clean-up passes afterwards to get to some acceptable quality level (both by LLMs and my own eyes). At which point, Claude sees the problem clearly, for some mysterious reason.
Also, I use a C dialect heavly influenced by Go (slices, generics, no smart tricks, virtually no malloc).
> general hope that a simpler language they can manage well
It's the opposite; a language with lots of guardrails allows the AI to write better code especially as it is able to use the compiler and linter to guide it through the process. It's why OpenAI for example was able to disprove some recent theorem recently, due to the LLM converting its thoughts into a formal language theorem prover to then check its work.
Is THAT how people use AI? I thought _I_ was vibe coding by telling it to write one function at a time and making sure I understand every line it outputs.
"Vibe coding" is a term that means "Prompt the LLM with a request for a project and wait for it to finish". If you're reading and understanding anything it made, that's not vibe coding, that's agentic development.
this was true a year ago but not so much anymore. You still have to supervise the agents, but they can write maintainable code if you keep an eye on it.
The simplicity of Gorilla is attractive but for better compression ratios without too much extra compute I'd instead recommend Sprintz: https://github.com/dblalock/sprintz.
The downside is that (a) Sprintz requires the data to be quantised to fixed point integers, usually fine if the data is coming out of a sensor of some sort and (b) the Huffman coding step of Sprintz requires dynamic memory allocation, whilst Gorilla is almost trivially implemented without it.
An observer falling into the black hole would not observe any distortion in time. They would simply fall in, under the influence of gravity. From the perspective of a far-away observer it would look as if time is slowing down as the photons would take increasingly longer to escape. At the event horizon the photons would effectively be held in place. Eventually though, the last photon will have escaped and you will just observe a slightly larger black hole.
So the merger definitely happens from the point of view of the black holes. We might observe odd artifacts but they would eventually fade away.
Are you suggesting Rust should automatically insert the borrow annotation because it is able to see that a borrow is sufficient? That would be quite unintuitive and make it ambiguous whether a for loop is borrowing or consuming the iterator without reviewing the body. I'd strongly argue that it should unambiguously do either one or the other and not try and read the author's mind.
Yes, I'm suggesting it should do the right thing for the code the loop is actually trying to execute. I personally think this is exactly what Rust and its users have signed up for. I might be mistaken about that, but I think it's in line with the more general view that Rust is attempting to be as close as it can get to a language that reads like it has a garbage collector without having one.
> the more general view that Rust is attempting to be as close as it can get to a language that reads like it has a garbage collector without having one.
I've used Rust a fair amount, and I've never seen that expressed as a goal.
A couple of general principles followed by Rust are to prefer explicit code over implicit conversions and to support local reasoning. Those are both present here: the borrow needs to be made explicitly, rather than implicitly based on code later on.
I think you have misread the abstract. The 'low statistical significance' was a [prior work](https://iopscience.iop.org/article/10.3847/2041-8213/acf577). This paper has increased the significance to 3-sigmas which is on the lower end but still quite significant.
This should work without needing a reboot. You do have to bind the vfio driver at boot, but the archwiki gives a script to unbind vfio and load the Nvidia driver: https://wiki.archlinux.org/title/PCI_passthrough_via_OVMF#Bi...
Which anecdotally worked fine on my RTX3050.
I did give up as well though, all of this is just too much of a faff. Hopefully Intel continues to make strides with their discrete graphics. They are the only manufacturer without DRM blocking this feature which the hardware can obviously do.
reply