Readit News logoReadit News
coxley commented on Monodraw   monodraw.helftone.com/... · Posted by u/mafro
milen · 3 days ago
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.

coxley · 3 days ago
Both would be sick! I do spend quite a bit of time making my own "tables" and re-arranging things.
coxley commented on Monodraw   monodraw.helftone.com/... · Posted by u/mafro
milen · 3 days ago
Developer of the app here, happy to answer any questions.
coxley · 3 days ago
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.

coxley commented on Going faster than memcpy   squadrick.dev/journal/goi... · Posted by u/snihalani
coxley · 19 days ago
Ha, I love the project name "Shadesmar". Journey before destination, friend. :crossed-wrists:
coxley commented on Go allocation probe   scattered-thoughts.net/wr... · Posted by u/blenderob
fsmv · a month ago
It is very difficult to avoid putting strings on the heap in go. I used the built in escape analysis tools and made sure I only use a constant amount of memory in the loop in my short https://github.com/fsmv/in.go progress bar program.

The biggest problem is any string you pass as an argument to the fmt functions is moved onto the heap because interface{} is always counted as escaped from the stack (https://github.com/golang/go/issues/8618).

coxley · a month ago
> 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

coxley commented on I want an iPhone Mini-sized Android phone (2022)   smallandroidphone.com/... · Posted by u/asimops
GarnetFloride · a month ago
What was so odd was how Apple fumbled the iPhone mini launch by launching the iPhone SE first. At that point there hadn't been a small phone for a few years, There was pent up demand. The SE came out and it was a big success, lots of people wanted ti because it was a small phone.

Then few months later they launched the mini expecting it to sell even more or something. Somehow they missed that everyone that wanted a small phone had just bought the SE, and it just wasn't long enough for them to be worth upgrading to the much better mini.

Had they waited for a year to pass the mini might have done much better because those who wanted a more powerful phone could find an excuse for an upgrade after a year, less then 6 months, not so much.

coxley · a month ago
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.

coxley commented on The Evolution of Caching Libraries in Go   maypok86.github.io/otter/... · Posted by u/maypok86
coxley · 2 months ago
I've been using Otter for ~2(?) years, and it's a good time. This post made me realize we should upgrade to v2, as we've had a craving for async refresh.

Thanks to maypok86 for their dedication. The long comment threads on Ristretto issues are endlessly informative and entertaining. ;)

coxley commented on OpenTelemetry for Go: Measuring overhead costs   coroot.com/blog/opentelem... · Posted by u/openWrangler
coxley · 2 months ago
The OTel SDK has always been much worse to use than Prometheus for metrics — including higher overhead. I prefer to only use it for tracing for that reason.
coxley commented on Jokes and Humour in the Public Android API   voxelmanip.se/2025/06/14/... · Posted by u/todsacerdoti
coxley · 2 months ago
For many years at FB, suffixing dangerous or really-deprecated tokens with `_DO_NOT_USE_OR_YOU_WILL_BE_FIRED` was the standard. Everyone[^1] was in on the joke.

In the middle of the pandemic when ~50% of the workforce had started post-2020, it and other things became complaints for causing fear/uncertainty. We didn't do the best job on-boarding remote people and making them feel part of the culture at that time.

[^1]: It was a big company so this statement could only be true in the circles I had access to.

coxley commented on Plain Vanilla Web   plainvanillaweb.com/index... · Posted by u/andrewrn
coxley · 4 months ago
Thank you! This is the resource I've been wanting to hand-feed web components to me.

Looking forward to playing around with some personal projects. :)

coxley commented on Easier Layout with Margin-Trim   webkit.org/blog/16854/mar... · Posted by u/todsacerdoti
coxley · 4 months ago
This is awesome — but sucks that support isn't widespread yet.

u/coxley

KarmaCake day226January 17, 2016
About
https://coxley.org (sorry, my TTFB is atrocious) https://github.com/coxley https://linkedin.com/in/codey-oxley-15187555/
View Original