gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rewriting (part of) gnunet in another programming language (Was: Re:


From: Jeff Burdges
Subject: Re: Rewriting (part of) gnunet in another programming language (Was: Re: Debian 10 build warnings, wiki enhancements, Questions)
Date: Fri, 13 Dec 2019 14:41:29 +0000

> On 13 Dec 2019, at 09:26, ng0 <address@hidden> wrote:
> I am not against Rust, or Go. The perspective of an application
> developer is (usually) focused on other parts than the perspective
> of someone who distributes and builds applications in a multi-OS
> environment with more than one hardware.

Rust wants multi-archetecture multi-OS to work and continuously improves.  
Example:  https://github.com/rust-lang/rfcs/pull/2803  At the extreme, almost 
all Rust crate authors are sympathetic to no_std users, and some large Rust 
projects build no_std for WASM environments.  I think the two biggest hurdles 
are cargo’s bug that leaks dev dependency features into real dependency 
features, and the churn in the Rust error traits.  I’d think that goes beyond 
what gnunet requires.

Go is ideologically opposed to the required conditional compilation features.  
Go devs just tell you to be rich and hire all your dependencies' devs, so that 
you can properly vendor those dependencies.

Jeff

p.s.  Parity finished the initial migration of rust-libp2p and substrate over 
to Rust’s new futures and maybe some of the new async/await syntax.  It’s 
definitely possible now to know what gnunet code should generally look like in 
Rust.  It appears the “feud" between tokio and async-std creates some 
challenges for gnunet scale async code bases.  I’m sure that’ll improve in 
2020, but yeah there remains some uncertainty.


Attachment: signature.asc
Description: Message signed with OpenPGP


reply via email to

[Prev in Thread] Current Thread [Next in Thread]