oops typo

This commit is contained in:
Jade Lovelace 2023-04-03 15:22:34 -07:00
parent 866fe408e4
commit 1391dcd4ab
2 changed files with 46 additions and 3 deletions

View file

@ -0,0 +1,40 @@
+++
date = "2023-04-02"
draft = true
path = "/blog/debuggers-really"
tags = ["debugging"]
title = "Our debuggers are awful"
+++
* Working on otel for rust
* Have to vendor several things to get http request logs
* Why are browsers the only things that you can dump http request logs from
* Why can't I dump a http/2 protocol trace from h2 in rust?
* This isn't a tracing problem
* Tracing is designed to not leak customer data
* Tracing is generally a metadata thing, *not* a data thing
* Tracing needs instrumentation and seeing the possibility of a problem
ahead of time
* What is a futuristic debugger, anyway?
* Integrate with rr
* Attach to a running system
* Has no overhead while not in use
* Can get information out of a system which has not yet been instrumented
* So thats just dtrace
* Yes kinda! But there's not enough instrumentation
* I can't dump the request logs into browser devtools (e.g. with a .har
file)
* Rust ecosystem does not really have deep dtrace integration
* Debugging a system is too important to disturb it
* Debugging a system is too important to care about module privacy
* Sidebar: "realness"
* When we build systems, we tend to treat the user . . . patronizingly, or
at least specially
* Database schemas with cursed tag-value schemas rather than dynamic
schemas
* Lowering things into a worse value representation that's different than
host-language objects
* Cannot introspect objects while ignoring module privacy, even though you
could exactly do this given ctf data
* RUSTC_BOOTSTRAP

View file

@ -52,9 +52,12 @@ only take in things that are known statically; in Bazel it is thus common to
check in generated build instructions. This property in category theory is check in generated build instructions. This property in category theory is
illustrated in the type signatures of the operations of Monad and Applicative: illustrated in the type signatures of the operations of Monad and Applicative:
* `apply :: Applicative f => f (a -> b) -> a -> f b`<br/> * `apply :: Applicative f => f (a -> b) -> f a -> f b`<br/>
which means that something *outside* the `f` box can be put into a which means that a value inside a box can be passed into a pure
computation `a -> b` inside the box. computation `a -> b` inside a box. This is less powerful than `bind`, since
unlike `bind`, the function you provide cannot use the "a" it got to create
new operations involving boxes: this means that the build graph of an
Applicative build system is static.
* `bind :: Monad m => m a -> (a -> m b) -> m b`<br/> * `bind :: Monad m => m a -> (a -> m b) -> m b`<br/>
which means that if you have a value of type `a` in a `m` box, you can *get which means that if you have a value of type `a` in a `m` box, you can *get
the `a` out of the box* and create a further computation in a box depending the `a` out of the box* and create a further computation in a box depending