Syncthing in Python?

Hey calmh,

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? :wink:

If the latter holds, I’d love to write a Python version (in theory, if I had time…)

cheers - Chris

1 Like

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. :smiley:

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… :smiley:


Me, too. :wink:

If syncthing is python, then i can contribute more. (in theory, if I had time…)

Actually, I have to apologize after all.

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


  • 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 :wink:

1 Like

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 ( :smiley: kidding ) your code.

cheers & thanks – Chris

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?

These are my assumptions:

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.

Most of the protocol code hasn’t changed since the move from MIT to GPL, so you can get inspired as much you like there. (Hence the ports probably)

But I guess your comment for porting does make sense and I wonder what @calmh thinks about this.

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.