Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
newpavlov
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
8 ms
·
61.
▲
by
newpavlov
1y ago
>If you're not doing things better than threads then why don't you just use threads? Because green threads are more efficient than the classical threads. You have less context switching, more control over concurrency (e.g. you
62.
▲
by
newpavlov
1y ago
The goal of the async system is to allow users to write synchronous looking code which is executed asynchronously with all associated benefits. "Forcing" users to do stuff like this shows the clear failure to achieve this goal. Ad
63.
▲
by
newpavlov
1y ago
Deal with it. Async is my greatest disappointment in the otherwise mostly stellar language. And I will continue to argue strongly against it. After Rust has raised the level of quality and expectations to such great level, async feels like
64.
▲
by
newpavlov
1y ago
>That problem exists regardless of whether you want to use stackful coroutines or not. The stack could be freed by user code at anytime. It could also panic and drop buffers upon unwinding. Nope. The problem does not exist in the stackfu
65.
▲
by
newpavlov
1y ago
No, the fundamental problem (in the context of io-uring) is that futures are managed by user code and can be dropped at any time. This often referred as "cancellation safety". Imagine a future has initialized completion-based IO w
66.
▲
by
newpavlov
1y ago
>which we found in every existing futures implementation we inspected This is exactly what I meant when I wrote about the indirect influence from other languages. People may dress it up as much as they want, but it's clear that poll
67.
▲
by
newpavlov
1y ago
This actually one of my many gripes about Rust async and why I consider it a bad addition to the language in the long term. The fundamental problem is that rust async was developed when epoll was dominant (and almost no one in the Rust circ
68.
▲
by
newpavlov
1y ago
The usual lossless image compression algorithms is the given. I am talking about compressing it further since the telescope observes the same (or largely overlapping) patches of the sky and the most significant signal is stars, which are mo
69.
▲
by
newpavlov
1y ago
I wonder if they could reduce the data size at rest by using specialized compressing techniques. Your probably could build an averaged "model" of the sky observed by the telescope (probably with account for stellar parallax and br
70.
▲
by
newpavlov
1y ago
I meant the absorb and squeeze part. The permutation itself (or more specifically its round) could be efficiently implemented in hardware, but you can't mask latency by parallel application of the permutation. Yes, KangarooTwelve is an
71.
▲
by
newpavlov
1y ago
>Keccak for all of symmetric crypto: it is suited both for encryption, hashing, duplex transcripts for ZK protocols etc. Unfortunately, Keccak and sponge constructions in general are inherently sequential. Even with hardware acceleration
72.
▲
by
newpavlov
1y ago
>In Rust, it's considered a bug for any code which isn't using `unsafe` to encounter a memory error (e.g., to segfault) Teeechnically , it's not true. Unfortunately, you can trigger a memory error in safe code by overflow
73.
▲
by
newpavlov
2y ago
>Incorrect with respect to an assumption furnished where? In the definition of the `NonZeroU8` type. Or in a more practical terms, in LLVM, when we generate LLVM IR we communicate this property to LLVM and it in turn uses it to apply opt
74.
▲
by
newpavlov
2y ago
"Undefined behavior" means that the compiler can apply optimizations which assume that it does not happen, resulting in an incorrect code. A simpler example is `Option<NonZeroU8>`, the compiler assumes that `NonZeroU8` can n
75.
▲
by
newpavlov
2y ago
>What I would like is a CPU with a highly parallel array of "worker cores" all addressing the same memory and speaking the same goddamn language that the CPU does. For "embarrassingly parallel" jobs vector extensions
76.
▲
by
newpavlov
2y ago
Sounds interesting! But I work with Rust, so your project is outside of my direct area of interest. If I am to suggest something, I think you should consider opening some parts of your product, e.g. you could publish your package reviews wi
77.
▲
by
newpavlov
2y ago
Roughly, yes. But it may be just one developer such as burntsushi. For example, by adding the aes-gcm crate to your dependencies you pull whooping 19 dependencies in total, but 13 of those are part of the RustCrypto org and remaining 5 are
78.
▲
by
newpavlov
2y ago
I think there is only one proper solution to the security problem of transitive dependencies: an open database of vetted/rejected libraries and tooling which would help to pull dependency versions according to configured rules. For exa
79.
▲
by
newpavlov
2y ago
In the ideal world, you are right, computer systems should've been using TAI for time tracking and converted it to UTC/local time using TZ databases. But in the real world a lot of systems made the wrong choice (UNIX being the big
80.
▲
by
newpavlov
2y ago
>memory safe (without a borrow checker) This sounds like a very weird statement. In my opinion, a proper proof-oriented language would inevitably contain a borrow checker variant as a subset of its functionality (assuming the language ha
81.
▲
by
newpavlov
2y ago
It's a property of the "semi-artificial" problem chosen by Google. If anything, it means that we should heavily discount this claim of "quantum advantage", especially in the light of inherent probabilistic nature of
82.
▲
by
newpavlov
2y ago
Then his comment makes even less sense.
83.
▲
by
newpavlov
2y ago
>in the quantum research to demonstrate any valuable forward progress you must compute something that is impossible to do with a traditional computer This is factually wrong. The most interesting problems motivating the quantum computing
84.
▲
by
newpavlov
2y ago
Yet another example of async Rust being a source of unexpected ways to shoot yourself in the foot... Async advocates can argue as long as they want about "you're holding it wrong", but to me it sounds like people arguing that
85.
▲
by
newpavlov
2y ago
I was very enthusiastic about RISC-V once upon a time, but after I encountered a number of its "quirks" (e.g. see https://www.reddit.com/r/RISCV/comments/1frrai9 ) my enthusiasm has significantly coo
86.
▲
by
newpavlov
2y ago
>the marginal alternative is LNG, also shipped in oil-fueled cargo ships LNG ships are usually fueled by natural gas evaporated from its liquefied payload, which is much cleaner than burning diesel.
87.
▲
by
newpavlov
2y ago
>Coal is finite, a resources stored away over a tremendous period of time, much of it burned in about a century Sure, it's finite, but we will run out of oil and natural gas much faster than of coal. There are centuries worth of kn
88.
▲
by
newpavlov
2y ago
So Varlink requires a proper specification of message types, but then uses god damn JSON to serialize messages? Why would you do that? Apparently, we don't have enough wasted cycles in modern software, just add a bunch more in a fundam
89.
▲
Opinion/rant: RISC-V prioritizes hardware developers over software developers
(old.reddit.com)
2 points
by
newpavlov
2y ago
|
0 comments
90.
▲
by
newpavlov
2y ago
The problem is that some high-profile people who want to preserve their right to "break whatever", do not want to shoulder responsibility of fixing Rust code which depends on the broken stuff. Even worse, they even do not want to
More ›