shabbyrobe

That's not what I found in my own experiments, I still had to unmarshal once inside the callback to get the `type` field out, then again once I knew what the type was. Do you have an example handy?

IME this is a longstanding pain point with Go. There's an attempt to propose an encoding/json/v2 package [1] being kicked around at the moment [2], spawned from a discussion [3].

This at least seems to improve the situation of marshalling to/from an interface directly slightly by providing the ability to pass custom Unmarshalers for a specific type (via json.WithUnmarshalers and json.UnmarshalFunc) to the Unmarshal functions, but it appears to still have the inefficient double-decode problem. Or I just haven't found a decent way around it yet.

Looks like they're intentionally punting on a first class solution until (if) the language gets some sort of sum type, but I still think the second-class solution could do a bit more to make this extremely common use-case more convenient. Pretty much every serious production Go app I've worked on in the last 10 years or so has had some horrible coping strategy for the "map a field-discriminated object to/from implementations of an interface" gap, often involving some sort of double-unmarshal.

Quote from the proposal [1]:

First-class support for union types: It is common for the type of a particular JSON value to be dynamically changed based on context. This is difficult to support in Go as the equivalent of a dynamic value is a Go interface. When unmarshaling, there is no way in Go reflection to enumerate the set of possible Go types that can be stored in a Go interface in order to choose the right type to automatically unmarshal a dynamic JSON value. Support for such use cases is deferred until better Go language support exists.

  [1]: https://pkg.go.dev/github.com/go-json-experiment/json
  [2]: https://github.com/golang/go/issues/71497
  [3]: https://github.com/golang/go/discussions/63397

Such an instrument is the turbo encabulator.

I would've probably picked the modernc variation

Heads up about the modernc library, it has been stuck on an old version of sqlite for several months [1]. It seems like maintainer time is the limiting factor [2]. There has been a call to arms on that issue page, the maintainer is looking for help, but it looks like not much has arrived. It seems like it might trace back to blockers in the C-to-Go compiler.

It's a major undertaking and a very impressive piece of work, but I'm not surprised it's a struggle when big roadblocks get hit. I hope they find a way to progress, but I'm very relieved to be seeing some CGo-free alternatives like ncruces/go-sqlite3 emerging. I'm going to give it a try for sure and see if I can live with the compromises.

Squinn-go looks very compelling too, but I don't like that it requires the squinn binary to already be installed on a user's machine, I think that gives with one hand and takes with the other: sure, I get to avoid CGo, but I also lose the turnkey, single-command install, static build benefits Go brings out of the box.

Seconding the point about nitty gritty, I'd read it for sure too!

  [1]: https://gitlab.com/cznic/sqlite/-/issues/154
  [2]: https://gitlab.com/cznic/sqlite/-/issues/164

I love this visualisation. Is the script to generate it publicly available?

Since PEP 591 [1], if using mypy with Python 3.8+ or the typing_extensions module, you can also take advantage of typing.Final, which lets you statically verify something isn't changed. The catch is that it isn't enforced at runtime.

  [1]: https://www.python.org/dev/peps/pep-0591/

There are fragments of discussion about the download timeout throughout the issue tracker, which end up leading back to this still-open but seemingly forgotten issue about adding InactivityTimeout: https://github.com/golang/go/issues/22982

I'd love to see this one addressed but it's not looking too hopeful at this stage.

I think it could be the same but it doesn't have to be. "What problem does this solve" is a bit more generous as at least, on the face of it, it may offer an opportunity to provide an answer that will be received in good faith.

But I think this is less about specific phrases one might need to be careful not to say, and more about the kinds of default attitudes that can turn into ongoing impediments to the free flow of ideas. It's definitely possible ask "what problem does this solve" without becoming the "What Problem Does This Solve Person", and the same goes for the other phrases too.

There's also the "That Won't Work" person's sibling: the "I Don't See a Use Case" person. In my experience, "I Don't See a Use Case" people require more sophisticated tactics if you actually want to get something done while they're around, not least of all because they move the game to a harder field: "that won't work" at least states a fact, whereas "I don't see" moves us firmly into "belief" territory, and "a Use Case" invites us into the trap of dreaming up our own strawmen for them to tear down one by one.

I wonder if they started out as "That Won't Work" people, but evolved better defenses?

Here's another fun one: https://github.com/git-lfs/git-lfs/issues/2434

Git on Windows client corrupts files > 4Gb

It's apparently an upstream issue with Git on Windows, but if you depend on something, you inherit its issues.

I really didn't enjoy the game with the biters turned on, but absolutely loved it when I switched to peaceful mode. There are enough problems to sort out without them, like "why do I suddenly not have enough iron plates", or "why do I suddenly not have enough copper plates", or my personal favourite, "why do I suddenly not have enough iron plates again"!

iTerm2 is fantastic! It can be a bit CPU hungry but you get a stack of mod cons out of the bargain.

There are tons of proprietary escape codes, not least of all the incredibly useful one for "fireworks"! [1]

    ^[]1337;RequestAttention=fireworks^G

Indeed! Even the Go wiki advocates exactly what you're saying about looking at the tradeoffs: https://github.com/golang/go/wiki/MutexOrChannel

I find it kinda strange that Flow has been relegated to the write-in "Other Flavours" section so soon. I know that it has been trending downwards for a while (as TypeScript trends upwards), but it feels like that story's not quite over just yet even if the conclusion is foregone.

Which bits of telemetry can't be opted out of? I've set at least a hundred things in my about:config to tamp down on it but I'm never quite sure I've got all of them.

The author of this post is also the author of the fantastic "Visualizing Concurrency in Go" [1] article.

[1] https://divan.dev/posts/go_concurrency_visualize/

The file is liberally annotated with explanatory comments though. It's really useful if you want to cherry-pick the things that matter to you.

Also, things might get a bit weird when you enter this 16-digit... uhh... "invoice number": 9007199254740992.

It's not really fixed though. When using vim-go with gopls, I see extortionate memory and CPU usage relative to what gocode used to use, and glacial lookup times compared to what gocode used to offer. Maybe it's perfectly adequate for you, and if so that's great! But that has not been my experience. Neither gopls nor any of the dozen forks of gocode I've tried since 1.11 has come close to the pre-modules experience for speed, accuracy and acceptable resource usage.

I tried to use the profiling flags to get some data to file reports, but ran out of yak-shaving time when I realised was trying to flush out a bug in the tool command helpers in golang/go where it would write empty profiles if the process was shut down the exact way vim was shutting it down. That may have been fixed since, I haven't had a chance to look back into it.

Which is, of course, totally unacceptable. This is a critical use case for doing deep-dive debugging or for code exploration. Fortunately for us there is the wonderfully named "gohack", which does easily expose your deps for editing (though not as easily as before): https://github.com/rogpeppe/gohack

Complaining about JS Fatigue is just like complaining about the fact that humanity has created too many tools to solve the problems we have, from email to airplanes and spaceships.

No, complaining about JS Fatigue is just like complaining that we should actually try to launch a spaceship instead of tearing the last one we started into pieces just so we can put some shiny new thing in the middle of it, and that we should try to actually finish an airplane and send an email while we're at ooh React Hooks! Hang on, I really need to start my post again and do it perfect this time now that it's possible. Bear with me a sec, trust me I'll be finished soon, hopefully you still have enough money to pay me.

Jonathan Swift in 1710:

"Falsehood flies, and truth comes limping after it, so that when men come to be undeceived, it is too late; the jest is over, and the tale hath had its effect: like a man, who hath thought of a good repartee when the discourse is changed, or the company parted; or like a physician, who hath found out an infallible medicine, after the patient is dead."

... which is a form of questioning why it's present. "Attempting to change it" in this situation is more like "submitting the pull request[1]" than "editing the code". The PR tends to only come together after one or more rounds of "git stash, try again".

[1]: or merging your branch, if you're solo.

It could just be that the devs on a team don't know how to use those tools yet. Having to learn how to use TypeScript effectively while establishing the patterns that underpin a new project would definitely slow you down. Maybe that's a cost you can bear early on, but maybe it isn't.

You can actually propagate errors from it. It's not pretty but it works:

    func Pants() (rerr error) {
        defer func() {
            if err := doStuff(); err != nil && rerr == nil {
                rerr = err
            }
        }()
        // ...
        return nil
    }

    func DeferClose(err *error, closer io.Closer) {
        cerr := closer.Close()
        if *err == nil && cerr != nil {
            *err = cerr
        }
    }

    func Pants() (rerr error) {
        f, _ := os.Open(...)
        defer errtools.DeferClose(&rerr, f)
        // ...
        return nil
    }

I'm using a bunch of other extensions and customisations, so I guess there's some dodgy interaction going on somewhere. No time to go spelunking though. I'll just use it on my desktop instead, where I won't notice the load.

I just gave it another try. Unfortunately, things haven't improved. `about:performance` shows a "medium" energy impact for TST. My 2015 Macbook's fans come on and stay on until I disable TST again, after which they reliably spool back down after a short delay. While TST is enabled, Firefox shoots up the list of CPU users in Activity Monitor.

Oh well, it was worth a shot, sidebar tabs are just so good when they're working well, but it's not worth the battery drain.

Your userChrome.css tweaks worked great!

Thank you for providing this detail, I used to use tree tabs before the webextensions fiasco but hadn't gone back to it yet as I wasn't aware it was possible to hide the existing tab bar. I'll definitely give it another shot now thanks to your help!

The last time I tried TST, it was fairly hostile to my battery on macOS; is that still a problem?

Sidebar tabs are a massive workflow upgrade, it surprises me that it's not a core browser feature, especially now with the ridiculous proliferation of those loathsome vertical-space hostile sticky elements that have spread through the web like a plague.

Wow, I'd love to hear more about this.

I've always been curious about the characters in ASCII for this, but I've never seen them used in the wild. Stuff like "Group Separator" (0x1D), "Record Separator" (0x1E) or "Unit Separator" (0x1F)

Is there a reason why nobody uses these? Did someone work out back in the 90s they were pure evil and we've just never used them since?