162 lines
7.6 KiB
Plaintext
162 lines
7.6 KiB
Plaintext
% id = "01HBTSXTTAAAHGKD4TZZW14KFK"
|
|
- "bad opinion zone"
|
|
|
|
% id = "01HBTSXTTAMWJ2BM6395YS72FN"
|
|
+ log verbosity levels are stupid
|
|
|
|
% id = "01HBTSXTTA946PJ04NN50P393T"
|
|
- because when should you use any log level other than `error`, `warn`, or `info`?
|
|
|
|
% id = "01HBTSXTTAA873BYW2X3499W4P"
|
|
- for debug info that doesn't affect most users, there will always be lower verbosity levels
|
|
than `info`, but in my experience these are *always* extremely specific, and clumping them
|
|
all into `debug` or `trace` doesn't make much sense
|
|
|
|
% id = "01HBTSXTTAQ9S7Q1SSPN0BCG8F"
|
|
+ in that case I believe it is better to declare separate channels that can be filtered individually, and use `info` for everything
|
|
|
|
% id = "01HBTSXTTAHCQ5YH1FZT3WKNTZ"
|
|
- you say `info` sounds wrong for debug info? well,
|
|
|
|
% id = "01HBTSXTTATA4GW13QBC8YMWP1"
|
|
- guess what, it's debug ***info***
|
|
|
|
% id = "01HBTSXTTANNMHXDGG1M4W70XN"
|
|
- the very concept of logs is to dump a load of (debug) info for later analysis,
|
|
so making some distinction between debug and non-debug info while logs are
|
|
_inherently_ for debugging seems a little silly to me
|
|
|
|
% id = "01HBTSXTTADJCTV9RTWT4NPASS"
|
|
+ use severities instead of verbosities
|
|
|
|
% id = "01HBTSXTTA3KN26DS4QMPSHEEC"
|
|
- `error` is "OH SHIT OH FUCK UHHH"
|
|
|
|
% id = "01HBTSXTTATK9W0TRGM50SKWRE"
|
|
- `warn` is "ding ding ding! something ain't right, but I'll carry on"
|
|
|
|
% id = "01HBTSXTTA8Z5JJHFKH4T88G0B"
|
|
- `info` is just that - info
|
|
|
|
% id = "01HBTSXTTANQXBN7FQQSBXTSB1"
|
|
- and there is really no need for anything lower, because guess what: [`debug` and `trace`](https://docs.rs/tracing/latest/tracing/struct.Level.html)
|
|
and [`Display` and `Verbose` and `VeryVerbose`](https://docs.unrealengine.com/4.26/en-US/API/Runtime/Core/Logging/ELogVerbosity__Type/)
|
|
and what have you - they're all just more `info` for you
|
|
|
|
% id = "01HBTSXTTAE94HEE60GZFBEAW7"
|
|
- and while writing logging code it's always hard to decide which info should be
|
|
stuffed into which verbosity, because which info will be interesting to you at the
|
|
time you read logs depends on what you're looking for at a given moment
|
|
|
|
% id = "01HBTSXTTAKZ3MKD3EJPX84J9N"
|
|
+ this is something I haven't tried yet, but one day I wanna build a logging framework one day that associates severities with whole categories rather than individual log messages
|
|
|
|
% id = "01HBTSXTTAD4TQ0A8JP71KZMXA"
|
|
- but at that point, do we even need severities at all? would a hierarchy of categories suffice?
|
|
|
|
% id = "01HBTSXTTAW160GH44JV3JYV3Y"
|
|
- I have no clue how well that will work but it would be pretty interesting
|
|
|
|
% id = "01HBTSXTTASQDZK2HMCZXR3JJ4"
|
|
+ tracing is better than logging
|
|
|
|
% id = "01HBTSXTTA08SCA313HSFWB13T"
|
|
- information about time spans is very valuable for profiling
|
|
|
|
% id = "01HBTSXTTAAHQ0Q8GY78Z1RYFN"
|
|
- and you do not have to worry about "should I log before I start the operation, or after I end the operation?"
|
|
|
|
% id = "01HBTSXTTAJ6R319P2N6HT54CA"
|
|
+ additionally, traces made of spans are way easier to visualize than tonnes of logs
|
|
|
|
% id = "01HBTSXTTA3M93STVPHA898GM4"
|
|
- if you've never tried [Perfetto](https://ui.perfetto.dev/) or similar tools, I highly recommend giving it a shot
|
|
|
|
% id = "01HBTSXTTAB9WD17FNDE5RYP8Y"
|
|
+ I also imagine visualizing traces live in your CLI could yield a very nice user experience,
|
|
with a visible progress indicator as to what eg. [your compiler][branch:programming/projects/muscript]
|
|
is working on right now at a glance, reassuring you that it is not stuck on some
|
|
`while (true) {}` in constant evaluation
|
|
|
|
% id = "01HBTSXTTA3Q36Y98GSBRVCS3B"
|
|
- perhaps emitting warnings along the road for things that take alarmingly long, so that you
|
|
can keep your build times in check
|
|
|
|
% id = "01HBTSXTTAA89CXD17GBNR3FEQ"
|
|
- though printing to stdout is quite slow, so perhaps limiting the frequency or depth would
|
|
be a worthwhile thing to do
|
|
|
|
% id = "01HCD90XT3G0J8G9Y48H5QT1GJ"
|
|
+ don't use [`RefCell<T>`](https://doc.rust-lang.org/std/cell/struct.RefCell.html)
|
|
|
|
% id = "01HCD90XT3X82R37WTJJABZF4Y"
|
|
+ usually if you have to resort to `RefCell<T>`, it means something is wrong with your architecture
|
|
|
|
% id = "01HCD90XT3QQA9MCB77Q04W148"
|
|
- `Cell<T>` less so but still you should avoid it whenever possible
|
|
|
|
% id = "01HCD90XT36Q0WTZNRCEWZQE1X"
|
|
- `Rc<RefCell<T>>` is an immediate red flag when I read someone's code. it means they don't
|
|
really know what they're doing and are just trying to sidestep the language
|
|
|
|
% id = "01HCD90XT3QNZ7H77Z4QMW66QJ"
|
|
- it's really not that hard to avoid, try bumping your resources up a scope and borrow them
|
|
from there
|
|
|
|
% id = "01HCD90XT32M4F61W5QRRRXG0K"
|
|
+ using `RefCell` has a few disadvantages
|
|
|
|
% id = "01HCD90XT3R214HQM03TSRZV6K"
|
|
+ first, `RefCell` is _literally_ turning off the borrow checker
|
|
|
|
% id = "01HCD90XT3V4K4RKRQXX5BCCRB"
|
|
- or really deferring it until runtime, but then what's the point. Rust's borrowing
|
|
rules are meant to prevent bugs, not cause more of them
|
|
|
|
% id = "01HCD90XT3DVTHP82Z5NAAF7RP"
|
|
+ second, your program can now panic in unexpected places, because it turns out runtime
|
|
borrows can be really hard to predict
|
|
|
|
% id = "01HCD90XT34QD8MCN0BA35AV0F"
|
|
- as evidenced by a random crash I once got while using [druid](https://lib.rs/crates/druid)
|
|
which was caused by a overlapping mutable then immutable borrows at runtime
|
|
|
|
% id = "01HCD90XT39NZ0BSY630MFNG1X"
|
|
- therefore maybe uhhh... don't use it in libraries? :pleading:
|
|
|
|
% id = "01HCD90XT3GT9G16EQDAK76WEC"
|
|
+ third, it incurs a runtime overhead for the borrow checking, which in 99% of cases is
|
|
totally unnecessary
|
|
|
|
% id = "01HCD90XT3V3B1TVPX7GS8SPDQ"
|
|
- (this is more about non-pessimization rather than premature microoptimization, so
|
|
don't yell at me with your "it'll be fast enough" arguments please)
|
|
|
|
% id = "01HCD90XT37138S38DN0V3DKHF"
|
|
+ fourth, and this one is extremely easy to spot - your code becomes really verbose!
|
|
|
|
% id = "01HCD90XT3WNGWD4GA2Y63D42H"
|
|
- yes please, `.borrow()` me everywhere!
|
|
|
|
% id = "01HCD90XT361QQB2YNFBY51N2A"
|
|
- and you end up with lots of temporaries because of the [`Ref<'b, T>`](https://doc.rust-lang.org/std/cell/struct.Ref.html)
|
|
guards you have to keep in scope.
|
|
|
|
% id = "01HCD90XT34K9BREXAKA5FFP3M"
|
|
- remember that you cannot do `&ref_cell.borrow().some_field` because that would
|
|
drop the temporary `Ref<'b, T>` guard after the expression ends
|
|
|
|
% id = "01HCG7KTGGAFS07QYJXZG6WHJJ"
|
|
+ `None` or `Invalid` cases in enums are a bad idea
|
|
|
|
% id = "01HCG7KTGGHWTT1ME9GQ5VPFPR"
|
|
- by having them, you're forcing your users into an API that forces them to think about the
|
|
invalid case every time they read the value.
|
|
|
|
% id = "01HCG7KTGGBJRX5JGQTFD59P4W"
|
|
- you're repeating the million dollar mistake - `null`
|
|
|
|
% id = "01HCG7KTGGYQ8EQB97AMFJPWYK"
|
|
- instead, use an explicit `Option<T>` or `std::optional<T>` or `T?` or ... when you need
|
|
to represent a possibly-invalid case
|