-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
-
Very well-researched article (in my uninformed opinion because I've done virtually no benchmarking). I'd summarize it as, Rust doesn't significantly improve build times over C++ for a project where you need to frequently recompile to test the logic of the code. I gather that the Rust code is pretty idiosyncratic (using raw pointers rather than slices and custom owned and borrowed string containers with i32 length and capacity fields), but I don't know why more idiomatic Rust code would be faster to compile, and it could be very different, so a worse comparison. The results aren't relevant for me because I use Rust mainly for the language features and don't have a project with terrible compile times or the need to often rerun tests, but there might be other C++ projects in the same boat as quick-lint-js that would consider moving to Rust if it compiled faster than C++. Hopefully the efforts of people like u/nnethercote will make that happen.
My apologies, I misunderstood. The initial implementation of -Zshare-generics happened here. Basically, the exported symbols of a library are changed after-the-fact to include any monomorphisations, but unfortunately this does not do any sharing between sibling crates. There might be followup work there I'm not aware of, but it seems that the fundamental problem here is that crates are separately compiled, so modifying the exported symbols of a crate only really gives sharing between crates where there's a dependency relationship, since they're compiled sequentially.
For example, on my Inox2D project, I was using serde to deserialize some JSON payload. But that came with some hacks I had to do, like have a temporary struct that gets converted to the final one because it wasn't possible to serialize it by itself, and add extra-dependencies to make the system extensible while also supporting external structures I used like Arena from the indextree crate.
The only path forward here would be to bend rustc/MIR for streaming codegen (and then bolt it to something like lightbeam).
I understand that this may sound harsh, but I also ported two (far bigger) codebases from C++ to Rust: rustybuzz and tiny-skia. Both of which are production -ready and not just prototypes. And mine not only do not use pointers, but also barely use unsafe in general.
I understand that this may sound harsh, but I also ported two (far bigger) codebases from C++ to Rust: rustybuzz and tiny-skia. Both of which are production -ready and not just prototypes. And mine not only do not use pointers, but also barely use unsafe in general.
Just as a point of reference, I have a ~75KLOC project (includes dependencies) called resvg which takes just 4s in the debug mode and 8s in the release mode to build on M1 Pro.
As an example, you can see this implementation in Swift (https://github.com/pointfreeco/swift-nonempty) by the pointfree.co guys, one is a mathematician, the other an engineer, they love and love to teach functional programming.
My allocator is 258 SLOC.