newpavlov

6 ms·

31.
by newpavlov 10mo ago
>`async` is in the type system. No, it's not. `async` is just syntax sugar, the "effect" gets emulated in the type system using `Future`. This is one of the reasons why the `async` system feels so foreign and requires so m
32.
by newpavlov 10mo ago
I agree. But it should be done with a proper effect system, not a pile of ad hoc hacks built on abuse of the type system.
33.
by newpavlov 10mo ago
In my (Rust-colored) opinion, the async keyword has two main problems: 1) It tracks code property which is usually omitted in sync code (i.e. most languages do not mark functions with "does IO"). Why IO is more important than &quo
34.
by newpavlov 11mo ago
While I agree that dependency tree size can be sometimes a problem in Rust, I think it often gets overblown. Sure, having hundreds of dependencies in a "simple" project can be scary, but: 1) No one forces you to use dependencies w
35.
by newpavlov 11mo ago
Great comment! I agree about comptime, as a Rust programmer I consider it one of the areas where Zig is clearly better than Rust with its two macro systems and the declarative generics language. It's probably the biggest "killer f
36.
by newpavlov 11mo ago
>often more performant than Rust with lower resource usage [citation needed] If we are to trust this page [0] Rust beats Zig on most benchmarks. In the Techempower benchmarks [1] Rust submissions dominate the TOP, while Zig is... quite f
37.
by newpavlov 11mo ago
Have you tried the GNU toolchain? IIRC rustup provides the option to use it instead of the MSVC toolchain during the initial installation.
38.
by newpavlov 11mo ago
I agree. In my opinion NaNs were a big mistake in the IEEE 754 spec. Not only they introduce a lot of special casing, but also consume a relatively big chunk of all values in 32 bit floats (~0.4%). I am not saying we do not need NaNs (I wou
39.
by newpavlov 11mo ago
>This goes all the way back to the "futures are inert" design of async Rust Yeap. And this footgun is yet another addition to the long list of reasons why I consider the Rust async model with its "inert" futures manag
40.
by newpavlov 1y ago
In most cases locale is encoded in character itself, i.e. Latin "a" and Cyrillic "a" are two different characters, despite being visually indistinguishable in most cases. The "language-sensitive" section of the
41.
by newpavlov 1y ago
IIUC graphitosis, silicosis, and black lung require to inhale ungodly amounts of dust. It's orders of magnitude more than we can expect from flaking-based trace contamination. Why do you expect a different result from "tiny sheets
42.
by newpavlov 1y ago
>Try not to breathe any, studies are still pending but that stuff gets everywhere. I would understand such comment in the context of carbon nanotubes or fullerenes, but graphene? Have you forgot that graphite is literally a bunch of stac
43.
by newpavlov 1y ago
I call BS. Without a series of MAJOR blunders Unicode was destined to succeed. When the rest of the world has migrated to Unicode, I am more than certain that Turks would've migrated as well. Yes, they may have complained for several y
44.
by newpavlov 1y ago
>If they had invented a separate code point for I in Turkish, then when converting text from those existing ISO character encodings, you’d have to know whether the text is Turkish or English or something else, to know which Unicode code
45.
by newpavlov 1y ago
>Even modern languages like Rust did a crappy job of enforcing it Rust did the only sensible thing here. String handling algorithms SHOULD NOT depend on locale and reusing LATIN CAPITAL LETTER I arguably was a terrible decision on the Un
46.
by newpavlov 1y ago
Thank you for a great overview! I wish HTTP3/QUIC was the "default option" and had much wider adoption. Unfortunately, software implementations of QUIC suffer from dealing with UDP directly. Every UDP packet involves one sysc
47.
by newpavlov 1y ago
The kernel ABI is notoriously backwards compatible (the famous "we do not break userspace" and all). The primary reason why binaries rot on Linux is GLIBC and other shared library dependencies. I still can execute a MUSL binary co
48.
by newpavlov 1y ago
I still disagree with their decision to make libc THE system interface. I understand why it's important to provide a compatibility layer, bit, ideally, I would like to see a Linux-like (potentially semver-versioned) stable sycall API,
49.
by newpavlov 1y ago
I wonder if there is a nice formula for the pi from n plot (extended to real n-s). It looks "nice enough" on the first glance. As for n=0, can't you prove that pi=inf for n=0 using limits?
50.
by newpavlov 1y ago
It's great to see PeerTube development, but I think it will continue to be extremely niche until a good solution for decentralized monetization is found. For both content creators and data hosters. It's extremely hard to move user
51.
by newpavlov 1y ago
I can not name an ISA with such instructions out of my head. As for unsigned integers, as I mentioned in the other comment, we probably need two separate instruction sets for "wrapping" and NaN-able operations on unsigned integers
52.
by newpavlov 1y ago
For absolute jumps you don't need extra logic, since CPUs could declare the last page always unmapped, so such jumps would always result in a page fault (similarly to the null page on most systems). For relative non-immediate jumps the
53.
by newpavlov 1y ago
- Handling of misaligned loads/stores: RISC-V got itself into a weird middle ground, ops on misaligned pointers may work fine, may work "extremely slow", or cause fatal exceptions (yes, I know about Zicclsm, it's extreme
54.
by newpavlov 1y ago
>Wouldn't this make CPU flags useless? They would, but I agree with RISC-V here, CPUs should not rely on them in the first place. I do not understand your argument about branches, how would it hinder the jump instructions? We still
55.
by newpavlov 1y ago
>RISC-V is a new-school hyper-academic hot mess. Yeah... Previously I was a big fan of RISC-V, but after I had to dig slightly deeper into it as a software developer my enthusiasm for it has cooled down significantly. It's still gre
56.
by newpavlov 1y ago
Tangential note: I sometimes wish that signed integers were symmetrical. i8 would represent the range of [-127 to 127] with 0xFF representing NaN. Any operation which can not be computed (division by zero, overflows, operation with another
57.
by newpavlov 1y ago
As well as in a number of widely spread cryptographic algorithms (e.g. SHA-2), which use BE for historic reasons.
58.
by newpavlov 1y ago
>Is this really better than what we have now? Depends on the metric you use. Memory-wise it's a bit less efficient (our tasks usually are quite big, so relative overhead is small in our case), runtime-wise it should be on par or sli
59.
by newpavlov 1y ago
You have an inevitable overhead of managing the owned buffer when compared against simply passing mutable borrow to an already existing buffer. Imagine if `io::Read` APIs were constructed as `fn read(&mut self, buf: Vec<u8>) ->
60.
by newpavlov 1y ago
>is that a failure of the async model This, 100%. Being really generous, it can be called a leaky model which is poorly compatible with completion-based APIs.

More ›