19 ms·

How to not rewrite it in Rust

452 points by yarapavan 7y ago

adrusi 7y ago
The title should be "how to not" rather than "how not to".
- steveklabnik 7y ago
  It really depends on your opinion on split infinitives. Both are correct.
  - cannam 7y ago
    Surely "How Not To..." is typically used when you're talking of a bad way to do something, or a way to fail - so this sounds like it's describing a bad way to rewrite something in Rust, which is not the case. It also isn't the wording used in the original article title.
    - steveklabnik 7y ago
      > so this sounds like it's describing a bad way to rewrite something in Rust, which is not the case. I think this kind of title is trying to do exactly that, or at least, that's how I took it. > It also isn't the wording used in the original article title. This is a good reason to switch it, for sure. I didn't realize this, if you had led with that, I wouldn't have said anything :)
      - lmkg 7y ago
        > I think this kind of title is trying to do exactly that, or at least, that's how I took it I took the exact opposite: This article is describing an alternative to RiiR, so that RiiR is avoided when not needed.
        steveklabnik 7y ago
        I don't disagree with you is that the thesis of the article is "don't re-write something in Rust." What I was trying to say is that I think the title is making a joke; it's saying "how to re-write something in Rust badly", because well, it's not re-writing it in Rust at all.
        aidenn0 7y ago
        I thought the title was making a joke, but then I read the article and IMO the actual article title of "How to not RiiR" is much more indicative of it's content than the HN title of "How Not to RiiR"
    - coldtea 7y ago
      >so this sounds like it's describing a bad way to rewrite something in Rust, which is not the case. Actually, this is the case. It describes the bad way (and bad reasons) to rewrite something in Rust.
  - goto11 7y ago
    No they have different meaning. How to not X = How to avoid doing X How not to X = The wrong way to do X
- coldtea 7y ago
  Not really. "How not to" is a common idiom (like "X considered harmful" for such advice articles (regardless of correctness).
  - aidenn0 7y ago
    The TFA is literally "How to not" as in "how to avoid" not "How not to" which would be "Here's the wrong way to do it"
- dang 7y ago
  Good catch! Changed now.
smt88 7y ago
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 likely to pay dividends by saving developers -- especially ones who are new to the library -- a lot of time.
- epage 7y ago
  Another reason I'd prefer things to be rewritten in Rust rather than using bindings is that calling out to external build systems introduces its own set of problems. I've run into the most problems with C-based dependencies (slower builds, OOM errors, confusion over static vs dynamic linking, etc) than any pure-Rust dependency.
- MichaelFBryan 7y ago
  i'm more thinking about libraries like tensorflow, ssh, or libgit2. 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).
  - erik_seaberg 7y ago
    There's no way to write a safe interface for a C library like OpenSSH where critical vulnerabilities to malicious payloads have been found and exploited. All this stuff needs to be replaced if we're ever to to have a trustworthy foundation.
jacobush 7y ago
"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 something elaborate like that.) (Then again, from a practical standpoint the reasoning may be good. Maybe, even likely, the C library is very good and very battle tested. And very likely, my novice would be re-implementation in Rust would not be very good.)
- steveklabnik 7y ago
  Yes, this is an important distinction about "unsafe" in Rust. https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html is a good starting place for learning about this.
- estebank 7y ago
  One but difference of this approach over just using the original library directly is that now you have a type system that can enforce more invariants than it is possible in C and that the library was previously already relying on. If the (now reduced) API surface happens to still expose a bug, it can both be fixed in the library and/or protected against in the API.
- gbear605 7y ago
  A lot of the time, the danger with unsafe code is doing a thing like passing a null pointer into a function that can’t handle null pointers, or using something before it is instantiated. So the interface should force those things not to happen (with the type system or a constructor or...). This doesn’t prevent the c code from being buggy, but it makes it much easier to use, since you can ensure that you’re maintaining the invariants.
- SAI_Peregrinus 7y ago
  Also even if you do plan to re-implement the C library in Rust it's still a good idea to do this step (make a safe wrapper around the FFI bindings) first. It lets you set up your Rust test cases, and gives you a step to design what the Rust API will look like. You can proceed to pull bits of the C out and into native Rust, all while whatever you've built on top doesn't have to change.
dmm 7y ago
> This may be problematic because it’ll require all users of our chmlib crate (and their users) to have Autotools installed. Autoconf creates a portable shell script, right? No need to have it installed just to build the project.
- steveklabnik 7y ago
  "portable" to different Unices, right? I'm on Windows, for example.
  - dmm 7y ago
    Sure but that's a different problem than "it’ll require all users of our chmlib crate (and their users) to have Autotools installed." I'm just being pedantic. It's a problem...
  - bluGill 7y ago
    Autotools is rarely portable. I've been doing a lot of cross compiling recently: the vast majority of autotools projects can't be cross compiled. Sure autotools itself supports it, but something required to make it work didn't get connected up and so you can't do it. If you want to natively compile on a fairly recent linux with the common standard libraries autotools works well. Even though autotools was written to work around these differences, in most cases the developer didn't hook into autotools detecting that difference and so it doesn't work.
    - monocasa 7y ago
      Cross compiling to what? Autotools is probably the most portable piece of software out there as far as Unices are concerned.
      - bluGill 7y ago
        Embedded Linux on arm. Nothing very far out really. Note that I'm careful not to blame autotools, it is the user's fault, there are a couple projects that use autotools and cross compile easily. The vast majority do not. CMake based projects almost always cross compile easily.
StreamBright 7y ago
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?
- steveklabnik 7y ago
  All of Rust's complexity for strings comes out of complexity due to UTF-8. Well, a tiny bit comes from the fact that Rust has pointers too, but most of it is UTF-8. Did you happen to read the book? We cover strings early because this is a common pain point. Also, if you have something more detailed than "get strings out of libraries", I can give better advice. It's tough to tell what the actual issue is.
  - StreamBright 7y ago
    Like this: use sha2::{Sha256, Digest}; fn main() { let mut hasher = Sha256::new(); hasher.input(b"hello world"); let result = hasher.result(); ?? } How do I get a string with the hash value? Which chapter of which book should I read?
    - aisengard 7y ago
      The hash value is a bunch of bytes. A "string" would need to be some encoded version of those bytes, commonly hexadecimal representation.
    - chousuke 7y ago
      I think you can use format!() to format the byte array as a hex string. The result of a hash is never a string, so it makes sense that you'd need another step to print it as one.
    - steveklabnik 7y ago
      Ah, I see! So yeah, this isn't something the book covers, so that would not be helpful. In this case, the hash ends up being raw bytes. So the question is, what are you trying to do with this hash? Being a bunch of bytes, this may not be valid UTF-8 (and in this case, is not ASCII, let alone UTF-8). One option is to encode to base64: use sha2::{Sha256, Digest}; use base64; fn main() { let mut hasher = Sha256::new(); hasher.input(b"hello world"); let result = hasher.result(); let encoded = base64::encode(&result); assert_eq!("uU0nuZNNPgilLlLX2n2r+sSE7+N6U4DukIj3rOLvzek=", encoded); } But yeah, you can't exactly "get a string" out of a random bag of bytes unless you know how you want that bag of bytes to be represented, encoding wise. That's not exactly a satisfying answer, but such are strings!
fmakunbound 7y ago
> Rust gives you the power to do things which would be unheard of (or just plain dangerous) in other languages What are examples of the unheard of things?
- nicoburns 7y ago
  Unheard of might be overstating it, but in Rust you can do things like pass references to other threads and aggressively parallelise things (without lots of defensive copies) without worrying about it causing bugginess later.
- mmaurizi 7y ago
  Passing around pointers to objects on the stack. In another language you'd risk having a pointer to invalid memory when the function returns if the pointer escapes the function, and so it is advised to use pointers to objects on the stack sparingly if at all. In rust, the compiler will statically determine if a pointer to an object on the stack could escape the function, and if so will fail to compile.
  - zeroxfe 7y ago
    > In another language you'd risk having a pointer to invalid memory when the function returns if the pointer escapes the function, and so it is advised to use pointers to objects on the stack sparingly if at all. Just a nitpick, this is only true for non-garbage-collected (or refcounted) languages. :-)
    - lmkg 7y ago
      Well, if you're gonna nitpick... A garbage-collected language wouldn't let you allocate such items on the stack in the first place. GC languages tend not to let you choose where to allocate in the first place, and have obligatory heap semantics for reference types. Some compilers (including Go and Java, to my knowledge) will attempt to optimize the implementation to stack allocation when possible using escape analysis, but this is less precise, and more opaque, then Rust's allocation. And you won't get feedback if it stops working. So, by GP's comment of "unheard of (or just plain dangerous)", the "unheard-of" applies to GC languages and "plain dangerous" would apply non-GC languages.
sitkack 7y ago
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 engineering, there are trade offs. RiiR can and often is a valid choice. The author talks about "introducing bugs", under an engineering approach to a rewrite, more like a language-port, rewrites can _find_ a lot of bugs. One such way is as follows. 1. keep the same interface in the new system, client code should work against either system. 2. have a body of integration tests, capture these from the field OR write a small collection of orthogonal tests, somewhere between unit and integration. 3. use the tooling, bindgen, etc and generate as much of the interface programmatically as possible. 4. iterate on the port, doing differential testing against both systems. Doing a language port is comparable in work to long term maintenance and refactoring of an existing codebase. As the tooling gets better, RiiR will be more of a smooth oxidization. If you own the C/C++ that could possibly get rewritten, I'd think one needs to rationalize NOT RiiR. Better tooling (IDE, build), perf tooling is improving, low bug count, increased team velocity, build is improved, etc. But the biggest reason to RiiR is safety. Integrating a body of C/C++ code into your rust codebase introduces a huge amount of unsafe code, much worse than surrounding your entire rust program with unsafe { }. At least do what is outlined in the article but ALSO compile the native code into Wasm and run it from within a sandbox. edit, something like a library for reading (parsing) a file format, should absolutely be RiiR or run from a sandbox. Data parsing and memory corruption vulnerabilities are excellent dance partners. [1] see PCA https://en.wikipedia.org/wiki/Principal_component_analysis https://en.wikipedia.org/wiki/Principal_component_analysis
- minraws 7y ago
  I would like to add my 2 cents, TBH I don't see a future where RIIR every piece of software would make sense, and I think you sort of put it in there somewhere in your comments. But yes I do see that for many it would and for those, RIIR would IMHO be an incremental process of oxidizing your project to the point that there's nothing left but Rust. Writing something from scratch and waiting for it to finish is the biggest problem we face, cause eventually the will to continue with the effort just dies. But creating a meaningful ground not just some "safer" bindings does help in inviting others to help share the effort as well. So hopefully people will be smart and identify what they should do for their projects, should it be a rewrite or should it be a new feature that you write in Rust. :) And no I don't think bindings are the solution to anything, they serve no purpose in Rust community as a long term measure, you shouldn't have to sacrifice safety and/or performance incase of high level language.
jamil7 7y ago
Archived link, I think HN knocked over the server: https://web.archive.org/web/20191023134247/http://adventures.michaelfbryan.com/posts/how-not-to-riir/ https://web.archive.org/web/20191023134247/http://adventures...
mirekrusin 7y ago
Oh no, it's not available, maybe you could rewrite your website in rust to handle the load? ;) ...this is tongue-in-cheek comment. I do agree with the author, "rust rewrite" alternative of wrapping c library is way better in many cases for well established or legacy libs. However it depends on the momentum you can bring - as pure rust implementation for widely used areas can benefit from compiler grinding through it. I can see rust written low level libraries used across all high-level languages in the near future.
asdfman123 7y ago
> 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).
- gpderetta 7y ago
  This is a very negative comment. Except I have seen it happen many times.
- Franciscouzo 7y ago
  It's called resume driven development, and the reason it's done is because it helps those who do it get jobs
  - shantly 7y ago
    As long as companies keep expecting experience in very specific technologies (only at work—400 hours on a hobby codebase don't count for as much as 40 hours writing something at a job for determining competence in a language or framework or whatever, it seems) this will keep happening. It's really, really dumb, but there's little other choice for folks who want to keep their skills (=the names of tools & languages they've used to write something for pay) up to date (=trendy high-paying buzzword compliant). Doubly true if you're not all-in on one of the major Bigcorp silos (Java, C#).
    - royjacobs 7y ago
      At a previous job I worked with someone who didn't see a buzzword they didn't like. Since nobody was stopping them, they designed an incredibly convoluted system using all the latest tech. In the end we replaced it with a JVM server and a Postgres database. I occasionally check their LinkedIn and they're still spending 12-15 months every time at companies, being CTO or Big Data Strategist or whatever.
jchw 7y ago
> why would you be better equipped to write a library for some domain-specific purpose than the original author? This is how you avoid growing as a programmer.
- xwolfi 7y ago
  But that's how you grow as a software shipper. Our job is not to program crap again and again, it's to deliver some value for the high fees we charge. Rewritting a working library to migrate language is really hard to defend...
  - jchw 7y ago
    No it’s not. You didn’t write it the first time, and grow from writing it the first time. Writing and shipping something in a new programming language is a fantastic way to learn both. This has only become contentious as people try to come up for a reason why rewriting things in Rust is bad, when really it is about as benign as trends go. I never heard the same complaints about rewriting things in Go (another language I love, btw) and even JS had less naysayers somehow. You may question the usefulness of having “x but in Rust” and that is fair. However, people keep answering the reasons why you might do something like this and yet like amnesia the same bad opinions come out again next time. — Sincerely, someone who also ships.
    - empthought 7y ago
      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.
      - jchw 7y ago
        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 supposed to learn?! People write NES emulators all the time even though they already exist. While most are purely for practice it doesn’t really matter: they wanted to write it, they wrote it, they learned. Discouraging people from writing something that they want to write is upsetting to me.
adrianmonk 7y ago
> 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 could be improved, code is in a poor state, etc.), and you're deciding between languages. In that case, a rewrite could be productive even if you didn't use Rust. (3) You have mature software that appears relatively free of obvious, known bugs, but it's written in an unsafe language, and it would be valuable to have the additional confidence that a safe language could provide. Security-sensitive or other critical applications are where this is most likely to make sense.
- Skunkleton 7y ago
  (4) You want to develop new components in rust, but it has to integrate with your existing components somehow.
  - zbentley 7y ago
    Why not use ffi for this case? Many languages have robust support for linking to Rust code.
    - gameswithgo 7y ago
      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)
      - viraptor 7y ago
        Having everything available in Rust code also means you don't have to do lots of extra work for cross-compilation.
gatherhunterer 7y ago
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.
- resoluteteeth 7y ago
  I don't see how the meaning of the phrases “How to not RIIR” and “How not to RIIR” is different.
  - cmyr 7y ago
    It's subtle. The second phrasing ("how not to x") is idiomatic, and means, roughly, "some things that you should not do when you do x", or "an example of how you should not go about doing x." So, an article titled, say, "how not to paint your house" would be expected to outline things to avoid when painting your house, and "how to not paint your house" could just be "go for a bike ride instead."
  - FreeFull 7y ago
    I would expect "How not to RIIR" to be some study of RIIR gone wrong, and "How to not RIIR" to be a guide.
  - laputan_machine 7y ago
    IMHO: 'How not to x' articles are typically self-deprecating articles that do x, but are critical of how they approached it and lessons learnt 'How to not x' is more explicit, i.e. How to avoid doing x
  - deleted 7y ago
    [deleted]
HankB99 7y ago
I don't think I've ever met a developer who didn't want to rewrite their predecessor's code and that includes the one I see in the mirror. Doing it in a different language would definitely be more interesting. Do we admit that this is a factor in the decision to rewrite vs. reuse?
- FpUser 7y ago
  "I don't think I've ever met a developer who didn't want to rewrite their predecessor's code and that includes the one I see in the mirror" Allow me to introduce myself ;) I mostly work on new products and rewriting to me just a waste of time. I am interested in creating features that give actual ROI. The only time I rewrite a piece of code is if said piece presents a major problem (bugs, performance etc)
  - HankB99 7y ago
    Pleased to meet you!
jaredtn 7y ago
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.
- zozbot234 7y ago
  > 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.
xvilka 7y ago
There is an automated tool - c2rust[1], automating a huge chunk of the translation from C to Rust. Moreover, it has a refactoring tool[2] that is scriptable in Lua. One of the good examples of such conversion (still not finished though), while still producing the same output is a rewrite[3][4] of XeTeX engine to Rust (as part of Tectonic[5] engine). It is able to parse arXiv articles dump and generate valid PDFs still. There is some concept[6] of converting Java to Rust, but it is far from being as useful as c2rust tool. Would be nice to integrate with c2rust somehow, if someone wants to help. [1] https://github.com/immunant/c2rust https://github.com/immunant/c2rust [2] https://c2rust.com/manual/c2rust-refactor/index.html https://c2rust.com/manual/c2rust-refactor/index.html [3] https://github.com/tectonic-typesetting/tectonic/issues/459 https://github.com/tectonic-typesetting/tectonic/issues/459 [4] https://github.com/crlf0710/tectonic/tree/oxidize https://github.com/crlf0710/tectonic/tree/oxidize [5] https://tectonic-typesetting.github.io/en-US/ https://tectonic-typesetting.github.io/en-US/ [6] https://github.com/aschoerk/converter-page https://github.com/aschoerk/converter-page
- peatmoss 7y ago
  I’ve sort of wondered if there isn’t a possibility for ML driven decompilers that produce idiomatic source code from a given byte code.
- svat 7y ago
  I wrote a comparison of the quality of this autogenerated C2rust code versus the original sources (WEB code in this case), the last time this was posted: https://news.ycombinator.com/item?id=21176806 https://news.ycombinator.com/item?id=21176806 (Though it's not a fair comparison as this particular automatic translation itself started from automatically translated C code, for unclear reasons.)
  - xvilka 7y ago
    Probably because there is no automated translator from WEB? And unlikely there will ever be.
- duneroadrunner 7y ago
tolodolo 7y ago
Dang is a massive tool.
vast 7y ago
The linked RIIR post pretty much described 2016 the behaviour of people shown in this thread. It is hilarious that seeing the arguing for RIIR in this context. Rewriting in some language is a matter of skill and preference. To even consider a rewrite there should be a rational reason, i.e. it is broken or can't work in the ecosystem. For fun and learning you can do what you want, of course.
lubesGordi 7y ago
Here's another article that is maybe a little more terse about how to write wrappers for C/C++ libs in Rust. https://medium.com/dwelo-r-d/using-c-libraries-in-rust-13961948c72a https://medium.com/dwelo-r-d/using-c-libraries-in-rust-13961...
deleted 7y ago
[deleted]
gattr 7y ago
I have rewritten my small-ish image processing library [0] in Rust (from C) and liked it! I mainly wanted to learn, also Rust forced me to improve the API a bit. [0] https://github.com/GreatAttractor/libskry_r https://github.com/GreatAttractor/libskry_r
brendangregg 7y ago
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) ignoring the value of engineering experience, and (C) making a major decision for an open source project (rewriting it) without collaboration with the current maintainers. (C) is anti-collaborative, and an extreme measure that should only happen in extreme circumstances (not "just because it might be better"). At my employer, the number one reason (I'm aware of) to open source our internal software is to solicit collaboration from other companies. Take away collaboration, and it's going to be a harder sell to open source anything.
- _bxg1 7y ago
  This is a good point. And unfortunately, in a long-lived language the network effect means you have almost no hope of moving a whole community over to a new language at once. Just look at what happened (or rather, didn't happen) with Python 2 libraries. And that was a less-old and less-permeated language than C(++). So maybe instead of "rewrite it in Rust", the answer is "build a new solution in Rust that meets the needs of a community of people who already use Rust".
- deleted 7y ago
  [deleted]
- orange8 7y ago
  > (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.
  - scottlamb 7y ago
    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 https://news.ycombinator.com/item?id=16600219 [2] https://news.ycombinator.com/item?id=20001570 https://news.ycombinator.com/item?id=20001570
mww09 7y ago
Generating C/C++ bindings in Rust is unfortunately still quite a hassle from my experience: Often C libraries end up with important functions as static inline in header files (these do not get translated automatically by bindgen). If the library uses the macro system to rename functions, these too won't show up as symbols in your library (so you'd have to manually define those names too). Then bindgen often pulls in too many dependencies and I end up manually white/blacklisting what symbols I want/don't want (and track changes through multiple versions). That being said, it's a hard problem and Rust has still one of the better toolings for FFI from what I've seen in other languages.
kragen 7y ago
Where are you getting your CHM files? If you're getting them from untrusted sources — that is, people you wouldn't give your password to — you probably don't want to pass them to a buggy C library. That's just begging to get pwned! The only way this seems like a reasonable idea is if your CHM files are generated by your own software or by something like SafeDocs: https://www.darpa.mil/program/safe-documents https://www.darpa.mil/program/safe-documents Wrapping your buggy C library in Rust isn't going to give you the kind of security against malicious data that a rewrite in Rust would give you.
fouc 7y ago
I find it interesting that Michael apparently keeps his git-backed projects in ~/Documents/. Does anyone else do this?
- josteink 7y ago
  I think both VSCode and Visual Studio defaults to this if you clone a repo using the editor GUI.
ivoras 7y ago
> Rust gives you the power to do things which would be unheard of (or just plain dangerous) in other languages Ummm.... any pointers as to what the author is talking about?

452 points by yarapavan 7y ago

adrusi 7y ago

The title should be "how to not" rather than "how not to".

steveklabnik 7y ago
It really depends on your opinion on split infinitives. Both are correct.
- cannam 7y ago
  Surely "How Not To..." is typically used when you're talking of a bad way to do something, or a way to fail - so this sounds like it's describing a bad way to rewrite something in Rust, which is not the case. It also isn't the wording used in the original article title.
  - steveklabnik 7y ago
    > so this sounds like it's describing a bad way to rewrite something in Rust, which is not the case. I think this kind of title is trying to do exactly that, or at least, that's how I took it. > It also isn't the wording used in the original article title. This is a good reason to switch it, for sure. I didn't realize this, if you had led with that, I wouldn't have said anything :)
    - lmkg 7y ago
      > I think this kind of title is trying to do exactly that, or at least, that's how I took it I took the exact opposite: This article is describing an alternative to RiiR, so that RiiR is avoided when not needed.
      - steveklabnik 7y ago
        I don't disagree with you is that the thesis of the article is "don't re-write something in Rust." What I was trying to say is that I think the title is making a joke; it's saying "how to re-write something in Rust badly", because well, it's not re-writing it in Rust at all.
        aidenn0 7y ago
        I thought the title was making a joke, but then I read the article and IMO the actual article title of "How to not RiiR" is much more indicative of it's content than the HN title of "How Not to RiiR"
  - coldtea 7y ago
    >so this sounds like it's describing a bad way to rewrite something in Rust, which is not the case. Actually, this is the case. It describes the bad way (and bad reasons) to rewrite something in Rust.
- goto11 7y ago
  No they have different meaning. How to not X = How to avoid doing X How not to X = The wrong way to do X
coldtea 7y ago
Not really. "How not to" is a common idiom (like "X considered harmful" for such advice articles (regardless of correctness).
- aidenn0 7y ago
  The TFA is literally "How to not" as in "how to avoid" not "How not to" which would be "Here's the wrong way to do it"
dang 7y ago
Good catch! Changed now.

smt88 7y ago

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 likely to pay dividends by saving developers -- especially ones who are new to the library -- a lot of time.

epage 7y ago
Another reason I'd prefer things to be rewritten in Rust rather than using bindings is that calling out to external build systems introduces its own set of problems. I've run into the most problems with C-based dependencies (slower builds, OOM errors, confusion over static vs dynamic linking, etc) than any pure-Rust dependency.
MichaelFBryan 7y ago
i'm more thinking about libraries like tensorflow, ssh, or libgit2. 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).
- erik_seaberg 7y ago
  There's no way to write a safe interface for a C library like OpenSSH where critical vulnerabilities to malicious payloads have been found and exploited. All this stuff needs to be replaced if we're ever to to have a trustworthy foundation.

jacobush 7y ago

"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 something elaborate like that.) (Then again, from a practical standpoint the reasoning may be good. Maybe, even likely, the C library is very good and very battle tested. And very likely, my novice would be re-implementation in Rust would not be very good.)

steveklabnik 7y ago
Yes, this is an important distinction about "unsafe" in Rust. https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html is a good starting place for learning about this.
estebank 7y ago
One but difference of this approach over just using the original library directly is that now you have a type system that can enforce more invariants than it is possible in C and that the library was previously already relying on. If the (now reduced) API surface happens to still expose a bug, it can both be fixed in the library and/or protected against in the API.
gbear605 7y ago
A lot of the time, the danger with unsafe code is doing a thing like passing a null pointer into a function that can’t handle null pointers, or using something before it is instantiated. So the interface should force those things not to happen (with the type system or a constructor or...). This doesn’t prevent the c code from being buggy, but it makes it much easier to use, since you can ensure that you’re maintaining the invariants.
SAI_Peregrinus 7y ago
Also even if you do plan to re-implement the C library in Rust it's still a good idea to do this step (make a safe wrapper around the FFI bindings) first. It lets you set up your Rust test cases, and gives you a step to design what the Rust API will look like. You can proceed to pull bits of the C out and into native Rust, all while whatever you've built on top doesn't have to change.

dmm 7y ago

> This may be problematic because it’ll require all users of our chmlib crate (and their users) to have Autotools installed. Autoconf creates a portable shell script, right? No need to have it installed just to build the project.

steveklabnik 7y ago
"portable" to different Unices, right? I'm on Windows, for example.
- dmm 7y ago
  Sure but that's a different problem than "it’ll require all users of our chmlib crate (and their users) to have Autotools installed." I'm just being pedantic. It's a problem...
- bluGill 7y ago
  Autotools is rarely portable. I've been doing a lot of cross compiling recently: the vast majority of autotools projects can't be cross compiled. Sure autotools itself supports it, but something required to make it work didn't get connected up and so you can't do it. If you want to natively compile on a fairly recent linux with the common standard libraries autotools works well. Even though autotools was written to work around these differences, in most cases the developer didn't hook into autotools detecting that difference and so it doesn't work.
  - monocasa 7y ago
    Cross compiling to what? Autotools is probably the most portable piece of software out there as far as Unices are concerned.
    - bluGill 7y ago
      Embedded Linux on arm. Nothing very far out really. Note that I'm careful not to blame autotools, it is the user's fault, there are a couple projects that use autotools and cross compile easily. The vast majority do not. CMake based projects almost always cross compile easily.

StreamBright 7y ago

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?

steveklabnik 7y ago
All of Rust's complexity for strings comes out of complexity due to UTF-8. Well, a tiny bit comes from the fact that Rust has pointers too, but most of it is UTF-8. Did you happen to read the book? We cover strings early because this is a common pain point. Also, if you have something more detailed than "get strings out of libraries", I can give better advice. It's tough to tell what the actual issue is.
- StreamBright 7y ago
  Like this: use sha2::{Sha256, Digest}; fn main() { let mut hasher = Sha256::new(); hasher.input(b"hello world"); let result = hasher.result(); ?? } How do I get a string with the hash value? Which chapter of which book should I read?
  - aisengard 7y ago
    The hash value is a bunch of bytes. A "string" would need to be some encoded version of those bytes, commonly hexadecimal representation.
  - chousuke 7y ago
    I think you can use format!() to format the byte array as a hex string. The result of a hash is never a string, so it makes sense that you'd need another step to print it as one.
  - steveklabnik 7y ago
    Ah, I see! So yeah, this isn't something the book covers, so that would not be helpful. In this case, the hash ends up being raw bytes. So the question is, what are you trying to do with this hash? Being a bunch of bytes, this may not be valid UTF-8 (and in this case, is not ASCII, let alone UTF-8). One option is to encode to base64: use sha2::{Sha256, Digest}; use base64; fn main() { let mut hasher = Sha256::new(); hasher.input(b"hello world"); let result = hasher.result(); let encoded = base64::encode(&result); assert_eq!("uU0nuZNNPgilLlLX2n2r+sSE7+N6U4DukIj3rOLvzek=", encoded); } But yeah, you can't exactly "get a string" out of a random bag of bytes unless you know how you want that bag of bytes to be represented, encoding wise. That's not exactly a satisfying answer, but such are strings!

fmakunbound 7y ago

> Rust gives you the power to do things which would be unheard of (or just plain dangerous) in other languages What are examples of the unheard of things?

nicoburns 7y ago
Unheard of might be overstating it, but in Rust you can do things like pass references to other threads and aggressively parallelise things (without lots of defensive copies) without worrying about it causing bugginess later.
mmaurizi 7y ago
Passing around pointers to objects on the stack. In another language you'd risk having a pointer to invalid memory when the function returns if the pointer escapes the function, and so it is advised to use pointers to objects on the stack sparingly if at all. In rust, the compiler will statically determine if a pointer to an object on the stack could escape the function, and if so will fail to compile.
- zeroxfe 7y ago
  > In another language you'd risk having a pointer to invalid memory when the function returns if the pointer escapes the function, and so it is advised to use pointers to objects on the stack sparingly if at all. Just a nitpick, this is only true for non-garbage-collected (or refcounted) languages. :-)
  - lmkg 7y ago
    Well, if you're gonna nitpick... A garbage-collected language wouldn't let you allocate such items on the stack in the first place. GC languages tend not to let you choose where to allocate in the first place, and have obligatory heap semantics for reference types. Some compilers (including Go and Java, to my knowledge) will attempt to optimize the implementation to stack allocation when possible using escape analysis, but this is less precise, and more opaque, then Rust's allocation. And you won't get feedback if it stops working. So, by GP's comment of "unheard of (or just plain dangerous)", the "unheard-of" applies to GC languages and "plain dangerous" would apply non-GC languages.

sitkack 7y ago

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 engineering, there are trade offs. RiiR can and often is a valid choice. The author talks about "introducing bugs", under an engineering approach to a rewrite, more like a language-port, rewrites can _find_ a lot of bugs. One such way is as follows. 1. keep the same interface in the new system, client code should work against either system. 2. have a body of integration tests, capture these from the field OR write a small collection of orthogonal tests, somewhere between unit and integration. 3. use the tooling, bindgen, etc and generate as much of the interface programmatically as possible. 4. iterate on the port, doing differential testing against both systems. Doing a language port is comparable in work to long term maintenance and refactoring of an existing codebase. As the tooling gets better, RiiR will be more of a smooth oxidization. If you own the C/C++ that could possibly get rewritten, I'd think one needs to rationalize NOT RiiR. Better tooling (IDE, build), perf tooling is improving, low bug count, increased team velocity, build is improved, etc. But the biggest reason to RiiR is safety. Integrating a body of C/C++ code into your rust codebase introduces a huge amount of unsafe code, much worse than surrounding your entire rust program with unsafe { }. At least do what is outlined in the article but ALSO compile the native code into Wasm and run it from within a sandbox. edit, something like a library for reading (parsing) a file format, should absolutely be RiiR or run from a sandbox. Data parsing and memory corruption vulnerabilities are excellent dance partners. [1] see PCA https://en.wikipedia.org/wiki/Principal_component_analysis https://en.wikipedia.org/wiki/Principal_component_analysis

minraws 7y ago
I would like to add my 2 cents, TBH I don't see a future where RIIR every piece of software would make sense, and I think you sort of put it in there somewhere in your comments. But yes I do see that for many it would and for those, RIIR would IMHO be an incremental process of oxidizing your project to the point that there's nothing left but Rust. Writing something from scratch and waiting for it to finish is the biggest problem we face, cause eventually the will to continue with the effort just dies. But creating a meaningful ground not just some "safer" bindings does help in inviting others to help share the effort as well. So hopefully people will be smart and identify what they should do for their projects, should it be a rewrite or should it be a new feature that you write in Rust. :) And no I don't think bindings are the solution to anything, they serve no purpose in Rust community as a long term measure, you shouldn't have to sacrifice safety and/or performance incase of high level language.

jamil7 7y ago

Archived link, I think HN knocked over the server: https://web.archive.org/web/20191023134247/http://adventures.michaelfbryan.com/posts/how-not-to-riir/ https://web.archive.org/web/20191023134247/http://adventures...

mirekrusin 7y ago

Oh no, it's not available, maybe you could rewrite your website in rust to handle the load? ;) ...this is tongue-in-cheek comment. I do agree with the author, "rust rewrite" alternative of wrapping c library is way better in many cases for well established or legacy libs. However it depends on the momentum you can bring - as pure rust implementation for widely used areas can benefit from compiler grinding through it. I can see rust written low level libraries used across all high-level languages in the near future.

asdfman123 7y ago

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

gpderetta 7y ago
This is a very negative comment. Except I have seen it happen many times.
Franciscouzo 7y ago
It's called resume driven development, and the reason it's done is because it helps those who do it get jobs
- shantly 7y ago
  As long as companies keep expecting experience in very specific technologies (only at work—400 hours on a hobby codebase don't count for as much as 40 hours writing something at a job for determining competence in a language or framework or whatever, it seems) this will keep happening. It's really, really dumb, but there's little other choice for folks who want to keep their skills (=the names of tools & languages they've used to write something for pay) up to date (=trendy high-paying buzzword compliant). Doubly true if you're not all-in on one of the major Bigcorp silos (Java, C#).
  - royjacobs 7y ago
    At a previous job I worked with someone who didn't see a buzzword they didn't like. Since nobody was stopping them, they designed an incredibly convoluted system using all the latest tech. In the end we replaced it with a JVM server and a Postgres database. I occasionally check their LinkedIn and they're still spending 12-15 months every time at companies, being CTO or Big Data Strategist or whatever.

jchw 7y ago

> why would you be better equipped to write a library for some domain-specific purpose than the original author? This is how you avoid growing as a programmer.

xwolfi 7y ago
But that's how you grow as a software shipper. Our job is not to program crap again and again, it's to deliver some value for the high fees we charge. Rewritting a working library to migrate language is really hard to defend...
- jchw 7y ago
  No it’s not. You didn’t write it the first time, and grow from writing it the first time. Writing and shipping something in a new programming language is a fantastic way to learn both. This has only become contentious as people try to come up for a reason why rewriting things in Rust is bad, when really it is about as benign as trends go. I never heard the same complaints about rewriting things in Go (another language I love, btw) and even JS had less naysayers somehow. You may question the usefulness of having “x but in Rust” and that is fair. However, people keep answering the reasons why you might do something like this and yet like amnesia the same bad opinions come out again next time. — Sincerely, someone who also ships.
  - empthought 7y ago
    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.
    - jchw 7y ago
      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 supposed to learn?! People write NES emulators all the time even though they already exist. While most are purely for practice it doesn’t really matter: they wanted to write it, they wrote it, they learned. Discouraging people from writing something that they want to write is upsetting to me.

adrianmonk 7y ago

> 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 could be improved, code is in a poor state, etc.), and you're deciding between languages. In that case, a rewrite could be productive even if you didn't use Rust. (3) You have mature software that appears relatively free of obvious, known bugs, but it's written in an unsafe language, and it would be valuable to have the additional confidence that a safe language could provide. Security-sensitive or other critical applications are where this is most likely to make sense.

Skunkleton 7y ago
(4) You want to develop new components in rust, but it has to integrate with your existing components somehow.
- zbentley 7y ago
  Why not use ffi for this case? Many languages have robust support for linking to Rust code.
  - gameswithgo 7y ago
    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)
    - viraptor 7y ago
      Having everything available in Rust code also means you don't have to do lots of extra work for cross-compilation.

gatherhunterer 7y ago

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.

resoluteteeth 7y ago
I don't see how the meaning of the phrases “How to not RIIR” and “How not to RIIR” is different.
- cmyr 7y ago
  It's subtle. The second phrasing ("how not to x") is idiomatic, and means, roughly, "some things that you should not do when you do x", or "an example of how you should not go about doing x." So, an article titled, say, "how not to paint your house" would be expected to outline things to avoid when painting your house, and "how to not paint your house" could just be "go for a bike ride instead."
- FreeFull 7y ago
  I would expect "How not to RIIR" to be some study of RIIR gone wrong, and "How to not RIIR" to be a guide.
- laputan_machine 7y ago
  IMHO: 'How not to x' articles are typically self-deprecating articles that do x, but are critical of how they approached it and lessons learnt 'How to not x' is more explicit, i.e. How to avoid doing x
- deleted 7y ago
  [deleted]

HankB99 7y ago

I don't think I've ever met a developer who didn't want to rewrite their predecessor's code and that includes the one I see in the mirror. Doing it in a different language would definitely be more interesting. Do we admit that this is a factor in the decision to rewrite vs. reuse?

FpUser 7y ago
"I don't think I've ever met a developer who didn't want to rewrite their predecessor's code and that includes the one I see in the mirror" Allow me to introduce myself ;) I mostly work on new products and rewriting to me just a waste of time. I am interested in creating features that give actual ROI. The only time I rewrite a piece of code is if said piece presents a major problem (bugs, performance etc)
- HankB99 7y ago
  Pleased to meet you!

jaredtn 7y ago

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.

zozbot234 7y ago
> 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.

xvilka 7y ago

There is an automated tool - c2rust[1], automating a huge chunk of the translation from C to Rust. Moreover, it has a refactoring tool[2] that is scriptable in Lua. One of the good examples of such conversion (still not finished though), while still producing the same output is a rewrite[3][4] of XeTeX engine to Rust (as part of Tectonic[5] engine). It is able to parse arXiv articles dump and generate valid PDFs still. There is some concept[6] of converting Java to Rust, but it is far from being as useful as c2rust tool. Would be nice to integrate with c2rust somehow, if someone wants to help. [1] https://github.com/immunant/c2rust https://github.com/immunant/c2rust [2] https://c2rust.com/manual/c2rust-refactor/index.html https://c2rust.com/manual/c2rust-refactor/index.html [3] https://github.com/tectonic-typesetting/tectonic/issues/459 https://github.com/tectonic-typesetting/tectonic/issues/459 [4] https://github.com/crlf0710/tectonic/tree/oxidize https://github.com/crlf0710/tectonic/tree/oxidize [5] https://tectonic-typesetting.github.io/en-US/ https://tectonic-typesetting.github.io/en-US/ [6] https://github.com/aschoerk/converter-page https://github.com/aschoerk/converter-page

peatmoss 7y ago
I’ve sort of wondered if there isn’t a possibility for ML driven decompilers that produce idiomatic source code from a given byte code.
svat 7y ago
I wrote a comparison of the quality of this autogenerated C2rust code versus the original sources (WEB code in this case), the last time this was posted: https://news.ycombinator.com/item?id=21176806 https://news.ycombinator.com/item?id=21176806 (Though it's not a fair comparison as this particular automatic translation itself started from automatically translated C code, for unclear reasons.)
- xvilka 7y ago
  Probably because there is no automated translator from WEB? And unlikely there will ever be.
duneroadrunner 7y ago

tolodolo 7y ago

Dang is a massive tool.

vast 7y ago

The linked RIIR post pretty much described 2016 the behaviour of people shown in this thread. It is hilarious that seeing the arguing for RIIR in this context. Rewriting in some language is a matter of skill and preference. To even consider a rewrite there should be a rational reason, i.e. it is broken or can't work in the ecosystem. For fun and learning you can do what you want, of course.

lubesGordi 7y ago

Here's another article that is maybe a little more terse about how to write wrappers for C/C++ libs in Rust. https://medium.com/dwelo-r-d/using-c-libraries-in-rust-13961948c72a https://medium.com/dwelo-r-d/using-c-libraries-in-rust-13961...

deleted 7y ago

[deleted]

gattr 7y ago

I have rewritten my small-ish image processing library [0] in Rust (from C) and liked it! I mainly wanted to learn, also Rust forced me to improve the API a bit. [0] https://github.com/GreatAttractor/libskry_r https://github.com/GreatAttractor/libskry_r

brendangregg 7y ago

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) ignoring the value of engineering experience, and (C) making a major decision for an open source project (rewriting it) without collaboration with the current maintainers. (C) is anti-collaborative, and an extreme measure that should only happen in extreme circumstances (not "just because it might be better"). At my employer, the number one reason (I'm aware of) to open source our internal software is to solicit collaboration from other companies. Take away collaboration, and it's going to be a harder sell to open source anything.

_bxg1 7y ago
This is a good point. And unfortunately, in a long-lived language the network effect means you have almost no hope of moving a whole community over to a new language at once. Just look at what happened (or rather, didn't happen) with Python 2 libraries. And that was a less-old and less-permeated language than C(++). So maybe instead of "rewrite it in Rust", the answer is "build a new solution in Rust that meets the needs of a community of people who already use Rust".
deleted 7y ago
[deleted]
orange8 7y ago
> (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.
- scottlamb 7y ago
  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 https://news.ycombinator.com/item?id=16600219 [2] https://news.ycombinator.com/item?id=20001570 https://news.ycombinator.com/item?id=20001570

mww09 7y ago

Generating C/C++ bindings in Rust is unfortunately still quite a hassle from my experience: Often C libraries end up with important functions as static inline in header files (these do not get translated automatically by bindgen). If the library uses the macro system to rename functions, these too won't show up as symbols in your library (so you'd have to manually define those names too). Then bindgen often pulls in too many dependencies and I end up manually white/blacklisting what symbols I want/don't want (and track changes through multiple versions). That being said, it's a hard problem and Rust has still one of the better toolings for FFI from what I've seen in other languages.

kragen 7y ago

Where are you getting your CHM files? If you're getting them from untrusted sources — that is, people you wouldn't give your password to — you probably don't want to pass them to a buggy C library. That's just begging to get pwned! The only way this seems like a reasonable idea is if your CHM files are generated by your own software or by something like SafeDocs: https://www.darpa.mil/program/safe-documents https://www.darpa.mil/program/safe-documents Wrapping your buggy C library in Rust isn't going to give you the kind of security against malicious data that a rewrite in Rust would give you.

fouc 7y ago

I find it interesting that Michael apparently keeps his git-backed projects in ~/Documents/. Does anyone else do this?

josteink 7y ago
I think both VSCode and Visual Studio defaults to this if you clone a repo using the editor GUI.

ivoras 7y ago

> Rust gives you the power to do things which would be unheard of (or just plain dangerous) in other languages Ummm.... any pointers as to what the author is talking about?