But many artists are hallucinating when they envisioned some of their pieces. Who's to say Mozart wasn't on a trip when he created The Marriage of Figaro.
If you need to grab a particular struct's version of the data, you can via `opts.BarService.URL` or `opts.FooService.URL`: https://go.dev/play/p/MUSYJhmoC2D
Still worth being careful, but it can be useful when you have a set of common fields that everything of a certain group will have (such as a response object with basic status, debug info, etc. and then additional data based on the particular struct). I don't know why they let you embed multiple layers and multiple objects though. I've never gotten value out of anything but a "here's a single set of common fields struct embedding".
There aren’t grid-scale batteries that can handle hundreds of thousands of cycles at an affordable price. If we crack that problem, solar and wind for everything will immediately be the only technology worth deploying for energy in 99% of areas.
Never look at the dispatch of a big company’s Java code base then. It’s dynamic dispatch 400 layers deep for a single network call or file op or small amount of math. Sure those are more expensive operations, but the dynamic dispatch has continually out scaled the problem.
Product velocity is not increased by spending a ton of time on complex type hierarchies and premature extensibility. It’s increased by having fewer classes and simpler functions that are faster to write tests for to get good coverage via end-to-end tests. The patterns of OOP increase the amount of time spent not solving the business needs. They also infuse the entire system with unnecessary slowness.
If this is going to be a library where that’s a desirable feature, architect it for that feature. In the example, one easy way would have the coefficient table be expandable/replaceable. If you really need to run arbitrary user code, then write an interface that the user will conform to and call their code. You don’t even need OOP support to do that easily, just typed function pointers.
To summarize: if you make the problem complex enough, then the specific performance methods used in the article don’t work. But hey, why not take your complex example? If you apply a polymorphic approach to Bézier curves and polygons, then you still get a 1.5x slowdown compared to a switch statement. If you have any commonality between your implementations of area for them, it’s harder to find, which could be worth 2x or more. If there is a common algorithm for calculating all polygons and curves, wasting work for simple shapes, but vastly improving cache and predictor performance, then you could be leaving another 5x on the table. Orienting the code around operations instead of types is still a win for performance with similar cognitive load compared to type hierarchies.
You’re right that once you’ve done the 15x performance gain that Casey demonstrates, the code is pretty brittle and prone to maintenance problems if the requirements change a lot. But I think we can have our cake and eat it too by maintaining our code with the simple path available to fall back to if we get a complicated new requirement. Need to add in complex cases that weren’t thought of before? Add them to new switch cases that are slower, and then keep looking for more performant ways of calculating things of need be.
Obscure tech and proprietary tools do translate… if you can translate them.
Programming languages are all the same, so learn 3 or 4 new ones and discover that you can probably write in any language for an interview (then do some in relatively unfamiliar languages for kicks and giggles to practice).
Tech is all the same. Take data in, poop data out. That’s the whole job. The formats and protocols change, but once you starting thinking about your stacks as data-in, data-out, they all start looking the same.
Make video games or hardware drivers from scratch, those are the hardest things to make. Video games from complexity overload, and hardware drivers from interface complexity.
It's no more misleading than saying it runs on bare metal. If I flash the correct motherboard ROM chip with the necessary bits to play Tetris in the UEFI (or completely replace it), would I be running closer or farther from "bare metal" than this is? Am I still on bare metal if I choose to use GRUB for loading up the game? Do I become an OS if I use GRUB instead of embedding that logic within my binary?
We call things BIOS and Boot-loader and Operating System by virtue of history, not necessity. It could even be confusing to a newcomer looking into development closer to the hardware and being told that all these programs are fundamentally different, instead of just being instructions and data getting shoved through a bunch of tubes in the processor and PCB.
The throttling was battery related. They could either have the phone shut off or just throttle down, they chose the latter. The fault is assign there is not communicating what the problem was and how to remediate it. They will still swap out your battery for a new one for something like $80 out of warranty, giving the phone another 3+ years of life.
If you’re doing any moderately complex analysis of the data in your database, the ORM will quickly start falling down. Abstracting the query layer into the application codebase is nice, and mapping entities to objects is nice, but ORM is not a silver bullet. Learning what makes for a good schema vs a bad schema and how to avoid N+1 loading or query problems is important no matter what.
ORMs aren’t bad, but learn their escape hatches or else you’ll have a hard time doing more complicated things.