In my career, I've found that this problem crops up the most when a team is unable to make impactful changes to a system that they depend on. It's so much easier (and requires less collaboration and fewer approvals!) to build an abstraction over some core system than to actually fix the core system, even if fixing the core system is always the better choice.
I was very guilty of this as a young go-getter engineer! Why try to convince another team that something should be fixed if I can just paper over it?
I also think the author is understating how bad the original framework was. I've seen some of these and the "itchy points" are real true problems. The team supporting the framework decides that fixing the pain won't get them promo because it doesn't show up in any metrics, and certainly they won't accept your submitted improvements. Your only choice is to wrap it.
Of course, since their thing is a framework, your wrapper must be a framework too. (Is it possible to wrap a framework into a library?)
The end of the story is even sadder. You work on your replacement and wrapper, and oh no, the framework you are wrapping has problems or slowness because of the framework it depends upon!
Years ago, I introduced Flow gradual typing (JS) to a team. It has explicit annotations for type variance which came up when building bindings to JS libraries, especially in the early days.
I had a loose grasp on variance then, didn't teach it well, and the team didn't understand it either. Among other things, it made even very early and unsound TypeScript pretty attractive just because we didn't have to annotate type variance!
I'm happy with Rust's solution here! Lifetimes and Fn types (especially together) seem to be the main place where variance comes up as a concept that you have to explicitly think about.
Note that this works because Rust doesn't have inheritance, so variance only comes up with respect to lifetimes, which don't directly affect behavior/codegen. In an object-oriented language with inheritance, the only type-safe way to do generics is with variance annotations.
This is very disingenuous: we don't know how much spare time Sascha spent, and much of that time was likely spent learning, experimenting, and reporting issues to Slang.
It's not disingenuous, we have his and my git commit logs. I also had to deal with issues with rust-gpu. He is an expert in both the space and his project, I had never seen his project nor written any graphics shaders before. You can never get apples to apples comparisons but this is the closest I have personally experienced.
Once upon a time, Flash, Java, Silverlight, ActiveX, etc. ruled the web.
I think the world is _much_ better off today, with a common language and platform. I don't think those big third party runtimes could survive in the browser in today's threat environment.
Unfortunately "common" means being what Google wants, and they abuse their market position to push whatever through (advertising support in an HTML client... what?)
You might be getting “sampled textures in a single call” with “total textures loaded” mixed up. Sampled texture limits affect complexity of your shader and have nothing to do with loading content from elsewhere.
The CPU-specific intrinsic stabilized a little while ago for cases where you need SIMD on a specific platform at least. A lot of crates like glam seem to only support SIMD on x86/x86-64 for that reason.
I know that `wide`, `faster`, and `simdeez` are options for crates to do cross-platform SIMD in safe Rust. Eventually we'll have `std::simd`, but I don't know what the timeline is or what the blockers are.
Algebraic effects use delimited continuations (and this appears to match toss/return). Call/cc captures an undelimited continuation. Totally different.
These three comments as a chain are hilariously close to the paper ‘On the Expressive Power of User-Defined Effects: Effect Handlers, Monadic Reflection, Delimited Control’ by Forster,Kammar,Lindley,Pretnar. It’s relatively new and evaluates the expressive power of the three concepts, which barring preserving typability during translation, are equivalent.
I was very guilty of this as a young go-getter engineer! Why try to convince another team that something should be fixed if I can just paper over it?
reply