programming/opinions

“bad opinion zone”
log verbosity levels are stupid
- because when should you use any log level other than error, warn, or info?
  - 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
    in that case I believe it is better to declare separate channels that can be filtered individually, and use info for everything
    you say info sounds wrong for debug info? well,
    guess what, it’s debug info
    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
  - use severities instead of verbosities
    error is “OH SHIT OH FUCK UHHH”
    warn is “ding ding ding! something ain’t right, but I’ll carry on”
    info is just that - info
    and there is really no need for anything lower, because guess what: debug and trace and Display and Verbose and VeryVerbose and what have you - they’re all just more info for you
    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
- 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
  - but at that point, do we even need severities at all? would a hierarchy of categories suffice?
  - I have no clue how well that will work but it would be pretty interesting
tracing is better than logging
- information about time spans is very valuable for profiling
- and you do not have to worry about “should I log before I start the operation, or after I end the operation?”
- additionally, traces made of spans are way easier to visualize than tonnes of logs
  - if you’ve never tried Perfetto or similar tools, I highly recommend giving it a shot
- 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 is working on right now at a glance, reassuring you that it is not stuck on some while (true) {} in constant evaluation
  - perhaps emitting warnings along the road for things that take alarmingly long, so that you can keep your build times in check
  - though printing to stdout is quite slow, so perhaps limiting the frequency or depth would be a worthwhile thing to do
don’t use RefCell<T>
- usually if you have to resort to RefCell<T>, it means something is wrong with your architecture
  - Cell<T> less so but still you should avoid it whenever possible
  - 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
- it’s really not that hard to avoid, try bumping your resources up a scope and borrow them from there
- using RefCell has a few disadvantages
  - first, RefCell is literally turning off the borrow checker
    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
  - second, your program can now panic in unexpected places, because it turns out runtime borrows can be really hard to predict
    as evidenced by a random crash I once got while using druid which was caused by a overlapping mutable then immutable borrows at runtime
    therefore maybe uhhh… don’t use it in libraries? :pleading:
  - third, it incurs a runtime overhead for the borrow checking, which in 99% of cases is totally unnecessary
    (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)
  - fourth, and this one is extremely easy to spot - your code becomes really verbose!
    yes please, .borrow() me everywhere!
    and you end up with lots of temporaries because of the Ref<'b, T> guards you have to keep in scope.
    remember that you cannot do &ref_cell.borrow().some_field because that would drop the temporary Ref<'b, T> guard after the expression ends
None or Invalid cases in enums are a bad idea
- 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.
  - you’re repeating the million dollar mistake - null
  - instead, use an explicit Option<T> or std::optional<T> or T? or … when you need to represent a possibly-invalid case