Go implementation of the protocol

[neuroscr]

a clean room implementation of the protocol in golang to correct for correctness

[liilac]

I'd be keen to do this. I have significant experience in Go and use it as a primary language.

[liilac]

Would appreciate feedback on how much interest this is of.

Has been mentioned to @Haafingar as a potential sponsored project, along with #62.

@neuroscr

[KeeJef]

I am interested in this, but my view that we should aim to allocated the most resources initially to getting the protocol and network stable in the C++ implementation before moving to another language for which we are less tooled for.

[liilac]

This is a fair comment, though I feel it's worth adding that Go is very easy to pick up for developers experienced in other comparable languages such as C++.

As far as actual toolchains, Go is a lot simpler than C++ in that respect. go build handles the entirety of building, style auditing and such is handled by gofmt and such, etc.

I think it's also worth considering the potential for it to encourage contributions from a possibly broader audience than at present, Go being a lot more "interesting" language than C++ for many. While I question the methodology, see a relevant section of the Stack Overflow 2018 Developer Survey:

Go as one of the most loved langages

C++ as one of the most dreaded, similar to PHP

Thoughts @KeeJef ?

[liilac]

Note as well, my comments apply equally to a Rust implementation.

[KeeJef]

Again i would be concerned about allocation of our time, right now i think the most important thing is to build a usable product for the general public. Once the protocol and first implementation is more stable i think an alternate implementation would be desirable, however right now the project is undergoing large changes on a week by week basis and reproducing these changes in an alternate implementation would probably not be super useful.

My view is that we should tackle this when version 1.0.0 of Lokinet comes out, that would be when Service Nodes and Lokinet are fully integrated. Past that point we will still be making changes but the we should start to see much more stability both in the network and implementations.

[majestrate]

On Sat, Dec 08, 2018 at 09:58:30PM -0800, Lilac wrote: This is a fair comment, though I feel it's worth adding that Go is very easy to pick up for developers experienced in other comparable languages such as C++. As far as actual toolchains, Go is a lot simpler than C++ in that respect. `go build` handles the entirety of building, style auditing and such is handled by `gofmt` and such, etc. I think it's also worth considering the potential for it to encourage contributions from a possibly broader audience than at present, Go being a lot more "interesting" language than C++ for many. While I question the methodology, see a [relevant section](https://insights.stackoverflow.com/survey/2018/#most-loved-dreaded-and-wanted) of the [Stack Overflow 2018 Developer Survey](https://insights.stackoverflow.com/survey/2018/#most-loved-dreaded-and-wanted): Go as one of the most loved langages  C++ as one of the most dreaded, similar to PHP  Thoughts @KeeJef ?

for the record i don't think it's unreasonable to have a parallel implementation written by a neutral thrid party to test the correctnes of the reference implementation. i think the real question is if it should be funded or not.

…

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #65 (comment)

[liilac]

for the record i don't think it's unreasonable to have a parallel implementation written by a neutral thrid party to test the correctnes of the reference implementation. i think the real question is if it should be funded or not.
…

The present implementation seems like a bit of a mess at present. As a contributor, it's difficult to reason about it, and the barrier to contribution is high. I think there's underestimated value in a parallel implementation even just for cleaner and more correct code, as @majestrate pointed out.

[majestrate]

On Sun, Dec 09, 2018 at 12:46:59AM -0800, Kee Jefferys wrote: Again i would be concerned about allocation of our time, right now i think the most important thing is to build a usable product for the general public. Once the protocol and first implementation is more stable i think an alternate implementation would be desirable, however right now the project is undergoing large changes on a week by week basis and reproducing these changes in an alternate implementation would probably not be super useful.

i think it's a fine use of time for documentation purposes, we should encourage alternative implementations but probably not finance them as we don't have the resources for such.

My view is that we should tackle this when version 1.0.0 of Lokinet comes out, that would be when Service Nodes and Lokinet are fully integrated. Past that point we will still be making changes but the we should start to see much more stability both in the network and implementations.

i suspect it's unwise to wait for 1.0.0 as i2p and tor also never reached 1.0 after all this time.

…

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #65 (comment)

[viencokhi]

It would be great to see Go implementation, at least for client.