Preferred language for NMControl-like things

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Preferred language for NMControl-like things

Post by biolizard89 »

somename wrote:
biolizard89 wrote:I asked on the Tor-Dev mailing list yesterday about why they're not building Python in Gitian. Here is the thread.

https://lists.torproject.org/pipermail/ ... 09422.html

Basically, they tried 2 years ago, and it was very hard, and they gave up. They haven't tried to do it since then. So, there is a chance that it has gotten easier since then (I think Joseph is going to talk to the Tor guys about it soon). Still, Go has a huge advantage here.
Following those links I checked the current status of 2 quoted bugs - they were related to Python 3.2 and were since both fixed:
https://bugs.winehq.org/show_bug.cgi?id=29764
https://bugs.winehq.org/show_bug.cgi?id=30515

(Personally I have no preference, not being a developer, but Python 3 seems easier to deal with from a user perspective).
Python3 is much better than Python2 for cross-compiling. However, it's still a big mess. Joseph can tell you all about the hoops he's jumping through for Armory's reproducible build effort. It's substantially more difficult than Go.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

hla
Posts: 46
Joined: Mon Nov 10, 2014 12:01 am
os: linux
Contact:

Re: Preferred language for NMControl-like things

Post by hla »

If "from a user perspective" you mean the actual binary distribution, then Go ships monolithic, statically linked (aside from libc/kernel32/etc.) binaries. Much less that can go wrong compared to a Python program, which either needs the runtime installed in a place where it can be found or needs a runtime bundled with the software.

somename
Posts: 80
Joined: Mon Sep 15, 2014 3:12 pm
os: windows

Re: Preferred language for NMControl-like things

Post by somename »

hla wrote:If "from a user perspective" you mean the actual binary distribution, then Go ships monolithic, statically linked (aside from libc/kernel32/etc.) binaries. Much less that can go wrong compared to a Python program, which either needs the runtime installed in a place where it can be found or needs a runtime bundled with the software.
I agree with that, but building from source is often a nightmare (when a newer version of Golang is required than shipped with your OS).

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Preferred language for NMControl-like things

Post by biolizard89 »

somename wrote:
hla wrote:If "from a user perspective" you mean the actual binary distribution, then Go ships monolithic, statically linked (aside from libc/kernel32/etc.) binaries. Much less that can go wrong compared to a Python program, which either needs the runtime installed in a place where it can be found or needs a runtime bundled with the software.
I agree with that, but building from source is often a nightmare (when a newer version of Golang is required than shipped with your OS).
The Gitian scripts that Tor uses don't appear to have that problem, since they build Go in a VM.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

hla
Posts: 46
Joined: Mon Nov 10, 2014 12:01 am
os: linux
Contact:

Re: Preferred language for NMControl-like things

Post by hla »

Code: Select all

      hl | ryan-c: while you're here, do you have any opinion on the proposal to switch to a Go-based middleware stack from Python?
  ryan-c | hl: go seems fine to me
Now in favour: brand0, Joseph, me, sugarpuff, Jeremy Rand, ryan-c
Yet to express a preference: domob, phelix, indolering, cassini

domob
Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: Preferred language for NMControl-like things

Post by domob »

hla wrote:

Code: Select all

      hl | ryan-c: while you're here, do you have any opinion on the proposal to switch to a Go-based middleware stack from Python?
  ryan-c | hl: go seems fine to me
Now in favour: brand0, Joseph, me, sugarpuff, Jeremy Rand, ryan-c
Yet to express a preference: domob, phelix, indolering, cassini
I don't particularly care (as long as there are good arguments by the supporters), as I'm not working with it anyway (most of the time). My impression is that Python is the most standard language, and I personally haven't looked at Go so far. Even if the language is easy to learn, it may still be a (psychological?) barrier to people who already know Python if they see "ah, this is in Go ... I would have to look it up". But if it makes things easier to distribute and make reproducible builds and all that, I'm all in favour of Go.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

Re: Preferred language for NMControl-like things

Post by phelix »

hla wrote:

Code: Select all

      hl | ryan-c: while you're here, do you have any opinion on the proposal to switch to a Go-based middleware stack from Python?
  ryan-c | hl: go seems fine to me
Now in favour: brand0, Joseph, me, sugarpuff, Jeremy Rand, ryan-c
Yet to express a preference: domob, phelix, indolering, cassini
Could you be more specific about what you are asking here? E.g. do you suggest that we dump all the NMControl code base now and create a go implementation?
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

hla
Posts: 46
Joined: Mon Nov 10, 2014 12:01 am
os: linux
Contact:

Re: Preferred language for NMControl-like things

Post by hla »

phelix wrote:Could you be more specific about what you are asking here? E.g. do you suggest that we dump all the NMControl code base now and create a go implementation?
I think the previous posts in this thread explain the motivations.

There is a pre-existing Go implementation, ncdns, which I wrote. Very likely we would start from here and evolve it as necessary.

phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

Re: Preferred language for NMControl-like things

Post by phelix »

hla wrote:
phelix wrote:Could you be more specific about what you are asking here? E.g. do you suggest that we dump all the NMControl code base now and create a go implementation?
I think the previous posts in this thread explain the motivations.
I take that as a "yes".

IMHO we should not discard all the work we have put into NMControl when we are just about to have a usable product. It simply does not make sense to restart now.

Why not have a competing second program? I think Go is a very interesting language but I for myself would have to dig into Go first which would take time and effort I would rather spend on other things. If you and others think they can create something better than current NMControl it's fine with me. But we should let the users decide and not force a single "official" software on them.

Whereas Go might be easier to create reproducible builds it is possible to simply run the python source directly (e.g. with Bitmessage this is pretty common).

DNSSEC is low priority from my current point of view, if not even a dead end: https://forum.namecoin.info/posting.php ... 70&p=15526
biolizard89 wrote:in Python it is difficult to know which exceptions to catch.
I don't see how you could get around this in any language. It was never a problem for though.
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

hla
Posts: 46
Joined: Mon Nov 10, 2014 12:01 am
os: linux
Contact:

Re: Preferred language for NMControl-like things

Post by hla »

phelix wrote:IMHO we should not discard all the work we have put into NMControl when we are just about to have a usable product. It simply does not make sense to restart now.
ncdns (which provides DNS resolution) works today. It is the only currently available implementation of domain-names.md, as far as I'm aware. So if we compare the completion of the two implementations, ncdns wins, unless I'm mistaken.
phelix wrote:Why not have a competing second program? I think Go is a very interesting language but I for myself would have to dig into Go first which would take time and effort I would rather spend on other things. If you and others think they can create something better than current NMControl it's fine with me. But we should let the users decide and not force a single "official" software on them.
Who's suggesting we do that? People can use what they like - but it doesn't make sense to divide the limited energies available between two middleware stacks within the context of the project.
phelix wrote:Whereas Go might be easier to create reproducible builds it is possible to simply run the python source directly (e.g. with Bitmessage this is pretty common).
I believe the issue pertains to creating reproducible builds of the Python interpreter itself.
phelix wrote:DNSSEC is low priority from my current point of view, if not even a dead end: https://forum.namecoin.info/posting.php ... 70&p=15526
DNSSEC is essential to allowing d/ names to securely delegate to nameservers, which is necessary for large zones. Moreover, the issues with getting DNSSEC support into browsers are basically the same issues as getting Namecoin TLSA verification support into browsers. They are essentially the same problem. So casting doubts on the viability of in-browser DNSSEC is basically the same as casting doubt on the viability of Namecoin-based TLS certificate verification ever working. I'm not so pessimistic. DANE has also seen adoption with for example e. mail routing, as Postfix can now validate against it in order to secure interdomain SMTP TLS sessions.
phelix wrote:
biolizard89 wrote:in Python it is difficult to know which exceptions to catch.
I don't see how you could get around this in any language. It was never a problem for though.
If the fallibility of a given function is explicitly declared, callers know they need to handle any errors which it returns. Unlike Python, Go is statically typed and uses returned error values. Therefore, it can be determined from the documentation whether the function can fail, and, when writing Go, all such failures are generally handled appropriately.

Post Reply