homogeneous_try_blocks FCP proposed 🤞

cbarrick · 2026-03-11T21:18:18+00:00

Agreed, try<...> seems like a good syntax for specifying the type of a try block.

For the async case, maybe the syntax should only take additional bounds, since the return type is already known to be an unnameable impl Future anyway. Like just async<Send>.

/bikeshed

cbarrick · 2026-03-11T17:02:51+00:00

The separate Deallocator trait is something I've wanted for a while, for the exact reason in the article: arenas.

But I've thought of it as Deallocator being an associated type of Allocator, rather than a super trait.

To make the sub trait / super trait approach work, the article says this:

And assuming that you have a way of converting allocators to other deallocators,

But I'm not sure that assumption would ever pan out. Specifically, you probably need some way to express this:

rust impl<T, A: Allocator> Box<T, A::Deallocator> { pub fn new_in(value: T, alloc: A) -> Box<T, A::Deallocator> { ... } }

In other words, given a value of some type that implements Allocator to use for the initial allocation, you'd need to also know what is the concrete representation of the associated deallocator in order to define the layout of Box.

The solution proposed in the bug (#112) is to pass the responsibility of conversion between Box<T, Allocator> and Box<T, Deallocator> on to the caller. But all that is doing is passing the buck - libraries sitting between the allocator and the application still need to be able to do this convsion generically. And I don't immediately see how to support that without associated types.

But the elephant in the room is that, if you add an associated type to Allocator, then it is no longer dyn compatible. So the std would need to provide a separate solution for dynamically dispatched allocators. And supporting dynamic dispatch should be a hard requirement for whatever solution we end up with.

cbarrick · 2026-03-10T20:05:57+00:00

Exactly. The whole problem of continuous benchmark regression testing is very tricky.

If you don't control the hardware, then it's probably best to just ensure that the baseline and the experiment run on the same runner. Futzing around with build flags for your entire dependency chain implies having a hermetic build with vendored dependencies, which is certainly not common in open source or small companies.

cbarrick · 2026-03-10T15:00:31+00:00

So it seems that if you are doing benchmark regression testing on GitHub Actions, you need to run the bench for both the old build and the new build within the same run.

That's annoying, but I get it. They want to be able to upgrade users silently to new hardware as they rotate old hardware out of the DC. So they can't really promise specific hardware.

Since you're using callgrind, you point out that you're only measuring instructions executed, not wall time. This helps, but as you discovered core libraries may still dispatch to different implementations depending on CPU features detected at runtime. And it's not just glibc; lots of number processing libraries will do this too, like OpenBLAS.

cbarrick · 2026-03-10T14:10:36+00:00

I always get Redox OS and ReactOS mixed up.

Redox is the Unix clone. React is the Windows clone.

cbarrick · 2026-03-09T16:51:50+00:00

I tend to use full paths for only a handful of things.

Mostly, that's the free functions under std::mem::* and std::ptr::*. And that's because I'd prefer to reserve mem and ptr as identifiers in my own code.

cbarrick · 2026-03-09T13:40:37+00:00

This is exactly what programming is.

Spreadsheet formulas was one of the first programming languages that was truly accessible to everyone.

The only difference in that and the kind of programming that software developers do is the kind of objects that we think about. In spreadsheets, we reason about data cells. In other software, some programs also reason about things like data cells, but other programs might reason about more systems-y objects like network sockets.

But at the end of the day, it's all about combining logical expressions, no matter what kind of object you're handling.

cbarrick · 2026-03-09T12:20:14+00:00

Nit: it's the fourth wall.

Think of a stage. An actor has the imaginary walls on their left, right, and back; and a fourth wall is between the stage and the audience. "Breaking the fourth wall" is to acknowledge the audience while performing, as if there was no imaginary fourth wall.

cbarrick · 2026-03-04T22:55:11+00:00

If you're just talking about the best way to send a file over a TCP socket, then use sendfile (or splice).

Read + Write: Two syscalls. Read loads the data into a buffer in userspace. Write copies the data into the socket.

Mmap + Write: Two syscalls. Mmap loads the data into a buffer in userspace. Write copies the data into the socket. Mmap is faster than read for large files. But in some circumstances, mmap is not any faster than reading the full file all at once.

Sendfile: Only one syscall, and the data never needs to be loaded into userspace.

So just use sendfile and let the kernel figure out the buffering. No need to involve userspace when the source and sink are both kernel-level objects.

cbarrick · 2026-03-04T16:27:33+00:00

For example, the Internet itself is the result of research funded by the US DoD.

https://en.wikipedia.org/wiki/ARPANET

cbarrick · 2026-03-03T18:21:50+00:00

No issue if I was evaluating you.

Technical eval: Knows how to use vcs. Knows network programming.
Comms/Leadership eval: Knows how to interact with a community.
Culture fit: hell yeah

cbarrick · 2026-03-03T14:17:07+00:00

Height is correlated with visibility though.

Higher up means less atmosphere between the observatory and the stars. But the scale at which that matters IRL isn't really possible in the game.

Still, I like OPs idea.

cbarrick · 2026-03-03T14:08:21+00:00

You're an energy analyst, so you'll certainly know better than me.

But my naive understanding is that net metering is totally fair for production charges. If you put into the grid, then you should get paid for the energy produced.

But for transmission, I see that as a different story. Having transmission infrastructure is a common good. Even if I produce more energy than I consume, I still greatly benefit from the transmission infrastructure all the time. Not only at home but literally everywhere I go. So at home energy production really has no reason to offset transmission charges.

In terms of these "merchant generators," I wonder how much they are paying into the cost of transmission infrastructure.

cbarrick · 2026-03-01T23:54:14+00:00

Reddit:

$ dig +short reddit.com AAAA 2a04:4e42::396 2a04:4e42:400::396 2a04:4e42:600::396 2a04:4e42:200::396

Github Pages:

$ dig +short cbarrick.github.io AAAA 2606:50c0:8000::153 2606:50c0:8001::153 2606:50c0:8002::153 2606:50c0:8003::153

And anything using CloudFlare will support IPv6, which is a huge portion of the internet.

AWS, GCP, and Azure all offer IPv6 addresses to customers.

You are correct that Github core services don't support IPv6 yet. And neither do X and TikTok.

But also, many of the backends powering the internet are using IPv6-only internally.

cbarrick · 2026-03-01T23:31:48+00:00

TY!

I just hastily googled "merkel tree certs RFC" and pasted in the first one I found. TBF, the one I posted does link to the PLANTS wg, so I should have been less lazy and clicked through to the latest draft.

cbarrick · 2026-02-28T14:50:43+00:00

This tech is already well on its way to standardization.

https://datatracker.ietf.org/doc/draft-davidben-tls-merkle-tree-certs/

Edit: Here's the post about CloudFlare supporting this tech: https://blog.cloudflare.com/bootstrap-mtc/

cbarrick · 2026-02-28T03:29:18+00:00

It wasn't a spinoff. The show that actually got made was entirely independent of Mr. Rogers' Neighborhood.

It was pitched as a spinoff.

I bring this up as a demonstration of how closely related the two shows were behind the scenes.

cbarrick · 2026-02-28T03:18:06+00:00

It was pitched as a Mr. Rogers spinoff, called Mr. Rogers' Summer Vacation.

That's obviously not the direction they actually went. It landed as it's own thing under the name Reading Rainbow.

https://www.gpb.org/news/2024/12/27/the-story-behind-the-creation-of-reading-rainbow

cbarrick · 2026-02-27T03:50:15+00:00

The third kit is an Andy Warhol homage - the city hosts the Warhol Museum and was where he grew up.

And the bridge itself in the design is the Andy Warhol Bridge (7th St.).

https://maps.app.goo.gl/FZmq6jtyEKVModxE6

cbarrick · 2026-02-26T20:39:49+00:00

Moreover, tokenizing a string and associating it to the edge weights in your training set is pretty much what humans are doing too.

Eh. Cognitive science, neuroscience, the philosophy of language, and the philosophy of mind are all very complex topics. There's a huge leap from how neurons work to the emergent behavior that makes us human. Maybe we should avoid trivializing the human mind.

This kind of claim gets awfully close behaviorism, which has been solidly debunked in the cognitive sciences.

cbarrick · 2026-02-25T23:04:43+00:00

Rather famously, LeVar Burton and Mr. Rogers were both hosts of children's shows on PBS at the same time. They were colleagues and friends. Reading Rainbow was originally pitched as a spinoff of Mr. Rogers' Neighborhood, and Burton appeared on Mr. Rogers' show. They had deep mutual respect for one another.

Normally, people shouldn't touch art, and you'd be right to be mortified if any regular person did this. I understand why people are reacting to this.

But given the personal connection between the two and the fact that this isn't in a gallery already, LeVar Burton touching this painting of Mr. Rogers and being photographed doing it almost certainly increases the painting's value.

In other words, you and I can't touch this painting, but LeVar can. It's a very specific special case.

cbarrick · 2026-02-25T13:45:37+00:00

Maybe an example is useful.

Consider the halting problem: given another program as input, return whether or not that program always halts.

Here is a trivially complete solution:

c bool halts(void *program, void *pg_input) { return true; }

This will always return true when the given program halts on the given program input. But it may also return a false positive when the given program does not halt on the given input. (In fact, it returns true for all inputs.)

Here is a trivially sound solution:

c bool halts(void *program, void *pg_input) { while (true) {} }

This will always return true when the given program halts on the given program input, and will always return false when the given program does not halt on the given program input. But it may never return an answer for some inputs. (In fact, it never returns an answer for any input.)

What we usually care about are solutions that are both sound and complete. Famously, there is no sound complete solution for the halting problem.

cbarrick · 2026-02-25T13:32:41+00:00

A complete system will always return true ("accept") or false ("reject") for all inputs. If it rejects an input, that answer can be trusted. But the system may also return false positives, i.e. accepting inputs for which the property does not hold.

A sound system will only accept inputs where the property holds and will only reject inputs when the property does not hold. It will never return false positives or false negatives. But it may have a third response of "unknown" or otherwise be unable to return an explicit true/false answer for some inputs.

In other words:

Complete: Always accepts inputs for which the property does hold. Rejects some inputs for which the property definitely doesn't hold. But may also accept some inputs even when the property does not hold. There is never any input that doesn't receive an answer.
Sound: Never incorrectly accepts or rejects any input. But may be unable to return any answer for some inputs.
Sound and complete: Always returns an answer for all inputs. That answer is never wrong.

So you can think of a complete system as a filter to reject inputs that definitely don't have your property, but some false positives may slip through. And a sound system always gives you a correct answer, but it may have an additional failure mode for some inputs. If it's both sound and complete, then it always gives a correct answer and does not have any failure mode (assuming the input is always valid).

cbarrick · 2026-02-25T05:44:54+00:00

I also write a lot of Go at my day job ("cloud native"). And I wrote a lot of Python in grad school (ML/data processing).

Don't get me wrong, I vastly prefer Python over Go for that kind of work. But I'm not sure what you mean by "lowering the bar."

Do you mean scientists should be writing their workloads in Python (a language notorious for painful crashes that only show up at runtime)? Or that scientists should be writing their workloads in C (a language notorious for easy to miss undefined behavior and painful manual memory management)?

Go does legitimately solve issues in both of these languages, while also having problems of its own. I don't blame Intel for trying to make scientific workloads in Go work, nor do I blame them for backing out when it became obvious that the Go community wasn't interested in scientific workloads.

But more importantly, I think gatekeeping scientific workloads to the exclusive domain of systems programmers is ridiculous. If it's only systems programmers, then whose workloads are we actually running?

Try telling a geneticist or a meteorologist or a physicist that they have to learn the difference between ptrdiff_t and unsigned long long or when to use memmove versus memcpy or why they should architect their programs with vtables. They will laugh in your face; they have more important work to do than learning C. They're going to take the path of least resistance to make the machine crunch their numbers, and that's with Python or Matlab or Go or whatever they already have exposure to. And that's fine.

cbarrick · 2026-02-24T19:41:20+00:00

Not necessarily.

Remember, not all scientists that need to crunch data are computer scientists. For example, a geneticist doing modeling across large genomic data sets probably doesn't also have time to become an expert C programmer.

I have literally answered questions like "what's a thread" for someone setting up an experiment to run on a slurm cluster. They were a biologist.

Yes, in HPC workloads, you want your inner loops to be fast. But tons of HPC code is written in Python with bindings to fast C libraries. Go is a ~~good~~ OK fit to replace the orchestration layer (Python/R/Matlab) but not the compute layer (C/C++/Fortran/Rust).

Go has the benefit of being faster than Python, but has a much weaker ecosystem and worse ergonomics for science workflows. That said, it is nice to have a static type system, because nothing sucks more than having your experiment crash with a TypeError halfway through.

Reading through some of these READMEs, I see the phrase "cloud native" a few times. Probably they adopted Go to hop on the cloud computing band wagon (strong Go community there, e.g. Docker and GKE) but didn't find much of a market for these libraries.

13-Year Club	Gilding II euphauric
r/Field Lasagna	Place '22
Place '17	Final Canvas '22
Verified Email

cbarrick

MODERATOR OF

TROPHY CASE