Please do not send features request for now

[jedisct1]

dnscrypt-proxy2 is still very new, and in beta, but the current goal is to release a stable version 2.0.0.

If features requests keep coming, this cannot happen, and it will remain in beta forever.

So, it's probably better to focus only on bugs and system-specific issues for now.

Thanks!

[ghost]

This might be the right place to thank you for your hard work :)

[GrizzlyJr]

thank you for your hard work and time to make better dnscrypt-proxy

[jedisct1]

Known issue: blocked suffixes (ex: *.local are logged in reverse (*lacol)). This has been fixed in 4f0c36ac270d62cc7cc1673192d2becfec002a9b and will be in the next beta.

[ghost]

Many thanks as well. I linger to discover the first release of DNScrypt-Proxy V2 and easily imagine the work it requires. It's in progress, 2.0.0beta6 already at this time. Not to say but written, V.1.9.5 has always ran flawlessly yet I "sort of" understand the improvements V2 will bring. We're all tuned!

[Tallefer]

Not to spoil the party, as I've enjoyed using DNScrypt proxy for quite some time, but — @jedisct1 could you please share some insights on switching to Go? I can totally understand the reason for using it for server-side software with all that light threads and such, but for end-users... I don't know, from what I've seen to this day on some projects it seems to differ just by binaries that are just TOO DAMN FAT. :) And while it is bearable on PCs (and to be perfectly honest, there's not too much of a size difference between that stripped static fat binary of v2 and a bunch of libs of v1), is v2 still runs as good as v1 on routers and similar "low power" devices? Because it is very important to have it there and generally to have as many options as possible for this kind of software. Have you considered other options? Something like Nim, perhaps? Also, seems like you've invested quite some time in Rust, was it deemed unsuitable for the task or there were some other reasons? I just want to know more pros and cons, more information to make educated choices. :) And of course, a big thank you for your great work!

[jedisct1]

@Tallefer It's been written in Go for many reasons. Social, technical and personal.

Nobody wants to learn C or write C any more. If you write a project in C today, you'll be maintaining it alone. Don't expect any external contributions. After a couple years, it can be quite depressing.

Go has a huge community, that keeps growing. And for good reasons. It's very easy to learn, similar to a scripting language, but it is also very versatile, easy to deploy, and performance is good. So, Go was a natural choice for a project more open and accessible to external contributors.

Go is also a perfect fit for that kind of servers. If you can model your application logic as something very linear, with very few shared states, Go let you write the code also in a very simple, linear way. Yet, no functions will block, there's no callback hell and no state machine to manage yourself. If you have a lot of shared state or need synchronization between clients, Go can become very ugly. There's no borrow checker to help you avoid races. Pesky bugs will be discovered at runtime rather than at compile time. But dnscrypt-proxy fits well in the first scenario.

I'm a huge fan of Rust and I've been using it since the 0.x days. But I wouldn't use it to write async servers today. There is still no well-defined way to do it. For the past 5 years, Rust tried many radically different approaches to async I/O, and they all failed. With Tokio being "reformed" due to its poor usability, and many independent frameworks working in a completely different way such as May, there's no assurance that you won't have to rewrite your code forever just to let it compile with newer versions of Rust. So, I'd rather wait for the dust to settle.

Go can produce binaries that will work everywhere, the same way. Look at all the precompiled dnscrypt-proxy binaries that are available for download. All built automatically, in a couple minutes, by the CI system, using the same Go compiler. No need for a cross-compilation toolchain. I can code and test on macOS, and know that it's going to work the same way on Windows, OpenWRT, Android, iOS, whatever. This is great for software that precisely must be available for many different platforms, including the ones I don't have access to.

Binaries are big. They can be compressed. I haven't done it yet, since these are still beta releases. Still, yes, they are bigger than C executables, because they are completely self-contained. They have zero dependencies. The same file will work on any Linux distribution, and on any version on that Linux distribution. You can upgrade, change or remove anything on the system, the Go binaries will keep working as usual. This is great, even from a support perspective. It prevents the classic "it works on my computer, sorry if it doesn't work on yours" situation.

Finally, I had virtually no experience with Go, so this was a good opportunity to learn the language and its ecosystem.

[Tallefer]

Thank you for such a detailed answer! Very useful bits of information about Go and Rust pros and cons. :) Seems like some of my guesses were right, for example:

Nobody wants to learn C or write C any more. If you write a project in C today, you'll be maintaining it alone. Don't expect any external contributions. After a couple years, it can be quite depressing.

Yes, I agree, and that's a very sad trend. I was honestly hoping that this wasn't the case here, but oh well... Btw, that's one reason why I pointed at Nim specifically, for it can be (very roughly) considered a higher level C replacement, because it uses C as a main intermediate language for producing binaries (and C is used practically everywhere and has strong line of highly optimized compilers), but with modules and other convenient things, which of course are also present in Go and Rust. The drawback is its lesser popularity, naturally. But I was hoping that keeping in use all those already written and tested libs and software of yours will outweigh the reasons to switch to Go and rewrite things from scratch. But I am a bit too late for that, I guess... :) What do you think of it, anyway? Is it too immature for now? For me Nim looks like a viable alternative for C that still has strong sides of it.

As for the size of binaries, I am mostly OK with that, as I stated earlier, I am just a bit worried for routers with little spare memory. UPXing a Go binary usually yields very good results, and in this case it is 1 285 632 bytes out of 4 549 120 bytes of original. Compressed unstripped versions were just shy of 1.5Mb.

Finally, I had virtually no experience with Go, so this was a good opportunity to learn the language and its ecosystem.

Totally fine with that. :) Especially with Rust seemingly out of the picture because of async problems — so there's not much alternatives left for this task and Go surely has a large set of already working libraries that can be used for reasonably fast prototyping and testing theories.

However, I am still not convinced about this one point:

But dnscrypt-proxy fits well in the first scenario.

I personally see dnscrypt-proxy more like a client application, with little to no need for distributed load or something like that, where Go has a nearly perfect application. Yes, I am aware that it can be used as a SOHO DNS or similarly scaled network service, but still — nothing what a good small C software can't handle well already, IMHO. :) But, inclusion of a DNS cache in v2 will help a great deal with that scenario, I think.