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.
Then be comforted that the argument here is not actually about the science, but rather about its interpretation or about the philosophical assumptions underlying the interpretation.
Dr. Hossenfelder is not arguing against the mathematical theory of inflation, or about its observational evidence. It's about whether there is any metaphysical problem if a certain parameter turns out to be much smaller than one.
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).
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 certainly agree with this sentiment (and the author's words "Read code that you can actually grok"). As a younger programmer, I tried to get into reading the source code for Flask and learned pretty much nothing.
The thing that has seemed to have the most effect for me (of course, this may not necessarily be effective for everyone) is refactoring or even completely rewriting my side projects after/near finishing them. It's a little bit maddening, since I would rather move forward and build new features or start a new project, but the exercise is really helpful. It forces me to take a step back, look at everything I've done, and figure out where I could have done something better. Then, hopefully at least, when I'm in a similar spot in the future I'll be able to think ahead better. In fact, "thinking ahead" might be the most valuable skill for a programmer to have, and I don't really see how reading code can help with that. All of their design decisions have been made by the time you read the code, and it's really difficult, especially for a junior developer, to actually consider how and why those decisions were made.
As a (mostly) front-end developer, I agree that reading some of the code in your node_modules can be enlightening. Sometimes in a good way, sometimes in a bad way.
There have been times when I've dug into a module when something wasn't behaving properly, and was shocked at how bad the code was. It's not as if I included it intentionally - it's usually a dependency of a dependency of a dependency. All the same, it was garbage that I'd been shipping as part of my application.
Your point still stands, though. Having the code where it's easy to find and read is helpful. And reading bad code can be as helpful as reading good code. Sometimes, the trauma caused by seeing some atrocious code can improve your habits more quickly than reading beautiful code. :)
Also, at the OS level, there are entire projects built around just understanding the dependencies in the Operating System and applying minimalism to try and get to a state of (relatively) simple, known dependencies.
One of my favorites is Rob Landley's Aboriginal Linux:
Great suggestion. It's great because you have context (you know what the input/output is) so the learning curve is flatter. Anytime I've done it, it's been a confidence booster. I always feel like the dependencies I use are built by genius coders who are much better than me. When I inspect the source I am reminded that it's just the same ole' code as I would write, but of course better documented and tested :)
It's not really any harder to modify the dependencies in Ruby (or Python, or I'd guess most other dynamic languages). They're usually all stored deep in a subdirectory, but a little find-fu typically gives them up quickly enough. I agree that people should be more willing to dig underneath the covers and see how the code they depend on handles things.
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).
Yes, but even with that restriction, it doesn't let you transfer ownership of structured messages, only buffers and images; so a serialization roundtrip is needed.
