remexre

> it has got the right top eight instructions that you actually need to optimize for

I wonder which ones he considers those to be -- the interview doesn't say, sadly...

Automattic, the developers of Wordpress, currently own Tumblr.

Send and Sync are the keywords to search for.

CHERI is insufficient for unsafe Rust to be fully safe, and I suspect Fil-C plus C's restrict is insufficient as well (if restrict isn't treated as a no-op, of course).

For unsafe Rust code to be sound, it has to uphold the invariant that no location pointed to by an &mut is modified through a pointer not derived from that &mut. However, there's no such restriction on *mut pointers ("raw pointers"), and it is in many cases perfectly sound (but unsafe, of course) to cast from *mut to &mut, or to directly mutate through a *mut. Without maintaining global information about what references are live, it sounds really, really hard to guarantee this.

Which one(s) are you thinking of? The JVM's appear to be in C++, GHC's and SBCL's are in C, Go's is in Go, and I'm not familiar with other high-performance garbage-collected platforms.

Use-cases like "implementing a garbage-collected language."

For example, not telling people to eat glue just because Reddit suggests eating glue could be considered a safety measure...

ZFS is the mechanism by which I implement local (via snapshots) and remote (via zfs send) backups on my user-facing machines.

- It can do 4x 15-minute snapshots, 24x hourly snapshots, 7x daily snapshots, 4x weekly snapshots, and 12x monthly snapshots, without making 51 copies of my files.

- Taking a snapshot has imperceptible performance impact.

- Snapshots are taken atomically.

- Snapshots can be booted from, if it's a system that's screwed up and not just one file.

- Snapshots can be accessed without disturbing the FS.

In my experience it hasn't required more hand-holding than ext4 past the initial install, but the OSes that most of my devices use either officially support ZFS or don't use package managers that will blindly upgrade a kernel past what out-of-tree modules I'm using will support, which I think fixes the most common issue people have with ZFS.

snapshots every 15 minutes are a big selling point of ZFS for me; losing a file to a tired

    $ grep bar foo.txt | tr A-Z a-z > foo.txt

is much more common than losing a disk

Templates already provide that useful polymorphism;

    template<typename T>
    T callWithState(auto f) {
        auto old = globalState;
        globalState = whatever();
        T out = f();
        globalState = old;
        return out;
    }

(forgive any syntax errors, my C++ is very rusty...)

Kinda funny, given that the Haskell iterator solution is "convert your data to be a list, and the optimizer and RTS will do the right thing as if it were an iterator."

At 1:27, "So then, you can ask, why didn't [Apple and AWS] choose Coq, Lean or Agda [instead of Isabelle/HOL]?"

My understanding (having only used dependent-types -family interactive theorem provers) is that if your property can be expressed in HOL, proving it will require far less human effort to prove than Coq or similar.

Yeah, I won't argue that there aren't some domains where you have soft real-time requirements, and need the language to allow you to do things like that. Reddit's app server isn't that, though.

Separately, my gut feeling is that in 2024, programming language runtime technology is advanced enough that manually reusing buffers isn't necessarily a good use of hours-spent-optimizing. To pick on Python in particular, it _does_ actually reuse buffers when they only have a single owner; more languages might get this in the future via the Perceus refcounting work?

Common Lisp's string support certainly feels like it comes from a world where allocating memory is expensive, and something the programmer should be aware of, and have the option to reuse buffers instead of allocating additional memory...

It has 201 direct dependencies, making it the 9th most directly-depended-on system in Quicklisp, one spot ahead of UIOP.

Methodology (yes, I could've stayed in Lisp, but I started by awking systems.txt...):

    (with-open-file (*standard-output* #p"deps.txt" :direction :output)
      (iter
        (for system in (ql:provided-systems t))
        (for name = (ql::name system))
        (format t "~a ~a~%" (length (ql:who-depends-on name)) name)))

    $ sort -h deps.txt | tail
    200 uiop
    201 iterate
    206 split-sequence
    274 closer-mop
    344 cl-glfw-opengl-core
    350 bordeaux-threads
    387 fiveam
    391 cffi
    408 cl-ppcre
    1006 alexandria

In what sense is iterate a fad that was gone? I see 1161 systems in Quicklisp (out of 5499 total) that transitively depend on iterate; so about a fifth of the open-source ecosystem.

Most flakes make it a pain to cross-compile, too, especially to platforms other than the "big four" ({aarch64,x86_64}-{linux,macos}), as compared to overlays.

(That said, the tooling around flakes is so much nicer that I still use and recommend them.)

Are you sure they're not talking about code size? Not sure what limiting instantiations would have to do with heap size...

(I also find it surprising that avoiding floats helps anything; maybe just in avoiding more instantiations? Because if the std floating point functions don't fully inline, you've got bigger problems than wasm blob size...)

LLVM breaks backwards compatibility all the time, though...

And, perhaps also relevantly, your compute kernel probably fits in iCache, even with VLIW instructions.

Have you seen/considered the work on staged programming? Something like [0], while thorny, seems like a reasonable stab at it.

[0]: https://okmij.org/ftp/tagless-final/TaglessStaged/beyond-tal...

"link the Boehm GC" got one line on an assignment in my University's compiler's course; it's literally a matter of changing

    exec ["ld"; "-o"; out_file; obj_file]

to

    exec ["ld"; "-o"; out_file; obj_file; "-lgc"]

...

I think the concern was all the buggy apps that connect to databases will accidentally be getting SQL injected.

Wouldn't the hand-written one be more work to write and measurably slower than the re2c-generated one?

There's also https://docs.rs/allocator-api2/latest/allocator_api2/ -- I end up using this more often than I end up using custom allocators, simply because it has a stable version of the currently-unstable functions for constructing uninitialized Vec<MaybeUninit<u8>>s.

Rust uses the C compiler as a linker, because this is often the only way to ensure all the libraries needed by the system toolchain are included. (Compare to the CCLD variable in autotools -- it refers to the command to use the C compiler as a linker, and exists for this very reason.)

This isn't only libc -- it also includes libgcc (or compiler-rt, depending on your system toolchain), which, despite the name, may still be called "behind your back" by the LLVM toolchain.

> So it's a Rust program but it's just calling inline assembly and using a C compiler?

Yeah, I think this article is more in the tradition of [0] (but trying hard not to drop rustc) than being completely practical advice on making the binary you ship to users smaller.

[0]: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.htm...

For straight-line code, something like

    %2 <- foo %0 %1
    ...

is effectively equivalent to

    (foo %0 %1 (lambda (%2)
      ...)

Phis are sorta modeled inversely:

    %1:
        %2 <- const 0
        br %5
    %3:
        %4 <- const 1
        br %5
    %5:
        %6 <- phi [%1 -> %2, %3 -> %4]
        ...

becomes:

    (letrec ((%1 () (const 0 (lambda (%2) (%5 %2))))
             (%3 () (const 1 (lambda (%4) (%5 %4))))
      (%5 (%6) ...))
      ...)

The nice thing on paper about both of these is that you've broken every computation down into nice nameable bits; if you want to do some analysis (e.g. abstract interpretation) over the programs, you can store intermediate results as a map from names (like %4) to values.

The traditional downside of CPS is that requiring lambdas be nested in order for things to be in scope can make some program transformations require "reshuffling" terms around in a way SSA doesn't require.

The "cps soup" [0] approach used in Guile fixes this, but your terms look like they violate lexical scoping rules!

[0]: https://wingolog.org/archives/2015/07/27/cps-soup

Family income is easier to game than community income though?