dist1ll

9 ms·

31.
by dist1ll 2y ago
> 64000x($100+256x$4)=$7,193,600 worst case pricing Not sure how you arrived at this calculation. 256x$4 already accounts for 256GB. The database in the OP is 6400GB large. So shouldn't it be 25x($100+256x$4) = $28100? FWIW in pract
32.
by dist1ll 2y ago
It's possible to build languages that compile faster than Go, with a much more expressive type system. It's just that compile times and DevEx haven't been a priority for most projects.
33.
by dist1ll 2y ago
How do you avoid branches in 64-bit WASM?
34.
by dist1ll 2y ago
Hopefully they don't axe their NICs. At least Intel provides really good open datasheets for their e800 cards, can't say the same about other vendors.
35.
by dist1ll 2y ago
I agree it's unnecessarily feared. At its core, it lacks a lot of complexity. But actually writing asm is an experience straight from the 80s. Compared to modern languages, the tooling is simply antiquated. I noticed this once I sta
36.
by dist1ll 2y ago
Scala also calls them enums fyi. Personally, I wish everyone would call them variant types.
37.
by dist1ll 2y ago
> I though in my 30+ years of programming cannot think of a particular problem that I have solved that would have been enhanced by this. One example that I frequently deal with that can benefit from this is compiler data structures.
38.
Bit-permuting 16 u32s at once with AVX-512(bitmath.blogspot.com)
51 points by dist1ll 2y ago|4 comments
39.
by dist1ll 2y ago
Yup. Almost every DS in my compiler is either an array or a hashmap.
40.
by dist1ll 2y ago
I don't have a problem with dependencies in principle. There's a good reason for standard libraries to contain a decent amount of code. It is a vector for supply chain attacks, but I also have a lot of trust in the Rust maintain
41.
by dist1ll 2y ago
That's the usual response I get when I bring this issue up. "file watching is actually very complicated" or "if you avoided deps, you'd just reimplement millions of loc yourself. Forgive me if I'm making a very
42.
by dist1ll 2y ago
You're right, the windows crate alone contributes 2.2M. I wonder if there's a way to deal with this issue.
43.
by dist1ll 2y ago
I think the dependency situation is pretty rough, and very few folks want to admit it. An example I recently stumbled upon: the cargo-watch[0] crate. At its core its a pretty simple app. I watches for file changes, and re-runs the compiler.
44.
by dist1ll 2y ago
Thank you, this was exactly my point. If efficiency is important, you want a very thin abstraction over hardware (in other words: library over frameworks). This lack of hardware sympathy is actually something operating systems have been add
45.
by dist1ll 2y ago
> But at the programming language level the compiler does have insight into the dependencies of your continuation This is really the key point - coupled with the fact that certain I/O operations are just inherently asynchronous. The
46.
by dist1ll 2y ago
Yielding in a cooperatively multitasked runtime is not comparable to OS context switches between user threads. The former is very, very efficient.
47.
by dist1ll 2y ago
The tree example is quite contrived. Most Rust programmers would use indices for indirection, pointing into flat buffers.
48.
by dist1ll 2y ago
Sure, but that's kind of beside the point I was making. The author was contrasting loops - an imperative construct (which both C-style for and iterator-based for are examples of) - to the functional style of chaining iterator functions
49.
by dist1ll 2y ago
IIRC for loops compile down to a while loop with the same body, that drives the given iterator with .next(), until it returns None. Since the .next() implementation of std::ops::Range is essentially an i++, you'll quickly arrive at a s
50.
by dist1ll 2y ago
I think that's bit too pedantic. Most people in the Rust community refer to for expressions as for loops (including the book). It's especially odd to point out this language detail, because for expressions always return the unit t
51.
by dist1ll 2y ago
> For loops are not idiomatic in Rust That's not really the case. For loops are certainly less common compared to C, but they are completely fine to use. Forcing every loop into an iterator-chain style can sometimes be more confus
52.
by dist1ll 2y ago
Fwiw, many C projects are written in a non-standard C dialect, including the Linux kernel.
53.
by dist1ll 2y ago
The abbreviation is also used by EE folks, e.g. SerDes [0]. The capitalization makes it a bit more obvious. [0] https://en.wikipedia.org/wiki/SerDes
54.
by dist1ll 2y ago
I'm primarily interested in full compilation performance, but thanks for the tip!
55.
by dist1ll 2y ago
It seems like I can't include standard header files, so it can't compile a common hello world. I guess that'd be useful to mention on the README, or maybe I'm doing something wrong? main.c:1:10: fatal error: '
56.
by dist1ll 2y ago
We've done large schema migrations in a 1 million LoC Rust codebase. Most of the time, these are pretty straightforward. You mark things as deprecated and link a tracking ticket for the migration in the doc-comment of the field/st
57.
by dist1ll 2y ago
First time I hear about HighLoad. Seems really interesting to me on the first glance. I personally find SIMD and ISA/μarch-specific optimizations more rewarding than pure algorithmic challenges (codeforces and such). Though Haswell see
58.
by dist1ll 2y ago
From the chromium website > Around 70% of our high severity security bugs are memory unsafety problems (that is, mistakes with C/C++ pointers). Half of those are use-after-free bugs. https://www.chromium.org/Home&#x2
59.
by dist1ll 2y ago
Yes, memory safety issues make up a large majority of high-severity security bugs in Chromium. See https://www.chromium.org/Home/chromium-security/memory-safet...
60.
Guide on optimizing Linux kernel with BOLT(github.com)
12 points by dist1ll 2y ago|0 comments

More ›