Lower contribution entry barrier

[TheJJ]

I really recommend using another language like C, C++ or Python3 to allow much more people to contribute. I'd recommend Python to allow really fast and easy progress, functionality is much more important than speed, especially in the early stage, later cython, pypy or c-extension can be used to speed up critical parts.

The target audience is barely familiar with Rust and doesn't want to learn a new language for just this project to contribute. Many people at our chair are looking forward to radeco, but are deterred by Rust.

This project is an awesome idea in general, but I can assure you it'll be way more successful if it's not based on Rust.

What do you think?

EDIT:
Switching language seems to be a bad option, so the other thing to improve is to lower the entry barrier by in-repo documentation.

[radare]

We have already discussed this topic a lot before starting the project. I think benefits of learning and using rust are way better than the caveats of not having enough users willing to contribute.

C and C++ are good languages but have a lot of issues in many aspects, in r2 we are suffering still segfaults, memleaks, abi incompatibilities, no automatic indentation, no documentation or generic testsuite, no good modularization system, no pkg system for managing dependencies, but we can live with them, maybe we get better results im short term but those languages are not really expressive enough to write a decompiler. Mainly because c++ templates and c macros are pure crap.

About python, i would say that no because dynamic languages are a pain to find bugs without running the code. Python indentation is a huge pain because it cant be done automatically and refactoring python code is awful. In fact, python works when the project is small, but when it grows you clearly see that the language was designed to write prototypes, cant really paralelize or thread the algorithms in a proper way. It have lot of memleaks and its slow. Also, module system of python is really bad, compared to others like nodejs. And i dont really want to keep maintaining that pydisease that is absorving the itsec world.

The only languages that are viable are:

• rust
• swift
• go

I could say that swift is a nice language but imho still needs 2-3 years to be mature.

Go is poorly expressive which tends to result in some spaguetti or automatic code generation to solve some limitations.

So i choosed rust, because its a stable language, it solves all the problems exposed previously. It is portable, fast, easy to paralelize or refactor. Comes with pkgsystem and dependency manager by default. Enforces good modularization practices, have automatic and standard indentation tool, doesnt have memleaks or overflow problems. Its native... And well, not everything is good.. It requires some learning and understanding of new concepts and shift your mind a bit to get in touch with this paradigm.. But again, i dont see any other better language for this task.

On 09 Dec 2015, at 15:02, Jonas Jelten notifications@github.com wrote:

I really recommend using another language like C, C++ or Python to allow much more people to contribute.

The target audience is barely familiar with Rust and doesn't want to learn a new language for just this project to contribute.

This project is an awesome idea in general, but I can assure you it'll be way more successful if it's not based on Rust.

What do you think?

—
Reply to this email directly or view it on GitHub.

[XVilka]

One more thing against Python - it will be slow, since decompilation is really hungry for a computing resources, especially memory. And more thing against OCaml (which is a standard for such kind of projects) - unlike Rust, OCaml support of Windows is very poor.

[TheJJ]

Yea you have a point, I'm just fearing that the project is stalling. I've never used Rust yet, but if you think it's really the best language for this, then it may be a good reason to start learning Rust.

To attract more developers, you may want to add some "don't fear we're using rust"-doc that briefly explains the Rust usage and project structure to lower the entry barrier.

[heapwolf]

imho, using rust is a pretty cool opportunity for new people to come into the project and an excuse to understand it from the ground up. I've been playing with Radare for the last few months and Rust for about the same amount of time. 👍 for rust! :)

[sushant94]

@TheJJ. I like the recommendation of adding a doc to lower the entry barrier. I don't mind adding this, just a quick question, what would you like to see in it though? Most of this project uses basic rust which can be picked up in about a week from the Rust Book. Maybe if you can let me know the difficulties you (or others face) in understanding this project, I can add something to help.

[TheJJ]

First of all, I have no idea how I'd set up a convenient development environment, so it should be documented. How do I arrange the folders, how do I compile the project for local usage without systemwide installation of the cargo?

This is the first thing I'd like to read somewhere, I'll think of more :)

[radare]

radeco builds like any other rust project.

just type cargo build. and you’ll get the binary in build/debug/target/radeco iirc.

cargo doesnt needs to be installed system wide. its just a binary that you can download from the rust site and put it anywhere (standalone).

maybe it will be good if sushant can write a blog post at radare.today about the first steps for a beginner to start with rust and radeco.

On 09 Dec 2015, at 18:16, Jonas Jelten notifications@github.com wrote:

First of all, I have no idea how I'd set up a convenient development environment, so it should be documented. How do I arrange the folders, how do I compile the project for local usage without systemwide installation of the cargo?

This is the first thing I'd like to read somewhere, I'll think of more :)

—
Reply to this email directly or view it on GitHub #13 (comment).

[TheJJ]

Jup indeed, but placing this inside the project repos might be better than just a blogpost.

If you say like any other rust project, how do radeco-lib and radeco interact then? And how is the lib found by radeco, because I really want to avoid having to install it systemwide etc. All these are things that should be documented in the repo please.

[jjdredd]

@XVilka you don't need performance in an application like this. This isn't a game engine, an HFT bot or heavy-load mathematics modelling like weather prediction.
This isn't the only concern, and isn't the biggest concern in radeco development.

[oleavr]

+1 for Rust.

Also agree on what's been said about Python and languages like it, it's just painful to scale to larger codebases. Regarding C and C++, you still need to get familiar with the libraries that are being used (there isn’t any one standard library), the concurrency model (which reactor implementation are you going to work with today?), complicated build systems, etc. However coming to a new language you don’t have old habits and assumptions to unlearn, and in the long run the project will benefit from using a language that’s a better fit for the problem at hand. Just imagine how many hours are lost tracking down heap corruptions, memory leaks, dealing with terrible build systems, lack of package management, etc., on top of the productivity already lost using a low-level language for building high-level things.

There’s no doubt that resistance to new languages is quite high though, just thinking about how Intel’s got brilliant engineers spending their time writing a C compiler that reverse-engineers your C code to recognize higher level patterns, e.g., that your for-loop is actually computing a sum-of-absolute-differences, and turning that into blazing fast vector code. But be careful, if it’s not 100% idiomatically written then it might not recognize the pattern and emit the slow and branchy code you’d expect from reading the C code. (The sane solution would be using a more expressive language, but instead we’re stuck inventing crazy technology so we can keep using the wrong tool for the job.)

[danpolanco]

Also +1 for Rust, which makes me wonder, will radare2 slowly be replaced by Rust as well?

[jjdredd]

another thing. you don't need a language like rust for a project like this. you need a very high level gc language to lower the development time.

[radare]

Go was the second choice for this task

On 07 Sep 2016, at 18:00, Judge_Dredd notifications@github.com wrote:

another thing. you don't need a language like rust for a project like this. you need a very high level gc language to lower the development time.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[TheJJ]

Code wins, so this will probably stick to Rust :)
Which is not a bad choice of course, just not as many people can contribute.