Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to not rewrite it in Rust

adventures.michaelfbryan.com

Post reply on HN
Print view View original

131–140 of 231 posts

Re: How to not rewrite it in Rust

#131

Post by baq »

StreamBright wrote: post #105
baq wrote: post #27

Earlier quoted context omitted.

It’s like that because strings are very difficult to get 100% right even in gced languages (Python 2 says hello) and when you take into account ownership and different standards used even in the same OS it all becomes a nightmare. You have to know when you want a reference or an owned object, when you want mutable vs immutable and when you want portable vs OS specific, and god forbid you put a path in a string. This…

Thanks, it would be great to cover all these types with common scenarios (like using a hash function, storing something in a database or things that are the most common in programming). If it is a good idea to hide those things then we need a library that does exactly that for Rust. Don't you think?

They’re good reasons for Python but not necessarily for Rust, where you are expected to care about such details by design. It’s one of the language’s differentiators.

Nonetheless a cookbook for converting strings for different use cases isn’t a bad idea at all.

Re: How to not rewrite it in Rust

#132

Post by keldaris »

otabdeveloper4 wrote: post #86
sitkack wrote: post #14

This 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…

There's no such thing as a "C/C++".

While you can essentially write C in almost any language, C++ is particularly well suited to it.

Re: How to not rewrite it in Rust

#133

Post by pjmlp »

The_rationalist wrote: post #120
pjmlp wrote: post #59

Earlier 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…

BTW there are garbage collectors for c++

Yep.

C++/CLI, C++/CX, GC pluggable API introduced in C++11, C++ Builder VCL in ARC mode, Unreal C++ managed classes.

Re: How to not rewrite it in Rust

#134

Post by zozbot234 »

jaredtn wrote: post #94

Summary: - Rather than rewriting a C++ library in Rust (difficult and will introduce bugs), wrap it in a Rust interface. This seems like the cleanest way to move a codebase forward without too much regression work. It reminds me of how TensorFlow 2.0 still contains tf.compat.v1 APIs so devs can write forward-facing code while maintaining existing modules.

> wrap it in a Rust interface

You'll need to do this anyway if you want an actual library that can be independently packaged, because that means you have to use the system ABI in the library itself. Rust does not provide a stable ABI.

Re: How to not rewrite it in Rust

#135

Post by zbentley »

Skunkleton wrote: post #128
adrianmonk wrote: post #74

> 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.

Why not use ffi for this case? Many languages have robust support for linking to Rust code.

Re: How to not rewrite it in Rust

#136

Post by minraws »

pjmlp wrote: post #60
nicoburns wrote: post #54

Earlier quoted context omitted.

> TBH I don't see a future where RIIR every piece of software would make sense It doesn't necessarily have to be Rust, and it's a process that may take decades. But I really do think that absolutely everything should be rewritten in a memory-safe language (i.e. not C/C++). The vast majority of security issues are either stupid misconfigurations or memory-safety issues. And currently most security initiatives are unde…

Yep, on my domain it has been Java and .NET.

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. :)

Re: How to not rewrite it in Rust

#137

Post by chc »

pjmlp wrote: post #59
sitkack wrote: post #14

This 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…

You can write safe code in C++, but it requires you to go way out of your way and exercise constant vigilance, and it's not always obvious when you mess it up. This is the approach we've been trying for 20 years, and it generally hasn't worked well, because people are both flawed and lazy. This is the thing that's fundamentally different about Rust — it provides strong guarantees by default and requires you to specifically call it out when you're doing something potentially unsafe, so to some degree it turns our laziness into a force for good.

Re: How to not rewrite it in Rust

#138

Post by empthought »

discreteevent wrote: post #122
empthought wrote: post #90

Earlier quoted context omitted.

Rewriting software written using Python, Java, and Ruby in Go is entirely different from rewriting software written using C and C++ in Rust. Go has easily quantifiable advantages over those other runtimes regardless of the original code's correctness.

Can't see what you would really gain rewriting from Java to Go.

Go can have a much smaller memory footprint than Java.

Re: How to not rewrite it in Rust

#139

Post by minraws »

sitkack wrote: post #61
nicoburns wrote: post #54

Earlier quoted context omitted.

> TBH I don't see a future where RIIR every piece of software would make sense It doesn't necessarily have to be Rust, and it's a process that may take decades. But I really do think that absolutely everything should be rewritten in a memory-safe language (i.e. not C/C++). The vast majority of security issues are either stupid misconfigurations or memory-safety issues. And currently most security initiatives are unde…

Exactly, when we talk about RiiR, we are saying, "I would like to have the guarantees that Rust provides". If the Rust ecosystem depends heavily on C/C++ libraries, then the system has the properties of the union of all the flaws and the properties of the language do not translate into a quality of the ecosystem. That said, I think containing C/C++ to a Wasm sandbox that can be integrated transparently with Rust woul…

TBH I still don't see it happening or being the case atleast in the near foreseeable future...

Why you may ask..? The answer is simple cause there is always a cost. So the question is what is easier or when can one say the cost of using a "safer" language out weighs a "less safer" one..

Cause otherwise Rust is also too damn unsafe, just move to something completely safe Idris could be a good starting point. /s

Putting the sarcasm aside. Rust is does not guarantee Memory safety, it tries to help with it. (Check Reference Cycles) The safest feature of Rust would be it's protection against Data Races.

So at the end it's all about the trade-offs and deciding what you are willing to sacrifice and what you aren't...

Re: How to not rewrite it in Rust

#140

Post by cellularmitosis »

sitkack wrote: post #14

This 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…

I agree, and I see a lot of analogies between this situation and the ObjC -> Swift transition which many code bases have gone through. When there are significant semantic benefits in the new language, a slow war of attrition against the old language is a good move.
Post reply on HN