-
> it crashes process IDs more often than Justin Bieber crashes Maseratis: https://github.com/rust-lang/vscode-rust/issues/890
So -- this guy used an extension (named Rust) with rust-analyzer, which was known to not work, and it didn't work(!), and the Rust extension author recommends he tries the extension made for rust-analyzer. That extension doesn't have the features he likes (it works for me and has loads of features, so I have no idea what this is about?), and so they close the issue?
Hardly a case for the ages. Guy uses unsupported config and things don't work?
> What clangd does is work.
Don't doubt it. I'm just saying -- I haven't had any problems with the rust-analyzer extension since it became the Rust default. But, yes, I had a few hiccups and crashes beforehand, no doubt. I just have to imagine it's both younger, and doing more/different things than clangd.
-
InfluxDB
Purpose built for real-time analytics at any scale. InfluxDB Platform is powered by columnar analytics, optimized for cost-efficient storage, and built with open data standards.
-
> Search your heart, do you think this story ends similarly if they decide to all do "modern C++" instead?
https://github.com/facebook/rocksdb
-
Funnily enough, a REPL environment is in the works for Rust: https://github.com/google/evcxr
-
Agree, you can see this in https://github.com/rust-unofficial/awesome-rust vs. https://github.com/avelino/awesome-go
I've noticed however that there has been an uptick in great libraries over the last 2 years, with examples like pola.rs, rust-bert, tokenizers etc. starting to build momentum in the ecosystem.
-
Agree, you can see this in https://github.com/rust-unofficial/awesome-rust vs. https://github.com/avelino/awesome-go
I've noticed however that there has been an uptick in great libraries over the last 2 years, with examples like pola.rs, rust-bert, tokenizers etc. starting to build momentum in the ecosystem.
-
Event the C# version is simpler :D
https://github.com/dotnet/Docker.DotNet#example-create-a-con...
-
tokio
A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ...
Quick correction for anyone searching: it's `tokio`, not `tokyo`. [0]
[0]: https://tokio.rs/
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
I'd be interested in a bit more detail on the technical migration strategy. Did they just cut over to a version of the project built in Rust? (I.e. vN is Python+C/C++, vN+1 is Rust?) Or something more gradual?
How did they verify that the new code was conformant with the old app's behavior/logic?
> To make matters worse, we would discover issues only after deploying (or in production!) due to Python’s run time nature.
I don't want to infer too much, but this makes it sound like perhaps they didn't have a very robust set of E2E/Acceptance tests, which would make a full-cutover migration scary to me. If you're finding Python bugs only after deploy, how can you find the inevitable rewritten-Rust-code incompatibilities before deploying/production?
I've been digging into Rust/Python interop recently using https://github.com/PyO3/pyo3 and maturin, and this points to an interesting migration strategy; PyO3 makes it quite easy to write a Python module in Rust, or even call back and forth between them, so you could gradually move code from Python to Rust. A migration path to full-Rust might be:
1. Incrementally replace all your fast-path C/C++ code with Rust, still having Python call these compiled modules. End-state: You now have a Python/Rust project instead of Python/C/C++.
-
Source? I thought .NET GC was tuned for throughput.
Their performance is, impressive, to say the least.
https://www.techempower.com/benchmarks/#section=data-r21
