The conversion is pretty expensive, and very sensitive to numerical errors. Okay as a preprocessing step, but I'd strongly advise against doing it in a shader.
If you store the image in Lab coordinates, then converting back to RGB is two 3×3 matrix-vector multiplications and three cubes. The hue shift would be another 2×2 matrix-vector multiplication if you have (cos θ, sin θ). Is that that expensive?
(Obviously preprocessing would be a lot better if you can get away with it.)
I think it changes the nature of this technique from a cheap simple trick – just one low-precision matmul – to a less general, many times more expensive, more complex computation.
To me that starts to feel wasteful, even if GPUs can churn through that anyway. If you're merely implementing a color tweak in a game you can come up with plenty of simpler formulas that look nice.
I've written oklab and okhsl implementations — that cube amplifies errors greatly. The full-precision cbrt makes it definitely a one-way thing for real-time graphics.
I have a feeling that it would be good to these sort of transformations in perceptually uniform colorspace anyways. Ottosson has some examples of color blending in different color spaces: https://bottosson.github.io/posts/colorwrong/#comparisons
I've done many rewrites of C in C, and C in Rust, and there is a big difference that is directly attributable to Rust.
The safety of references, no raw malloc, no null pointers, compiler-checked thread-safety of types, consistent and enforced error handling help a lot to make robust programs, and allow making bigger refactorings without fear of screwing something up.
The Turing Tarpit means that theoretically everything you can write in Rust you could have written in C, but in practice Rust enables things that wouldn't be worth the risk/effort in C, even when doing a ground-up rewrite.
If you wouldn't write your program in C or C++, then it's not the problem that Rust is trying to solve.
Rust has some nice high-level features and tools, so it gets used in other areas like web dev too, but in the end, it is a systems programming language. It is a low-level language, even though it may not feel like that a lot of the time.
Let's say I want to use a real type-safe language to write web applications. So rails/python/JavaScript/php is out of the window. I'm left with two big options: Java/Kotlin and C#. If I want to avoid Microsoft, I'm left with Java. And in fact, this is the industry standard for "real" web development: financial, enterprise, etc.
But Java is cumbersome. It's very `FizBazBarFooAbstractInterface` type of cumbersome. Kotlin makes it nicer, but Kotlin didn't get much adoption in the web industry. C/C++ is too low level for web development. Rust is the perfect language, in my opinion of course, to fill this niche.
Oh, there is also Go. Which is, by the way, also a system programming language. But nobody argues that Go shouldn't be used to write web services.
If you come from proper languages, like C, the borrow checker is not that bad. The problem is that most developers don’t even know when variables go out of scope. Sure, there are more to that in the borrow checker, and I’m far from understanding every single use case. But for fay to day web development, it’s fine.
Java on the other hand is straight up annoying. It’s super bloated, there are 101 ways to do the same thing (recent example from swing: do I do new Broder(), do I use BorderFactory? What’s the difference? When should I use each one?). And it’s extremely wordy ‘Employee foo = new Employee()’
Never considered. I grew up coding in C, so always wanted to come back to something similar. After being spoiled by PHP/JS, couldn't go back to C/C++. Rust offered me a modern, C-like language, so I just learned it and applied forcefully wherever I could.
It depends how proficient you're in Rust. Once Rust itself is not a difficulty for you, there's a lot of productivity gained from having a modern language with many conveniences, and great tooling.
Rust moves more bugs to compile time, so you will technically spend more time getting the code to compile, but in my experience in 99% of cases it's a time saving. And it lets you be more confident about a program correct by construction, rather than merely fuzzed and not observed to crash. The 1% of counter-examples is trying to be too clever with generic interfaces and hitting Rust's limits.
I think it's necessary to remember that they're not a general artificial intelligence, but language models. For example, they're pretty good (not perfect) at translating things, including translating arbitrary instructions into code or machine-readable forms.
The particular mode of distribution of code as a traditional standard library has downsides:
- it's inevitably going to accumulate mistakes/obsolete/deprecated stuff over time, because there can be only one version of it, and it needs to be backwards compatible.
- it makes porting the language to new platforms harder, since there's more stuff promised to work as standard.
- to reduce risk of having the above problems, stdlib usually sticks to basic lowest-common-denominator APIs, lagging behind the state of the art, creating a dilemma between using standard impl vs better but 3rd party impls (and large programs end up with both)
- with a one-size-fits-all it's easy to add bloat from unnecessary features. Not all programs want to embed megabytes of Unicode metadata for a regex.
The goal of having common trustworthy code can be achieved in many other ways, such as having (de-facto) standard individual dependencies to choose from. Packages that aren't built-in can be versioned independently, and included only when necessary.
There’s two sides to it, an author creating something using plain text in the authoring tool and a reader viewing the final product. So the author uses plain text to get their point across to the reader.
When you’ve created something you can publish it and the reader can view it at a URL. The author obviously isn’t trying to get a point across to themselves in the app.
The authoring tool is a web app and does quite a lot so it is JS heavy. It works well on mobile but the demo only works in landscape as the mobile version is slimmed down so you do have to rotate your phone.
Cloudflare caches pages at many many datacenters, often colocated with large ISPs.
This lets Cloudflare deliver pages from their local cache over local links (which is fast and cheap), instead of fetching the data every time across the world from wherever the VPS is located.
None at all. The alignment is for cheap and easy access of data once it is in memory. It's probably rooted in PostgreSQL being written in C where aligned access is trivial, and dereference of an unaligned pointer is Undefined Behavior and requires more clunky code instead.
