oops typo
This commit is contained in:
parent
866fe408e4
commit
1391dcd4ab
2 changed files with 46 additions and 3 deletions
40
content/posts/debuggers-really.md
Normal file
40
content/posts/debuggers-really.md
Normal 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
|
||||
|
|
@ -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
|
||||
illustrated in the type signatures of the operations of Monad and Applicative:
|
||||
|
||||
* `apply :: Applicative f => f (a -> b) -> a -> f b`<br/>
|
||||
which means that something *outside* the `f` box can be put into a
|
||||
computation `a -> b` inside the box.
|
||||
* `apply :: Applicative f => f (a -> b) -> f a -> f b`<br/>
|
||||
which means that a value inside a box can be passed into a pure
|
||||
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/>
|
||||
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
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue