Implementation Language

[timkaechele]

It should be clear, that GDS needs an implementation, as far as I saw the specs I don't think that you would have to write a special Linux distribution to realize it. Anyway after outlining the internal API and finalizing the specs. One big question comes up: which language should the project use to implement all the functionality. Personally I would recommend one of the established languages like Python or Ruby. Especially Ruby has proven that it's possible to write complex OS CLIs like Homebrew/Puppet/Capistrano. Anyway the language would not be mandatory to use in Apps. Every third party app could interact with the Core GDS via a JSON API. The core would just handle all the nasty DB and App management and the GDS Interface and make them accessible via the API

The whole GDS could then be shipped in a Docker Container

[piranna]

I would find both Python and Node.js good candidates, and maybe better the last one since it would enable easy integration with browsers.

[timkaechele]

Actually I don't see the advantage. Personally I see node as a great network tool. That's it. If you need async I/O for whatever reason -> GDS will not be a high traffic site. You can use something like AsyncIO or Eventmachine or even Go. Most of the GDS implementation is not browser based. There's only a small percentage that is actually happening in the browser. Most of the implementation will be about databases, app installation/setup, securing data and handling the API requests that are incoming via a socket.

[lukasbestle]

Hm, being async still has advantages: Applications could easily open sockets to communicate with the core in both directions.

I'd go for either Node.js or Ruby if we decide that we don't need async code.

[timkaechele]

I am a bit tired about this whole »node is the only async programming language« perception. If we really need massive concurrency via Async IO I would prefer to take the little extra work to implement one of the many great async libraries like Eventmachine. Most applications servers written in Ruby implement a Event Pattern anyway. And one of the best parts would be silence that with Rubinius we could implement native threads and take advantage of today's multi core architecture. Looking at you little one thread node The push stream Idea is not really practical IMO cause most DBs (except redis) don't support that. Still there are ruby streaming implementations out there that are battle proven.

[lukasbestle]

I know you can write async code in Ruby, but the language isn’t made for it. The whole JS architecture is built on top of this principle.

IMHO, opening a thousand threads is not quite the best way of using memory, especially on a probably small box.

[janl]

Can we stop discussing programming languages, this won’t go anywhere.

The people who will start writing the first code will have the freedom of choice for this. Alternative implementations could arise and one will win eventually. There is no need to discuss the merits of languages here without actually doing any work as they are all equally terrible in their own ways.

[lukasbestle]

+1!

[bastianallgeier]

I completely agree! I'm all in for actually starting to work on an implementation and use that to test and work on the specs. You can only find out about the real issues when you have something to play with. I don't mind at all which language it is.

[timkaechele]

So, has someone already started an implementation, cause I wanted to start the ruby implementation.

[lukasbestle]

Go for it, Ruby sounds nice. After you started with a base structure, we will help and contribute as well, I guess.

[timkaechele]

of course it sounds nice. Ruby is awesome. 😂

[lukasbestle]

Haha. :D