This is just my curiosity before getting deeper into the project:
My native approach to start a project like Syncthing would be to prototype
it in Python, and then see if something needs to be made faster in another language.
So my question is:
is there a special reason (modulo speed) that you chose the Golang in the first place?
is there something that would be near impossible with Python, like getting over the GIL problem?
or is Golang simply what is āyourā favorite language, as āPythonā feels like mine?
If the latter holds, Iād love to write a Python version (in theory, if I had timeā¦)
Thatās an interesting question! Python has been my go-to language for years as well. Nowadays I would do anything nontrivial in Go. The specific reasons in this case would be something like;
Deployment. Using Go, I get a statically linked binary and I can crosscompile it for Linux, Windows, FreeBSD etc from my Mac. There are no dependencies. None. Python would be more painful to deploy, especially on Windows, and wouldnāt really feel at home there. Well, as much āat homeā as any command line application does, but still.
Concurrency. This is the big one, language wise. In Go itās trivial and cheap to spin up āgoroutinesā (similar to green threads etc) and there are some very nice language structures to communicate data safely between routines.
Fun. I quite recently started playing with Go and itās the most fun language for me to do anything in at the moment. This project is for fun, so that matters.
Then thereās a whole bunch of smaller things and intangibles that make up the āwhyā of why I think Go is a nice and fun language to work with. A certain minimalism compared to many other languages, the cohesiveness of the standard library, and a kind of harsh pragmatism / asceticism in the thinking around what features to include and not, how to handle errors, etc that appeals to me. And yes, Itās probably faster, at least in some parts, although Python can be plenty fast as well (especially the parts of it that are actually C). (The GIL specifically would probably not have been an issue; the concurrency in syncthing is mostly the waiting-for-many-things-simultaneously kind rather than spinning all the CPU cores at the same time.)
Edit; So I donāt think thereās anything in particular that would prevent you from writing a version in Python. Iām sure it would work fine. But Iām not sure it would provide any huge advantages over the current approach. It would be much cooler if someone wrote up the core mechanics in Objective-C or C# or something that could genuinely go places Go doesnātā¦
When looking into the code, I was not aware of the key point of Golang.
The key point of Golang, besides of other important things, seems to be the idea
of CSP (Communicating Sequential Processes), which was initiated by C. A. R.
Hoareās work, but later extended, and used in languages like Alef and Limbo.
Limbo was also the language which I used as a starting
point for Stackless Python.
I feel quite ashamed of my post, since I realized too late that I was talking somehow
about this stuff - Stackless was and is my project, started 15 years ago.
So, concluding, I would like to either
retract the question as inappropriate/invalid
or
rephrase it to be like āwell, you could have it by using Stackless Pythonā
Besides reading many web pages, it was quite instructive to study Rob Pikeās talk:
Again, sorry for being numb and talking without checking the relevant history,
including mine
Iām actually intrigued by the simplicity and same time the power of Golang.
Not that Iām conv(erte|ince)d completely, it is definately the language to try.
And I want to learn it, in order to study and approve ( kidding ) your code.
Excuse the awakening of an old thread, I was browsing and saw something I already had a question about.
āIt would be much cooler if someone wrote up the core mechanics in Objective-C or C# or something that could genuinely go places Go doesnātā¦ā
Iām interested in an Objective-C, or maybe Swift, port. The GPL is not compatible with Appleās App Store EULA though, so does that mean we need to do a complete clean room implementation of the protocol? Or is there some plan to make the code available under another license for this purpose?
The protocol is creative commons, which probably means anybody can implement it.
The code is also available to āget inspired byā, and though I am not sure, inspiration does not count as violation of GPL, so I assume once you got inspired, you can license it under any license you want.
There already seems to be basic ports to Swift and Java which I think implement the protocol (but not the application part).
Thanks, I found the Swift and Java ports after posting.
Unfortunately ābeing inspiredā by some code can be enough to create a derivative work. Ideally the main project license should be updated to allow for use under e.g. MIT license for anyone porting to another language. Makes it clear to anyone contributing how their work could be used by others and gives those porting to other languages confidence that they can base their work on the Go code without someone challenging the license later.
I have a hard time seeing anyone arguing that a port of a publicly specified protocol to a different language would be a āderived workā (so covered under the license), unless the port was done by machine. But yeah, there are only minor bug fixes to the protocol stack since the MIT licensed version, so that one could be a good base to work from.