Svetlitski

When available I prefer installing applications via brew as casks, since at least this way if I decide to uninstall it later brew will take care of deleting all of these associated directories. I remember using an app called AppZapper several years ago which did this but for arbitrary applications. No idea if it’s still around/maintained.

Compression algorithms like Brotli already do this:

https://www.rfc-editor.org/rfc/rfc7932#page-28

The Itanium ISA was an infamous failure, never seeing widespread usage, hence people often referring to it as “The Itanic” (i.e. the much-touted ship that immediately sunk). The fact that anyone would be using it today at all is sort of hilariously niche, and is illustrative of how wide-ranging and obscure the issues filed to the GitHub repo could be. On a similar token I recall seeing an issue (or maybe it was a PR?) to fix our build on GNU Herd.

As of when I left Meta nearly two years ago (although I would be absolutely shocked if this isn’t still the case) Jemalloc is the allocator, and is statically linked into every single binary running at the company.

> Or I wonder if they could simply use tcmalloc or another allocator these days?

Jemalloc is very deeply integrated there, so this is a lot harder than it sounds. From the telemetry being plumbed through in Strobelight, to applications using every highly Jemalloc-specific extension under the sun (e.g. manually created arenas with custom extent hooks), to the convergent evolution of applications being written in ways such that they perform optimally with respect to Jemalloc’s exact behavior.

It’s just a huge pain to build and link against. Before the bazel 7.4.0 change your options were basically:

1. Use it as a dynamically linked library. This is not great because you’re taking at a minimum the performance hit of going through the PLT for every call. The forfeited performance is even larger if you compare against statically linking with LTO (i.e. so that you can inline calls to malloc, get the benefit of FDO , etc.)

2. Painfully manually create a static library. I’ve done this, it’s awful; especially if you want to go the extra mile to capture as much performance as possible and at least get partial LTO (i.e. of TCMalloc independent of your application code, compiling all of TCMalloc’s compilation units together to create a single object file).

When I was at Meta I imported TCMalloc to benchmark against (to highlight areas where we could do better in Jemalloc) by pain-stakingly hand-translating its bazel BUILD files to buck2 because there was legitimately no better option.

I understand the decision to archive the upstream repo; as of when I left Meta, we (i.e. the Jemalloc team) weren’t really in a great place to respond to all the random GitHub issues people would file (my favorite was the time someone filed an issue because our test suite didn’t pass on Itanium lol). Still, it makes me sad to see. Jemalloc is still IMO the best-performing general-purpose malloc implementation that’s easily usable; TCMalloc is great, but is an absolute nightmare to use if you’re not using bazel (this has become slightly less true now that bazel 7.4.0 added cc_static_library so at least you can somewhat easily export a static library, but broadly speaking the point still stands).

I’ve been meaning to ask Qi if he’d be open to cutting a final 6.0 release on the repo before re-archiving.

At the same time it’d be nice to modernize the default settings for the final release. Disabling the (somewhat confusingly backwardly-named) “cache oblivious” setting by default so that the 16 KiB size-class isn’t bloated to 20 KiB would be a major improvement. This isn’t to disparage your (i.e. Jason’s) original choice here; IIRC when I last talked to Qi and David about this they made the point that at the time you chose this default, typical TLB associativity was much lower than it is now. On a similar note, increasing the default “page size” from 4 KiB to something larger (probably 16 KiB), which would correspondingly increase the large size-class cutoff (i.e. the point at which the allocator switches from placing multiple allocations onto a slab, to backing individual allocations with their own extent directly) from 16 KiB up to 64 KiB would be pretty impactful. One of the last things I looked at before leaving Meta was making this change internally for major services, as it was worth a several percent CPU improvement (at the cost of a minor increase in RAM usage due to increased fragmentation). There’s a few other things I’d tweak (e.g. switching the default setting of metadata_thp from “disabled” to “auto”, changing the extent-sizing for slabs from using the nearest exact multiple of the page size that fits the size-class to instead allowing ~1% guaranteed wasted space in exchange for reducing fragmentation), but the aforementioned settings are the biggest ones.

At the risk of sounding overly harsh, I just don’t think this crate is a particularly good idea. I really do mean this as constructive criticism, so let me explain my reasoning.

A function being marked unsafe in Rust indicates that there are required preconditions for safely invoking the function that the compiler cannot check. Your “safe” function provided by this crate sadly meets that definition. Unless you take great care to uphold the requirements of async-signal-safety, calling your function can result in some nasty bugs. You haven’t made a “safe” wrapper for unsafe code like the crate claims, so much as you’ve really just traded one form of unsafety for another (and one that’s arguably harder to get right at that).

This is likely to violate async-signal-safety [1] in any non-trivial program, unless used with extreme care. Running code in between a fork() and an exec() is fraught with peril; it's not hard to end up in a situation where you deadlock because you forked a multi-threaded process where one of the existing threads held a lock at the time of forking, among other hazards.

[1] https://man7.org/linux/man-pages/man7/signal-safety.7.html

I'm quoting from the article, and wanted to be charitable by not adding a "[sic]"

> I think the big asterick to all of this design is that my ideal framework would not look like standard C++ but like a slightly weirder Rust stdlib

An interesting option in this space is rpp [1], which bills itself as a “Minimal Rust-inspired C++20 STL replacement”

[1]: https://github.com/TheNumbat/rpp

You can implement pipes via operator overloading in Python. Whether or not you should is a different question:

  class Pipe:
      __slots__ = ("value",)
  
      def __init__(self):
          self.value = None
  
      def __or__(self, x):
          return x(self.value)
  
      def __ror__(self, x):
          self.value = x
          return self
  
  v = Pipe()
  
  def double(x):
      return x + x
  
  def triple(x):
      return x + x + x
  
  pipeline_result = 3 + 7 |v| double |v| triple |v| double
  normal_result = double(triple(double(3+7)))
  assert pipeline_result == normal_result

I have a genuine question, intended in good faith: why? Why spend 10 years working on this, only to give it way for free?

While I don’t use it anymore and have been out of the web dev space completely for a few years now, I personally feel I owe a lot to Django. It’s the framework behind the first software I wrote that other people actually used and depended on. While looking back at it now the first Django code I wrote was pretty awful, it’s astonishing how much the framework lets you accomplish. Without knowing much at all about web development or databases, following the Django tutorial is sufficient to get you started with a very basic web app, and you can grow from there. Couple this with the superpower that was deploying to Heroku, and it made for a fantastic introduction to web dev and shipping software to real users.

This is unfortunate considering how far the language has come since then. Local variable type inference (i.e. the `var` keyword) is very difficult to give up once you’ve gotten used to this being table-stakes in basically every other modern statically typed language.

Turn off “Slide to Type” in the settings if you don’t use it. This appears to increase accuracy in my experience.

> This will lead to hard to read code

I’m curious to hear why you think this. What is it about duplicating the variable name that you feel makes the code clearer?

These things are everywhere in Manhattan; a few weeks ago there were so many it took concerted effort not to step on one on the sidewalk. They don’t appear to be particularly intelligent either, and as such the ground is littered with their dead bodies, crushed underfoot by pedestrians. It’s gross.

The only place I ever encountered these was in the computer labs in Soda Hall at Berkeley. They’re a great fit for an environment like that so there’s one machine for each person without needing the extra space for a traditional tower. But I imagine outside of situations like this where you need something that’s not locked down for programming, Chromebooks have probably taken the lion’s share of the education market.

Starting with Ice Lake there’s support for 5-level paging, which increases this to 128 PiB. Can’t say that I’ve ever seen this used in the wild though.

Clang provides the "musttail" attribute for C and C++:

https://clang.llvm.org/docs/AttributeReference.html#musttail

I can’t help but ask, why “,notify” and not just “notify”?

I cannot help but think of the novel “A Fall of Moondust” by Arthur C. Clarke.