What programming language to use?

[oscarwumit]

No description provided.

[vito-c]

Let the emoji war begin quick vote for your favorite language!

[vito-c]

golang!

[sunnyguan]

COBOL!

[breakthatbass]

Assembly!

[BryantH24]

HTML!

[JayWeeeve]

python using https://www.nltk.org/

[pfcodes]

TypeScript (front-end), Python (back-end)

[honggyu420]

Python!

[GuruOz]

I assume this will be a client-server architecture? webapp of some sort?

[itsCodyBo]

python is the most universally accepted language for the average user I would image, as well as the easiest for anyone not familiar with it to pick up. Just my two cents!

[Carson-Fricke]

C++ for its superior interpretability and ease of writing.

[zachlavere]

Wouldn't be surprised if Python wins out, and if we go that route I like Django + Vue.js

[syphilitik]

🚀

[dannyseymour2]

Seconding @pfcodes and @zachlavere for python backend (Django?) + js frontend (Vue). Might also be wise to separate webapp/site for users that then makes API calls to a standalone backend API to fetch/process data (this is where the data science stuff could happen). Keep user website lightweight and makes API standalone.

[Collert]

Holy C

[comann]

golang for restful back end, react for any front end, and python for data science.

[dannyseymour2]

it does not need to be in one language, because this project will need to address multiple issues, so multiple languages will be required anyway.

Agreed, probably best to divide up into several small, well-defined backend services based on desired functionality, accessible via rest or graphql, with one webapp frontend. With a large team with a lot of different competencies that'll make it easier to divide up work.

[Bradfordly]

No Rustaceans out there? 😉
Apologies for echo-chamber-ing, but I too agree about the sentiment about this not being a single language project. dannyseymour2 has the right idea as mentioned above me; this needs to be a distributed services that can leverage cloud native services for cost-control and containerization to keep the app portable.

[anthony-langford]

Seconding the multi-language microservices architecture proposals

[devopsjourney1]

Vote for a multi-lang microservices architecture, with a preference towards Python

[notjoshjames]

Concur that multi-lang microservices should allow the most contribution and flexibility for different datasets

[Nllii]

A Docker container, for everything. Since we all have different language background.

1. Assembly
2. C
3. Python
4. Graphql server for api for each tools created.

Time to play a devils advocate for the second time. Since Reddit has ban me for saying anything that’s not following the narrative.

What if. A huge what if, we don't do this.

1. Why create these tools that majority of the general public isn't going to use?

2. We are helping the big guys by coming together and creating tools for them to take and exploit us.

3. Why waste our time doing this when sites like this exist.

https://swaggystocks.com/dashboard/home

And also, https://pushshift.io

4. I'm all for us doing this, just don't think it's worth doing in the long run. 

Hopefully these tools are not CURD APP

[neomat00]

Connecting it all in the end with different languages and so many changes is going to be one hell of a job. But I think we should be able to accomplish it as long as we don't lose traction on this project.

Can someone please add me to the discord? ID - anon65

[iduncant]

Just throwing in my support for python, Django, flask. I do think the person below has a point. Maybe we need to define what the main point of difference is?

A Docker container, for everything. Since we all have different language background.

1. Assembly
2. C
3. Python
4. Graphql server for api for each tools created.

Time to play a devils advocate for the second time. Since Reddit has ban me for saying anything that’s not following the narrative.

What if. A huge what if, we don't do this.

1. Why create these tools that majority of the general public isn't going to use?
2. We are helping the big guys by coming together and creating tools for them to take and exploit us.
3. Why waste our time doing this when sites like this exist.

https://swaggystocks.com/dashboard/home

And also, https://pushshift.io

1. I'm all for us doing this, just don't think it's worth doing in the long run. 

Hopefully these tools are not CURD APP

[DrewMcArthur]

@Nllii i'm not really sure what "this" is that you're proposing not doing. so far, this repo is just a shitton of people coming together saying "i wanna help", so my take is yes we absolutely should do that.

are there existing projects that have some useful functionality? absolutely!
should we reinvent the wheel? no!

i think this repo (and hopefully the organization once that's implemented) will serve as a launchboard towards those smaller, more specific projects you mentioned.

[MattSmilin]

@Nllii i'm not really sure what "this" is that you're proposing not doing. so far, this repo is just a shitton of people coming together saying "i wanna help", so my take is yes we absolutely should do that.

are there existing projects that have some useful functionality? absolutely!
should we reinvent the wheel? no!

i think this repo (and hopefully the organization once that's implemented) will serve as a launchboard towards those smaller, more specific projects you mentioned.

Yes. Also, the separate tools can be written in different languages.

Good to see people voting for their favorites nonetheless.

[ghost]

A Docker container, for everything.

Gets my vote.

The microservice route seems like the optimal way to leverage both everyone's experience, and the best features of each language or framework. Can potentially see us having differents types of services:

• feed aggregators
• feed processors
• Analysis tools
• Frontend apps
• Dashboard to accumulate apps

Just need to be careful we don't get stuck in micro service hell.... each service should do some non-trivial work, and have a clearly defined role with expected inputs / outputs.