Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
writebetterc
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
7 ms
·
31.
▲
by
writebetterc
1y ago
Java doesn't produce 'garbage data', racing writes will never show intermediary results.
32.
▲
by
writebetterc
1y ago
Sorry, I don't see it that way.
33.
▲
by
writebetterc
1y ago
Why should we care about the COSMIC Desktop Environment? Edit: I've now gotten 2 downvotes in 4 minutes. I do not understand what's so controversial about this comment. Why should we care about having a third DE? Does this matter
34.
▲
by
writebetterc
1y ago
Intel Arc Pro B60 will come in a 48GB dual-GPU model. So yeah, hardware is gonna be there, and the 24GB model will be $599 from Sparkle. I assume 48GB will be cheaper than a hacked RTX 4090. Look at this: https://www.maxsun.com&#
35.
▲
by
writebetterc
1y ago
There are old Arabic maps which have south at the top.
36.
▲
by
writebetterc
1y ago
I don't think it counts as visiting, as you never look at the dirtied bitmap during GC, only during allocation. That means, you don't actually know if a dirty bit represents a different object or not (if a 16-byte size class is al
37.
▲
by
writebetterc
1y ago
I forgot that this GC is non-moving (I'm not used to that assumption, and it was a bit of a quick comment). I do find the statement dubious still, do you mind clearing it up for me? Given a page { void* addr; size_t size; size_t alignm
38.
▲
by
writebetterc
1y ago
To add on top of this: This is a tracing GC. It only ever visits the live data, not the dead data. In other words, it would need a lot more special support if it wanted to report the dead objects.
39.
▲
by
writebetterc
1y ago
I'm not sure what the goal was here, that's not what I'm saying.
40.
▲
by
writebetterc
1y ago
I'll do the opposite: The P vs NP episode is aboslutely horrid. Probably the first and last time that they had any informatics people on the show. One major issue is that the experts didn't explain what we mean by "hard"
41.
▲
by
writebetterc
1y ago
Same, Emacs is improving at a rapid rate thanks to its adoption of LSP and Tree-Sitter. Performance is very good, but the async story needs to become better.
42.
▲
by
writebetterc
1y ago
Let's not over correct, of course O-notation has something do with algorithms for the working programmer.
43.
▲
by
writebetterc
1y ago
Good job on dispelling the myth of "compiler = fast". I hope SPython will be able to transfer some of its ideas to CPython with time.
44.
▲
by
writebetterc
1y ago
That was quite rude of Andrew. If someone doesn't want to review a PR, then they should just ignore it IMHO.
45.
▲
by
writebetterc
1y ago
They're talking about dollars
46.
▲
by
writebetterc
1y ago
C++ has bitfields built in : https://en.cppreference.com/w/cpp/language/bit_field.html
47.
▲
by
writebetterc
1y ago
Fedora 41, KDE Plasma 6.3.5, kernel 6.14.5, Wayland, Mesa Intel Iris Xe Graphics.
48.
▲
by
writebetterc
1y ago
I think you answered how you managed to induce latency in Emacs :).
49.
▲
by
writebetterc
1y ago
It's surprisingly slow. Switching files in the tab list has a noticeable delay. Typing is higher latency than both Emacs (lsp-mode activated) and my web browser. Also uses approximately 60MiB more than my Emacs. It starts fast though!
50.
▲
by
writebetterc
1y ago
FWIW, I've heard from people who know this stuff that linking is actually super slow for us :). I also wanted to try out mold, but I couldn't manage to get it to work.
51.
▲
by
writebetterc
1y ago
>10 minutes for linking? The only projects I've touched which have had those kinds of link times have been behemoths like Chromium. That must absolutely suck to work with. I don't know the exact amounts of time per phase, but y
52.
▲
by
writebetterc
1y ago
>How long are you realistically "waiting for the compiler and linker"? 3 seconds? You're not recompiling the whole project after all, just one source file typically 10 minutes. >If I wanna use a debugger though, now tha
53.
▲
by
writebetterc
1y ago
You can't use KeepassXC + Firefox? Might need to downgrade the KeepassXC browser plugin (because of a bug)
54.
▲
by
writebetterc
1y ago
> As it happened, my superiors had come to realize the same, so when I asked for a talk, they preempted my plan by announcing this. What is "this"?
55.
▲
by
writebetterc
1y ago
Multi-tenancy on the JVM makes me shudder, though. The general point you're making, thumbs up to that.
56.
▲
by
writebetterc
1y ago
Ownership and lifetimes are arguably not about Rust, but about how we construct programs today. Big, interdependent, object graphs are not a good way of constructing programs in Rust or C++.
57.
▲
by
writebetterc
1y ago
You don't need to learn how git works internally to be able to use it. You need to know a lot about filesystems in order to use them: Folders, files, symbolic links, copy, cut, paste, how folders can exist on different devices, etc. Th
58.
▲
by
writebetterc
1y ago
Yes, Rust is better. Implicit numeric conversion is terrible. However, don't use atoi if you're writing C++ :-). The STL has conversion functions that will throw, so separate problem.
59.
▲
by
writebetterc
1y ago
It's a bit annoying that there is a standard desugaring of all of this, but there's no actual way of implementing this sugaring yourself. I guess you could have a token macro (or whatever they're called) at the top scope and
60.
▲
by
writebetterc
1y ago
>Benchmarks show its about 25% faster than the raw pointer version. (I don't know why - but I suspect the reason is due to better cache locality.) Cache locality matters, but so does having less allocator pressure. Use 32-bit unsign
More ›