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

191–200 of 231 posts

Re: How to not rewrite it in Rust

#191

Post by orange8 »

scottlamb wrote: post #181
orange8 wrote: post #170

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…

I did not mention anything about github. I am talking about what you can freely do with any opensource software without being made to feel like you are breaking the law or doing something immoral. If you arent comfortable with people building on top of or making derivatives of your work, do not opensource it.

Re: How to not rewrite it in Rust

#192

Post by randyrand »

bernawil wrote: post #160
IshKebab wrote: post #144

Earlier quoted context omitted.

There's pretty easy rules: stack unless it needs to outlive the current scope, or is very large. That covers 99% of cases.

But you realize that "it needs to outlive the current scope" is vague enough to support the statement that there's really no rule of thumb, right?

Seems pretty objective to me. When the current function returns, will this object ever get used again? Most of the time the answer is no.

Re: How to not rewrite it in Rust

#193

Post by jfsszuj »

kragen wrote: post #175
pron wrote: post #173

Earlier quoted context omitted.

It's pretty much the only kind of bugs that Rust can prevent, too. > and it's far from clear that fixing all the bugs, or even all the undefined behavior, in an existing C library will be less effort than rewriting it It's pretty clear to me. > Consider that one of the worst security bugs in history I'm not sure what bug you're referring to, but if it's Heartbleed, than that was an undefined behavior bug. Of course,…

No, I'm talking about the Debian OpenSSL bug Luciano Bello discovered. It was a lot worse than Heartbleed. Kurt Roeckx didn't introduce Heartbleed, and Heartbleed wasn't introduced by removing undefined behavior, so there is no plausible reason for you to infer that I was talking about Heartbleed. As for the cost of rewrites, there's a lot of evidence from software project metrics that the cost of modifying software…

We can almost always tell what a given piece of software will do, we just can't tell what all software will do in all cases.

Re: How to not rewrite it in Rust

#195

Post by peoepl929 »

orange8 wrote: post #170
brendangregg wrote: post #143

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.

It is gate keeping. Pretty dismayed to see who is peddling it here. Corporate sycophant now I guess.

Really smart computer nerds emotionally wrapped up in change they aren’t interested in. They know what the future needs! To stay just like yesterday!

Gen X has become the old geezers who want you to stay off their lawn.

Oh what? It may not be super popular like Linux? We all have to work on the same code bases? Individual drive and curiosity verboten! Your one person project won’t satisfy the general user base? You should just focus on computing as we see it.

Who cares. Generate whatever syntax you want. They don’t have to organize around the semantics if they don’t want.

Gimme a break.

Re: How to not rewrite it in Rust

#196

Post by abbadadda »

chii wrote: post #182
scottlamb wrote: post #181

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.

I think the author's point is not that you can't RiiR, it is that one should think twice if the resultant code is not supported. If there is a Rust community around it, great! But if it is just doing it just to RiiR, then (C) holds.

Re: How to not rewrite it in Rust

#197

Post by saagarjha »

viraptor wrote: post #184
gameswithgo wrote: post #149

Earlier quoted context omitted.

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.

How does Rust help you if you have to cross-compile?

Re: How to not rewrite it in Rust

#198

Post by safercplusplus »

pron wrote: post #115
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…

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

While not as mature as Rust, static enforcement of C++'s (memory and data race) safe subset is coming along [1].

Iiuc tools like TrustInSoft are for situations where you need not just safety, but "reliability" (i.e. no crashes, no exceptions). That doesn't really scale so well to larger applications.

[1] https://github.com/duneroadrunner/scpptool

Re: How to not rewrite it in Rust

#199

Post by saghm »

saagarjha wrote: post #197
viraptor wrote: post #184

Earlier quoted context omitted.

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

How does Rust help you if you have to cross-compile?

I'm not positive, but I think GP intended to refer to idea that you would need to multiple compilers to compile the project rather than cross-compiling to another platform.

Re: How to not rewrite it in Rust

#200

Post by pnako »

rytill wrote: post #151
dmit wrote: post #89

Earlier quoted context omitted.

Alternatively, you could have C/C++ as a third, discrete category somewhere in the middle of the C C++ spectrum. For people who like namespaces, or overloading arithmetic operators for mathy vector/matrix/etc stuff in order to make the code more readable.

C+?

C+=0.5
Post reply on HN