[siwatanejo]

I'm not a fan of Go. If anyone is interested in developing a Rust equivalent of this (all Rust with no C/C++ deps) I'm willing to pay for it, contact me at [e-mail] (end result can be opensource)

[arghwhat]

As someone who is personally a great fan of Rust, I have to say that this is a very defective attitude.

If you're not writing it yourself (WebRTC is super simple, and this tool is basically the absolute bare-bone example of it—make a pipe and transfer something over it), why in the world would you care about what language it is written in beyond whether the language is safe, performant enough, and not a nightmare to execute on the target PC?

If you're not making it, you don't get to pick the tools. Paying just to get decide tools for other people also seems like a really weird thing to do.

[siwatanejo]

> If you're not making it, you don't get to pick the tools. Paying just to get decide tools for other people also seems like a really weird thing to do.

I'm making it, I'm a dev (but focused on other projects). I want a specific solution that I can use from my projects. That's why I have technical requirements, not functional ones.

[GoblinSlayer]

Tools affect the result. If you ordered a tool in C, you will get more features than you wanted.

[arghwhat]

Tools, at a high level, do not affect what the end result is. Instead, it affects how end result is achieved.

In real life, languages are more than tools, but as long as features/performance/behavior is acceptable, it still reduces to an implementation detail.

(also, unless segfaults can be considered features, I don't see why C would get you anything extra.)

[pjmlp]

I guess black hats would consider memory corruption welcomed features.

[hackerpacker]

re: performance, as someone who isn't particularly enamored with rust or go (or any language), how is this thing only doing 16MBps local to local?!?

[Antonito]

Transfer is done via DTLS, a protocol on top of UDP, so we have to deal with packet loss and retransmission, which itself is controlled by SCTP. gfile uses pion/sctp[0] (via pion/webrtc[1]), and there has been some work going on to improve performances. :)

The performances used to be far worse, but with the recent improvements on pion/sctp, I felt gfile had become fast enough to be useful to some people.

[0]: https://github.com/pion/sctp

[1]: https://github.com/pion/webrtc

[binwiederhier]

You may want to look at QUIC. It'll be part of http/3 and it's on top of UDP. There is a go library called quic-go [1] that works quite well.

I was recently playing with a similar thing and used the lib [2]

[1] https://github.com/lucas-clemente/quic-go

[2] https://github.com/binwiederhier/natter

[hu3]

Paying to have something rewritten from Go to Rust out of spite.

This is a new low as far as hatred that I've witnessed.

[siwatanejo]

It's not so much "hey mom I want that too", but that I've been looking for a similar solution, but written in a decent language that I can consume from my app.