nicoburns

7 ms·

121.
by nicoburns 5mo ago
A little slower but safe is a pretty good default I think. Most of the time you're not in a hot loop and even a 5% slowdown would be negligable. And in the cases where you are in a hot loop you just have to put in a little extra effo
122.
by nicoburns 5mo ago
Of course you can write the above as: a[0..32].iter_mut().for_each(|el| *el = 1) and have per-iteration bounds checks elided in Rust today.
123.
by nicoburns 5mo ago
Rust also has these advantages of course
124.
by nicoburns 5mo ago
It really ought to be solar+batteries. It'd be slightly more expensive to build up-front than oil-based solutions, but probably not much and the companies building these data centers have the money to pay for that.
125.
by nicoburns 5mo ago
> For a fair comparison you would also have to present the worst case incremental build time which approaches the full build time (this goes for Go too) The worst case that would approach a non-incremental build time would be if you wer
126.
by nicoburns 5mo ago
The other very important reason for splitting into crates is compile times. Crates are the "compilation unit" and you often get more build paralellism with more crates.
127.
by nicoburns 5mo ago
> claiming that versioning is easier with 0.x than with major version numbers > 0 I think it's less that versioning is claimed to be easier with 0.x versions, and more that some people have got into their heads that 1.0 signals
128.
by nicoburns 5mo ago
> in any case building and immediately building again of course will be fast FWIW, the compile time test above was done comparing consecutive commits. Which in this case happened to have ~3-4 lines changed.
129.
by nicoburns 5mo ago
Sure, but when we're talking single-digit seconds it feels not that significant regardless?
130.
by nicoburns 5mo ago
Incremental Rust builds are almost never minutes (on recentish hardware) A quick measurement on my web browser project with almost 600 dependencies: - A clean "cargo check" was 31s - An incremental "cargo check" with a
131.
by nicoburns 5mo ago
> As far as I know this is an inherent property of Rust to have its safety guarantees. From what I've seen, Rust's strictness is actually a huge win for LLMs, as they get much better feedback on what's wrong with the code.
132.
by nicoburns 5mo ago
Because fabs are about the most complex cutting edge technology out there: the "rocket science" of our day (or one of them). And merely having the money is not sufficient. It would be very easy to blow several billion dollars and
133.
by nicoburns 5mo ago
> Claude Code as the most popular software project ever I don't think that's true? The likes of Chrome, Linux, curl, sqlite, etc, are much more widely used.
134.
by nicoburns 5mo ago
Perhaps it will happen, but I am yet to see good results from AI code review (it can be useful as an additional review, but not (yet) as the sole source of review).
135.
by nicoburns 5mo ago
> As long as the tests pass and the performance doesn't regress and it's secure... why are people so mad that it was vibe coded? Because the chances that they had a test suite that was actually comprehensive enough to guarantee
136.
by nicoburns 5mo ago
Would it not be pretty counterproductive for other countries to assist the US in this case? That seems only likely to prolong / exacerbate the war. The US giving up would be much faster.
137.
by nicoburns 5mo ago
Blitz has good plaintext text input support. But there's no contenteditable (which is what you would need for rich text editing) yet. litehtml appears to have no built-in text input support so far as I can see.
138.
by nicoburns 5mo ago
For just rendering (no editing) you could use https://github.com/litehtml/litehtml (C) or https://github.com/DioxusLabs/blitz (Rust). Both are actually lightweight HTML rendering libraries, so you
139.
by nicoburns 5mo ago
> IMO it's different qualitatively than slack/mattermost/discord/teams I always think of it as being halfway between those and more traditional forums (PHPBB, discourse, etc).
140.
by nicoburns 5mo ago
The trackpads on the old (pre-force-touch MacBooks) were really good. The force-touch is (IMO) slightly better, but it's a slight difference.
141.
by nicoburns 5mo ago
Probably true. I hope they do it next year, but I suspect it might the following one.
142.
by nicoburns 5mo ago
The Neo is pretty great, and the compromises are totally reasonable at the price point. But if they do a second generation with A19 Pro (and thus 12GB RAM) and a slightly better cooling system then it would really be fantastic.
143.
by nicoburns 5mo ago
> I guess I'm not currently stapling the ticket to the binary, but supposedly you don't have to if you are running with a network connection. AFAIK, you do in fact have to staple the ticket. The other thing I found is that you
144.
by nicoburns 6mo ago
They are intrinsically linked beyond a certain point. If we're making progress but costs are spiraling exponentially then it stands to reason that we will soon reach a point where we can no longer afford the increasing costs and thus p
145.
by nicoburns 6mo ago
The cost factors on the new models compared to the old models.
146.
by nicoburns 6mo ago
In the sense that the incremental improvements in capabilities that we've been seeing in recent models seem to taking exponentially growing amounts of compute to achieve.
147.
by nicoburns 6mo ago
Where this clearly wins is native rendering use cases where there is no browser or JS engine involved at all.
148.
by nicoburns 6mo ago
They do. They just solder them onto their SOCs (as part of the manufacturing process of the SOC). But they can't do that if they haven't got any.
149.
by nicoburns 6mo ago
> But why? So they don't have to stop producing machines entirely because they've run out of RAM chips. The problem they have is with supply not demand.
150.
by nicoburns 6mo ago
Memory safety doesn't help too much here, but "RAII" (automatically dropping values when they go out of scope) does.

More ›