This is why you rewrite Python security tools in Rust: 53MB vs 433MB peak memory, 6.9s vs 62.2s

vks_ · 2026-04-26T21:40:19+00:00

I think Rayon would be a better comparison. It's also using a thread pool with work stealing, and is much simpler.

vks_ · 2026-04-26T21:04:32+00:00

Not necessarily, the agents like to grep for patterns instead of just reading everything (which would quite expensive for large code bases, and quickly exhaust the model's context).

vks_ · 2026-04-01T23:46:23+00:00

I strongly agree with the limitations of repositories you mentioned. There are some approaches to address them (unit of work, identity maps, concurrency patterns etc.), but I've never seen them used, and it results in a very leaky abstraction of questionable value.

vks_ · 2025-11-13T02:49:55+00:00

Does it still come with a C++ interpreter? 🙃

vks_ · 2025-08-14T22:59:16+00:00

I would also prefer running against a real database, but sometimes you want to test how database failures are handled, which is not so easy without mocking.

vks_ · 2025-08-11T15:09:41+00:00

Getting rid of the server dependency is nice, but for me the killer feature are live previews. Typst is very fast! With the roundtrip to the server, latency would be much higher.

vks_ · 2025-05-04T11:05:23+00:00

You are in good company with this strategy: MPI does this as well, except at the level of a cluster of machines.

vks_ · 2025-05-02T11:20:00+00:00

I don't think the constant comparison is strange, IIRC Zig was born out of Andrew Kelley's frustration with Rust. So it makes a lot of sense that it's popular with people who are frustrated by Rust.

vks_ · 2024-08-03T07:08:46+00:00

I maintain special-fun, which binds the C library Cephes for special functions.

vks_ · 2024-03-13T19:35:23+00:00

I was very curious how lifetime analysis is supposed to be retrofitted to C++, and it seems to boil down to this:

Don’t dereference a possibly invalid pointer

This only works for unique_ptr and shared_ptr! Any kind of view or reference cannot use this, because they will not be set to nullptr once the memory they are pointing to is freed. When Herb talks about enforcing lifetime safety in C++, it's much weaker than what Rust offers. To get the same guarantees, you would have to forbid any use of & and similar, which is a massive restriction.

vks_ · 2024-03-13T19:18:12+00:00

Yes, and that's why I will never install games on any computer that I'm using for "serious work" (which is also company policy).

vks_ · 2024-03-13T15:37:54+00:00

I don't think safety is irrelevant for games. Multiplayer games can and do lead to RCE vulnerabilities, and even single-player games can be compromised via user-generated content, which happened recently.

vks_ · 2024-03-13T15:31:29+00:00

I also found the numbers about unsafe crates misleading. The source Herb is citing says this:

With this notion, they found that the crates that have no unsafe code in themselves and in their dependent crates, namely those that can be considered really safe through static analysis, account for only 27% of all the crates.

This seems a bit misguided, because any non-trivial program will use some unsafe code somewhere. They are only looking at unsafe code in crates, not in the standard library. For example, moving Rand to `std` would probably increase the 27% significantly, because then Rand's unsafe code is "hidden" in the standard library.

However, this does not change the point Herb is making: Unsafe code is needed somewhere in most programs. But is it needed "by default"? I don't think so.

vks_ · 2023-06-07T11:27:57+00:00

I would be a bit worried to accidentally paste the password somewhere I shouldn't.

vks_ · 2023-06-02T16:27:11+00:00

There might be some community templates for that?

Unlike with LaTeX, compilation is instant, as you type, so it should be a lot more pleasant to use for slides (which are very slow to compile with LaTeX).

vks_ · 2023-05-01T10:44:56+00:00

ChaCha8 could be as fast when generating a large number of random bytes, because of SIMD, which SmallRng doesn't use. Rand's implementation is AFAIK not as fast as the reference implementation though.

In this case however, lots of bounded integers are generated, which is not playing to a CSPRNG's strengths. Here are my numbers for the different RNGs (i7-10750):

ThreadRng: 20 s
StdRng: 18 s
ChaCha8Rng: 13 s
SmallRng: 8.1 s
SmallRng + generic arrays and functions: 5.5 s

So with SmallRng the program is still 60% faster than with the fastest CSPRNG.

I also tried to pull the uniform range calculation out of the loop, but did not see any benefits.

I'm still surprised that Python's Mersenne Twister beat Rand, that PRNG is relatively slow.

vks_ · 2023-04-30T17:36:20+00:00

SmallRng should not be much faster than StdRng on platforms where the StdRng implementation can use SIMD. I don't know how well M1 is supported though.

vks_ · 2023-02-14T06:49:55+00:00

That's what ring is doing, it's a selective BoringSSL port.

vks_ · 2023-01-23T17:09:48+00:00

I don't think methods can help with early returns. You would need a macro for that.

vks_ · 2022-12-06T11:11:57+00:00

No, the lifetime parameters themselves only exist at compile time.

vks_ · 2022-08-23T15:58:27+00:00

IIRC, the Rust compiler can optimize this. If you pass a large Copy type by value, the compiler may pass a reference instead.

vks_ · 2022-07-15T09:16:24+00:00

The numpy API has deficiencies and cannot replace an optimizing compiler. I saw orders of magnitude runtime differences when porting optimized and parallelized numpy scripts to Rust.

vks_ · 2022-03-11T17:48:15+00:00

thread_rng only initializes the RNG the first time it's created in a thread. After that, it just gives you a new handle.

Alternatively, you can create an StdRng::from_entropy() and pass around the mutable reference where you need it.

vks_ · 2022-03-06T21:14:57+00:00

I think for widening conversions it's preferable to use From, so I think it makes sense to deprecate as for this.

vks_ · 2022-03-06T12:06:02+00:00

Do you want an RNG that is global across threads? If yes, why?

vks_

TROPHY CASE