Live data from Hacker News

How to not rewrite it in Rust

adventures.michaelfbryan.com

181–190 of 231 posts

Re: How to not rewrite it in Rust

#181

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

> (C) is anti-collaborative, and an extreme measure that should only happen in extreme circumstances (not "just because it might be better"). 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.

You can...and certainly cloning a git repo or hitting the "fork" button on github is a normal part of the development workflow. If you're experimenting those changes may be discarded. If you're contributing those changes go back to upstream. But I don't think either of those are what the author means by fork. Other folks have talked about this. [1] [2]

I think the author means: if you're maintaining changes in your fork indefinitely and advertising this fork to others as superior to the original to use or as a canonical place to file issues, you should have a good reason. Communities are valuable; please don't divide them or throw them away lightly. Try working with the original maintainer first.

[1] https://news.ycombinator.com/item?id=16600219

[2] https://news.ycombinator.com/item?id=20001570

Re: How to not rewrite it in Rust

#182

Earlier quoted context omitted.

> (C) is anti-collaborative, and an extreme measure that should only happen in extreme circumstances (not "just because it might be better"). 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.

You can...and certainly cloning a git repo or hitting the "fork" button on github is a normal part of the development workflow. If you're experimenting those changes may be discarded. If you're contributing those changes go back to upstream. But I don't think either of those are what the author means by fork. Other folks have talked about this. [1] [2] I think the author means: if you're maintaining changes in your f…

> you should have a good reason

And what constitutes a good reason?

The epitome of open source is that you don't need to explain of your fork is really superior, the users will come.

Re: How to not rewrite it in Rust

#183
post #182

Earlier quoted context omitted.

You can...and certainly cloning a git repo or hitting the "fork" button on github is a normal part of the development workflow. If you're experimenting those changes may be discarded. If you're contributing those changes go back to upstream. But I don't think either of those are what the author means by fork. Other folks have talked about this. [1] [2] I think the author means: if you're maintaining changes in your f…

> you should have a good reason And what constitutes a good reason? The epitome of open source is that you don't need to explain of your fork is really superior, the users will come.

Creating a wrapper around an existing library will never be superior to a native rust library to me.

Re: How to not rewrite it in Rust

#184

Earlier quoted context omitted.

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

yeah sometimes that makes sense. if the lib in question in small enough it might be more valuable to port, so avoid having a multi language project, and avoid the effort of the ffi. at least Rust -> C ffi is zero cost (usually)

Having everything available in Rust code also means you don't have to do lots of extra work for cross-compilation.

Re: How to not rewrite it in Rust

#185

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

> (2) You already have other reasons to want to rewrite (design could be improved, code is in a poor state, etc.), and you're deciding between languages.

It would be wise to ignore the language distraction and remember that most urges to rewrite are just flat out wrong. The standard and well respected advice about rewrites doesn't go out the window just because of a fad language, if anything they apply more strongly.

Much of what people perceive as cruft is most of the actual value-- the stored knowledge from years of experience using the software in practice. Few "clean" programs are actually complete.

Re: How to not rewrite it in Rust

#186

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

> (C) is anti-collaborative, and an extreme measure that should only happen in extreme circumstances (not "just because it might be better"). 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.

You are free to fork, but that doesn't make it right.

Imagine a well-funded startup trying to make a name for themselves decided to fork the top 10 emerging open source projects, put their company name on them, and then spend millions in PR/marketing so that (A) it seems like they invented them, and (B) they fork the community. Are they free to? Is it right? What will it mean for the original authors and experts who created the software?

I happened to be reading this yesterday: dstat is dead. Red Hat decided to rewrite it using pcp, so the original author has given up. https://github.com/dagwieers/dstat/issues/170

Is Red Hat free to? (probably). Is it right? Now that's where I'd want to see a strong reason.

Re: How to not rewrite it in Rust

#187
post #36

Earlier quoted context omitted.

As mentioned by others, you need to convert the bytes to a String. `Sha2` provides a helper function for that: `hasher.result_str()`. EDIT: sorry I don't know which docs I was looking at, I can't find it in the current version.

This is helpful but in general what is a problem of having strings and trivial functions to convert something (like bytes) to strings? Maybe I am missing the point.

It sounds like you're coming from a language (like C) where a string is just an array of bytes or a language (like Ruby or Javascript) where strings are seriously overloaded.

In Rust a string is a UTF-8 sequence. Typically human readable. A byte is generally represented by the u8 type, and a collection of bytes is either an array or vector (e.g. [u8] or Vec). To create a human readable form of an object in Rust you'd typically use the Display ({} format specifier) and/or Debug traits ({:?}). A string (e.g. &str or String) is NOT a collection of bytes. There are exceptions however with OsString/OsStr representing something closer to a collection of bytes and CString/CStr representing a bag of bytes.

Your comments seem a bit XY-ish to me. What are you trying to solve by converting things to strings? For debugging or human readable output Array, Vec, and u8 all implement the Debug trait. u8 also implements UpperHex and LowerHex so you can get a hex formatted version as well (e.g. format!("{:02X}", bytes)).

For the (MD5) hash case, as others have pointed out you're looking at a base 64 encoding which you'll often have to do on your own depending on the library you're using.

Now if you're struggling with owned vs borrowed strings that's a whole other matter. You can insert some magic into your functions with generics and trait constraints and into your structures with the Cow type (clone on write).

Re: How to not rewrite it in Rust

#188
post #172

Earlier quoted context omitted.

In practice, how much does “not completely free” cost? TrustInSoft doesn’t even publish prices, which pretty strongly suggests I couldn’t afford it nor persuade a manager to expense it.

The main cost either way is not licensing but effort.

That's not always true. While I have no idea of what this particular solution costs, I have seen licensing costs that would easily pay for a 20+ person team. The size of the software is important to consider when you are looking at the cost of rewriting.

Re: How to not rewrite it in Rust

#189
post #167

Earlier quoted context omitted.

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

Out of curiosity, how many times did you get raised in 5ish years ?

3 times, 2 of them were significant (> 20%)

Re: How to not rewrite it in Rust

#190
post #182

Earlier quoted context omitted.

You can...and certainly cloning a git repo or hitting the "fork" button on github is a normal part of the development workflow. If you're experimenting those changes may be discarded. If you're contributing those changes go back to upstream. But I don't think either of those are what the author means by fork. Other folks have talked about this. [1] [2] I think the author means: if you're maintaining changes in your f…

> you should have a good reason And what constitutes a good reason? The epitome of open source is that you don't need to explain of your fork is really superior, the users will come.

A good reason is that your fork is superior _and_ you have exhausted reasonable efforts at sharing the improvements with upstream. There's some threshold of how superior but it's subjective.
Post reply on HN