That is an interesting read, seems some were having a hard time grasping the benefit of having compiler checks for potential null dereferences. Having worked with null safety in TypeScript and Kotlin the extra bit of strictness is nice.
HN user
symaxian
You can enable null safety in TypeScript, seems like a pretty good fix to me.
Sand-boxing such as in Snap and Flatpak?
I'll second that Angular provides a great experience these days, but they have definitely had substantial API changes within the last few years: standalone components, swapping WebPack for esbuild, the new control-flow syntax, the new unit-test runner, etc...
Valhalla should be able to address this to some extent with immutable value classes.
I'd like to ask these CEOs, for people which are taking advantage of the system, why are they not let go? Could it be that management often have no clue how much value each employee brings to the team? Is RTO being mandated to avoid facing that uncomfortable truth?
Are the techniques described in the article still in use today or have they been superseded?
Shadow maps are a good example, if the final rendered image is 4k you don't want to be rendering shadow maps for each light source which are only 1080p else your shadows will be chunkier.
I understand where he's coming from, but on the other hand it sounds like he's trying to avoid saying "maybe that OOP thing isn't all it was cracked up to be".
Yeah, I cannot count how many times I've seen it claimed that the virtual DOM is the secret to why React(or another framework) is fast, completely missing the point of the virtual DOM.
The virtual DOM is not faster than performing direct mutations of the actual DOM, the virtual DOM is a tool that allows the normally slow approach of "blow away and rebuild the world" to be fast enough to put into use.
Selenium can definitely run tests in multiple windows.
You can open multiple tabs within the same browser window, or you can create multiple WebDriver instances for multiple windows.
It does seem like some additional compression could be performed, if they wanted to keep it a pointer to avoid a table lookup I wonder if they could do something like ensure that all class definitions must exist in the certain contiguous chunk of memory that has a fixed size of 1-4 gigabytes which would let them shrink the pointer size down.