Right!? My mind teleported back to the TechTV era for a second.

Not to mention you can restrict who can file issues with permissions. So you have a forcing function, whereas hoping tags are correctly applied is a never ending battle.

> Author: frontend technical lead, setting high code standards

Haha, to be fair it's common to half-ass personal projects even if it's your primary domain.

Off-topic rant: I hate when websites hide the scrollbar. By all means, apply minimal styling to make it cohesive with the website background and foreground. But don't completely hide it.

This is included on that page's stylesheet:

    ::-webkit-scrollbar {
        width: 0;
        height: 0;
        display: none;
    }

Another reason to use Firefox, it doesn't respect that CSS :)

Timely! We're redesigning our blog, will keep you posted

You can definitely use this approach for large projects. No matter how big, at some point you are just reading a function or file. You don't need to read every single file to find bugs.

This can be combined with a more strategic approach like: https://mitchellh.com/writing/contributing-to-complex-projec...

Are there any enhancements that you've wanted to do, but haven't had the time?

I'm a huge fan, and am surprised how stable Monodraw has been for me. I've kept a single, growing document open as a scratch pad for the last three years. The only downtime was converting it to the new-ish file format haha.

The top two features I want to add next are table support and some form of auto layout (like flexbox).

I really care about stability and performance, so I’m happy to hear that it’s being appreciated.

There’s this layout library in C called clay which is basically a renderer agnostic flex box style layout engine. You might be interested in reading its source!

Yeah, there's a few such libraries that I'm aware of but I haven't had time to evaluate them. I do plan to at least look into them and make decision from there.

nucleic/kiwi uses the same algorithm that autolayout uses. It's also a tried and true implementation I've used many times, including in console environments.

Both would be sick! I do spend quite a bit of time making my own "tables" and re-arranging things.

Ha, I love the project name "Shadesmar". Journey before destination, friend. :crossed-wrists:

> because interface{} is always counted as escaped from the stack

Not quite - if the function accepting interface{} can be inlined (and other heuristics are groovy), then it won't escape.

Trivial example but it applies to real-world programs:

    > cat main.go
    package main
    
    import "github.com/google/uuid"
    
    func main() {
            _ = foo(uuid.NewString())
    }
    
    func foo(s any) string {
            switch s := s.(type) {
            case string:
                    _ = "foo:" + s
            }
            return ""
    }
    
    # Build with escape analysis
    > go build -gcflags="-m=2" main.go
    # command-line-arguments
    ./main.go:9:6: can inline foo with cost 13 as: func(any) string { switch statement; return "" }
    ./main.go:5:6: can inline main with cost 77 as: func() { _ = foo(uuid.NewString()) }
    ./main.go:6:9: inlining call to foo
    ./main.go:6:24: uuid.NewString() does not escape
    ./main.go:6:9: "foo:" + s does not escape
    ./main.go:9:10: s does not escape
    ./main.go:12:14: "foo:" + s does not escape

That makes sense.

I love my iPhone 13 Mini. Its only issues are battery life (now), and non-competitive camera. I'm personally happy with the photos it takes, but then I look at my girlfriend's shots and get FOMO.

While I doubt it's economical, I'd love a small, simple phone with juiced up camera. I'd be fine with worse battery life as external batteries can remedy that in a pinch.

I have a 12 mini, it's about as large a phone as I'd want. I wish the back and/or bezel were a little "grippier" as the phone as it's made is so slippery it almost demands a case, but that adds bulk.

Unlike many it seems, I don't care much about the camera. I'd probably want some sort of camera for scanning QR codes, or snapping a quick photo of something I want to look up later, but otherwise I don't take photos or videos on my phone. I don't use any social media on my phone other than text messaging. This makes the smaller battery size/capacity a non-issue.

Since Apple no longer makes a reasonably-sized phone I'll probably go back to Android after this one dies or becomes unsupported.

I also think it's silly to carry a $1,000 device around with you everywhere, so a "premium" small phone is probably a non-starter for me. My favorite phones were the ~$200 Moto-G phones I had before I got the iPhone (it was a gift).

I wish they made it thicker. It could easily fit better cameras and a bigger battery.