maxpolun

I don't tend to believe people who say that everyone working in a particular field are crazy and stupid. Wrong maybe. Whole fields are wrong all the time. But not because they're all crazy and stupid.

You can have multiple threads with coroutines. However you generally only have one thread per CPU/hardware thread, and use async io within that thread.

This is the general architecture of nginx for example (though it doesn't use coroutines, just callback based async io).

I wonder what the performance difference is when you're actually handling the errors though. I'd imagine that

    try {
       doThing();
    } catch (Exception1 e) {
        handleError1();
    } catch (Exception2 e) {
        handleError2();
    } catch (Exception3 e) {
        handleError3();
    }

Might be slower than

    Error err = doThing();
    if (err.code === ERROR1) {
        handleError1();
    } else if (err.code === ERROR2) {
        handleError2();
    } else if (err.code === ERROR3) {
        handleError3();
    }

Exceptions are best in my mind when they are very coarsely-grained, and error-codes best when you need to handle very fine-grained errors. This is certainly true in the code ergonomics, but I'd be interested in seeing if it's true for performance as well.

A lot of people will recommend reading great code -- well known open-source libraries etc. That's good, but one thing I think is useful is to read your dependencies. Then you can get a better picture of what "regular" code is like. Most popular libraries are not great to read because they are often very abstract, or they use so much helper code that it's hard to see what's actually going on. But fairly small libraries are usually easy to understand and usually are also fairly straightforward, but by reading code you'll be able to put yourself in the shoes of someone who will be reading your code one day, which is the most important things to keep in mind.

I'm mainly a front-end developer, and the nice thing about the npm/node ecosystem is all of your dependencies are right there in node_modules, so feel free to read them to see how they work, or why something isn't doing what you expect -- you can even add debugger statements or console.logs.

In some ecosystems this is harder because you might have to hunt for the source, or only have headers. For example in ruby, use bundle show my_dependecy to see where the code is stored.

I think they're just being very strict about what counts as breaking. They gave the example of upgrading the typescript compiler they use as breaking.

Rust has overflow checking in debug mode, but release mode does not have any overflow checking. The thinking here is that you'll hopefully catch most of your overflows while testing the app, but get no performance penalty in production use.

If you want to overflow there are special types that you can use.

Modern JS does allow you to send large buffers from one worker to another with just a pointer copy (because it stops being accessible from the sender).

Sounds like a similar process to hand-pulled cotton candy, just with pasta instead of sugar.

here's how to make that: https://www.youtube.com/watch?v=auRNHI2nkIU

for migrations in go, check out goose (https://bitbucket.org/liamstask/goose). I've used it, and it's pretty simple, but works pretty well.

You can write migrations either in plain SQL (my preferred method) or in go.