Appart from cxx.rs. I think most binding between C++ and Rust are in fact C and Rust binding. So you need a C API to your C++ library (no template, no std etc...). So for me you can't use C++ library from Rust.
cxx only support a part of c++ STL container. It doesn't support template and custom container implementation. So no generic, no variadic number of argument, no automatic type déduction etc...
I'm not a front end dev and only use JS stuff time to time for small personal project.
There is so much JS framework out there that appear and disappear so fast. I don't know if we can call it innovation. I have the impression they just reinvent the wheel with so little value added.
I prefer to keep on React at least it will not disappear the next time I will do some change on my project.
It's really hard to be sure, but my pet theory is that frontend tech has been rapidly evolving since it had to solve some real problems that are relatively new at scale:
- Work with reactive variables
- Combine three different languages
- Write modular code
- Enable highly response designs
The target platform (the web) doesn't natively support all of these things elegantly, and maybe for good reasons.
I've got the feeling that frontend frameworks are starting to converge to some consensus on some of these things (e.g. signals), and I hope the next decade will be more stable than the last.
That is my feeling/hope as well. Modules were a big win, even if the advantage was felt mostly in bundlers and it’s just now arriving in browsers and node. Hopefully signals will be a smoother thing
My pet theory is that frontend devs have so little on the critical path, and are usually overqualified for the kind of work they do, that they keep reinventing these interesting paradigms for managing state in GUIs basically just so they can keep themselves entertained.
There’s lots of people able to work anywhere on the stack but choose to work on the frontend because they feel super-productive compared to others. They can switch between frameworks and even come up with new ideas.
On the other side, there’s way too many frontend engineers that can barely write tests, have extremely little ability with the visual part, have never setup a new project, but are still getting super small things done.
You are giving most front end devs way too much credit. Most just use React because that's what they were taught and see it as an end rather than as a means to an end as if it is an accomplishment.
Computers have become faster while websites have become slower. You can go on a random webpage and usually see 100s of MBs of memory being used while we had computers in the 90s running 3D games with around 1/100 of that. LLMs have partly become popular because people don't want to enter the current wasteland of web pages who couldn't care less what framework you used and just want to get what they are looking for and to get out.
You will see people write things like "powered by React" as if React is doing any thing except running more JS. You are not getting any closer to the CPU or any of your hardware that actually runs your machine.
At best some of these front-end devs want to appear as if their job is far more complicated and sophisticated than it is.
> react better for job and also some type application, but also you become alcolyte of complexity demon whether you like or no, sorry such is front end life
That said, I do want to point something out: the “Fast (because Rust)” or “Lightning fast” tagline that’s increasingly common in Rust projects isn’t great. Just using Rust doesn’t automatically make something fast — real performance comes from design, algorithms, and benchmarks.
These days, whenever I see “Lightning fast” in a Rust project, it makes me think the author hasn’t really focused on optimization, and that the project might not actually be as performance-tuned as the claim suggests.
Some of the distortion shown in the article is call "Volume Anamorphosis". It's a distortion that strongly deform face and person. This deformation is really visible for short focal lens.
Disclaimer: I work for a photo processing software.
There is. If you use lightroom app for example you can have access to raw pixel.
But I'm not sure there is a way to get all the images the camera app from the iphone take.
Phone don't take one shot to create the final image. they take hundred of shot and combine them.
It's funny because I have completely the opposite stance. When I code in rust (mainly algorithm), I always struggle to change what I want to do to what rust allow me to do. And all this complexity has nothing to do with the problem.
I personally think that the discovery of rust API is awfully as soon as macro is involve. It's impossible to know what argument is taken by macro.
For example the "simple" `println!`, without example in the docstring it's impossible to guess what are the argument even when we have an IDE that show you the implementation.
