The author touched on the value of the original author, and this is something missing from the RiiR projects I've encountered. An open source project is more than just code. It's the community: the original authors and maintainers and their years of experience in that problem space. If you don't have a plan to move the community over to Rust (and the RiiR projects I've seen did not) you're (A) duplicating effort, (B)…
How to not rewrite it in Rust
161–170 of 231 posts
Re: How to not rewrite it in Rust
#162> at best, the temptation to RiiR is unproductive I think there are probably three cases here: (1) You have perfectly good software and your only motivation to rewrite is infatuation with how great Rust seems. In this case, yes, that's unproductive. (Infatuation-driven design is poor engineering and is a fairly widespread problem in the software industry.) (2) You already have other reasons to want to rewrite (design…
(4) You want to develop new components in rust, but it has to integrate with your existing components somehow.
Re: How to not rewrite it in Rust
#163This article is wonderful and I hope as a setup for second article, "How to Rewrite it in Rust"! > However at best, the temptation to RiiR is unproductive > A much better alternative is to reuse the original library and just publish a safe interface to it. Just as models are a lower dimensional representation of a more complex problem, [1] I have to re-iterate that there are no truth(ism)s in software and as in all e…
At least in what concerns C++ there are several ways to try its safety instead of bearing the cost of a full rewrite. Using standard library types, actually integrating sanitizers into CI, enable bounds checking (even on release builds) and above all avoid C style coding. Naturally this doesn't work out for third party libraries that one doesn't have control over. So from a business point of view it boils down how mu…
Re: How to not rewrite it in Rust
#164This article is wonderful and I hope as a setup for second article, "How to Rewrite it in Rust"! > However at best, the temptation to RiiR is unproductive > A much better alternative is to reuse the original library and just publish a safe interface to it. Just as models are a lower dimensional representation of a more complex problem, [1] I have to re-iterate that there are no truth(ism)s in software and as in all e…
> But the biggest reason to rewrite it in Rust is safety. This is not a good reason if there are cheaper ways to get safety (at least for existing codebases). Indeed, there are sound static analysis tools (like TrustInSoft) that guarantee no undefined behaviour in C code. Using them is not completely free, and it may even require adding annotations to the code or even changing the code, but it does seem significantly…
Re: How to not rewrite it in Rust
#165Earlier quoted context omitted.
There's no such thing as a "C/C++".
Apparently there is when reading ISO, Microsoft, Apple, Google, IBM, Microsoft,... documentation. Guess what, we even used to have a famous magazine called "The C/C++ Users Journal".
Re: How to not rewrite it in Rust
#166Re: How to not rewrite it in Rust
#167Earlier quoted context omitted.
I mean the incentives are the cause. If you could rewarded with an incredible salary for sticking at the same company for 10 years and making a great, reliable platform using "boring technologies" then more people would probably do it. Instead to raise your salary you gotta jump jobs every 2 years
> If you could rewarded with an incredible salary for sticking at the same company for 10 years and making a great, reliable platform using "boring technologies" then more people would probably do it. > Instead to raise your salary you gotta jump jobs every 2 years I believe the majority of America stays at their employers. It just seems to be the en vogue style for this group. I've made careers at my past two employ…
Re: How to not rewrite it in Rust
#168Earlier quoted context omitted.
At least in what concerns C++ there are several ways to try its safety instead of bearing the cost of a full rewrite. Using standard library types, actually integrating sanitizers into CI, enable bounds checking (even on release builds) and above all avoid C style coding. Naturally this doesn't work out for third party libraries that one doesn't have control over. So from a business point of view it boils down how mu…
Also, adress sanitizer but iiuc it's not advised to keep it in production code.
Re: How to not rewrite it in Rust
#169Earlier quoted context omitted.
Java and .NET are Safe..... O.o Edit: For the uninitiated, I am baffled by the fact that people think Java and .NET are memory safe. Also if you meant that Java and .NET should be replaced by something memory safe.. I am absolutely for it. :)
More than Rust in multithreaded scenarios, actually. Not only they have automatic memory management, they have an industry standard memory model for hardware access, adopted by C and C++ standards, used as inspiration for std:atomic on CUDA. While you keep being baffled, where is Rust's memory model specification?
Rust statically prevents inappropriate unsynchronized accesses for arbitrary APIs (for instance, the compiler will emit an error when attempting to mutate a non-concurrent object/data structure from multiple threads). Those VMs make unsynchronized mutations of individual memory locations work just enough to not be unsafe, but still allow arbitrary unsynchronized operations. These will likely end up with an incorrect result, even if there's no memory unsafety, and may completely violate any internal invariants of the object or data structure. This latter point means one cannot write a correct abstraction that relies on its invariants without explicitly considering threadsafety (it is opt-in safety), whereas Rust has this by default (opt-out safety).
Rust has essentially adopted the C/C++11 concurrency model.
Re: How to not rewrite it in Rust
#170The author touched on the value of the original author, and this is something missing from the RiiR projects I've encountered. An open source project is more than just code. It's the community: the original authors and maintainers and their years of experience in that problem space. If you don't have a plan to move the community over to Rust (and the RiiR projects I've seen did not) you're (A) duplicating effort, (B)…
I agree with A and B, but C just feels like gate-keeping. Open source license do not require collaboration with the original authors. You can freely fork any opensource codebase and modify it as you wish without asking someones permission.