101–110 of 231 posts
The title of the article is “How to not RIIR”, not “How not to RIIR”. The article is about wrapping an API with a Rust interface so the title used here on HN does not fit the content of the article.
I don't see how the meaning of the phrases “How to not RIIR” and “How not to RIIR” is different.
Earlier quoted context omitted.
Here goes a list from GC enabled languages that let you chose where to allocate. Modula-3, Oberon, Oberon-2, Active Oberon, Mesa/Cedar, Component Pascal, Eiffel, Sing#, System C#, C#, Swift, D, Nim
I prefer the term "obligate-GC languages": you don't get to choose whether GC runs. Otherwise, Rust and C++ count as "GC-enabled", and comparisons are vacuous. Reference-counting, a form of GC very commonly used in Rust and C++, is inefficient compared to more intrusive schemes, particularly where there may be contention for the count, but may be applied selectively, e.g. never on critical paths, so that the ineffici…
Yep, really lying.
I think this is a clever concept and useful article. However, I have to disagree with the severity of this statement: > at best, the temptation to RiiR is unproductive (unnecessary duplication of effort) For tiny, mature libraries, this might be true. But a rewrite in Rust can also vastly improve maintainability. If a library is under heavy maintenance (and will continue to be), your investment in rewriting it is lik…
Yes you could rewrite them in Rust, but considering these are tools which are used all over the ecosystem and have massive momentum behind them, your time would be better spent building cool things on top of existing work than reinventing the wheel and trying to convert the ecosystem to something which will (initially, at least) be an inferior product.
The original statement was deliberately opinionated and extreme, but I still feel like the pragmatic approach of reusing existing libraries instead of rewriting them is the best one for the short/medium term (jury's still out on the long term costs/effects).
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.
People rewrite C and C++ software in Go too. In fact, unlike Rust, most Go software has no C dependencies at all. This is precisely the result of rewriting everything in Go. To be clear I’m not suggesting you should always rewrite something versus just wrap it, not at all. I’m just saying the reasoning for not doing it being “you didn’t write the original so what do you know” is very offensive to me; how are you supp…
Most programmers are programmers for hire, and it would be a waste of everyone's time to re-implement (for example) libdispatch in Rust. If someone wants to write it on their own time for their own edification and no other purpose, fine -- but half-assed internal implementations of common functionality are a significant drag on the lives of other working programmers.
I still have issues with Rust string handling. Half of the time I have no idea how to get strings out of libraries. I don't understand the intentions of the language creators at all. Does anybody have a great intro to Rust for software engineers who come from Python or something similar where high level types are the norm?
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…
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.
People rewrite C and C++ software in Go too. In fact, unlike Rust, most Go software has no C dependencies at all. This is precisely the result of rewriting everything in Go. To be clear I’m not suggesting you should always rewrite something versus just wrap it, not at all. I’m just saying the reasoning for not doing it being “you didn’t write the original so what do you know” is very offensive to me; how are you supp…
> The first step in interfacing with a native library is to understand how it was originally intended to work. But reading code is hard, it's easier to project your sense of confusion onto your predecessor than own it yourself, and once you rewrite the code in Rust and start to understand the true complexity that the previous code had to work around, you'll leave for another job (this time with Rust on your resume).
It's called resume driven development, and the reason it's done is because it helps those who do it get jobs
"A much better alternative is to reuse the original library and just publish a safe interface to it." I think I must reject the premise a bit, unless I misunderstand how Rust works. If you write a safe wrapper around unsafe code, is it not still the case, that if the unsafe code bombs out, it will take the safe Rust down with it, engulfed in shared flames? (Unless you spawn unsafe code in its separate process or some…
The title should be "how to not" rather than "how not to".
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++".
Guess what, we even used to have a famous magazine called "The C/C++ Users Journal".