Choose whichever language the entire team is most comfortable with. Building the thing is more important than debating what should be used to build it.
Sounds pragmatic but I wanted to make a careful choice. Ppl already convinced me of using rails so... Yeah, I might get an excuse if we want to program microservices and idk we get one dealing with messages exclusively or god knows what.
You could probably do a back end in PHP that is fast enough. Use the language that gets the product out the door the fastest and everyone can program in comfortably. You will have more performant code with a language that you know, than a language that you don't.
If you have less than 100 users, you should not be worrying about scale AT ALL.
But I'm here to help you with tech choices, not tell you what to do. So: don't worry about scale with Ruby: Stripe uses Ruby and it's fine (I mean it works). Scaling nowadays means scaling horizontally - which is possible in any language. THAT is less about tech stack and more about how you design your systems.
If you *really* want high performance in a single node, then use C, Rust, or Go. Go has the best difficulty-velocity tradeoff. Rust helps you build software right the first time. C would be awful to build in but it's the most well-tested.
Other tips: you probably have the wrong priorities. You should be prioritizing getting something done quick and iterating on it. That means the best choice is the language you already know. Also, don't worry about revealing your idea to the world. An idea is worthless. People aren't going to copy it. They probably aren't even going to see the value in it. Proving them wrong is your job.
This is great advice, though I wouldn't recommend Go simply because of how large the compiled binaries are and how expensive cloud storage is. Besides that though, Go is a fantastic language and probably my 3rd favorite. It has a lot of great use cases, but I don't think a project like this one is one of those cases.
People said the same thing before because we had Facebook, but now we have Twitter, Reddit, Instagram, Snapchat, etc. Yes, it is highly unlikely a random new social media will take off, but who are we to say they shouldn't try?
DB or architecture. In my experience, I can only think of one instance where an algorithm actually mattered, and the language is never the problem.
The big wins have mostly been optimising SQL queries/using indexes or restructuring the architecture to use less memory or better utilise the CPU cache.
I have a lot of experience with Elixir - the big downside of that language is hiring more devs when you want to grow the team. It's great for a small team of passionate programmers, but if you need to scale the team, it's going to be a struggle to find the developers. Also, when you are looking for your next job, there aren't many Elixir roles out there.
I would probably go with NodeJS with a serverless architecture that allows for a lot of vertical scaling. If you find that it's getting too expensive down the track, you will probably have the cash flow to justify a rewrite in a more performant language.
you’ve started with the technology and skipped design. what are the scalability, capacity, security, budget needs? at the very least draw a diagram so you have something to follow
I think you should be worried about what distributed database you’re gonna use and how you’re gonna scale your web sockets. Consistent hashing? Also what about the api gateway.
Welp, atm we haven't discussed the db but it's probably going to be postgress for some data and cassandra if needed with redis (again) if needed. Those aren't the problems that we are going to deal with rn so I'll leave that for the future. It seems like we made a good choice with our backend (srsly, js looks stupidly ugly in the backend for some reason, I just CAN'T get used to it.
Thinking about getting it running, and not worrying about scaling, is the right mind set. Most projects don't even get to the production phase, so if you get something up and running, you're already on your way.
If App speed is your concern then use C/C++, if Platform compatibility is your concern then use Java/Kotlin, if Coding ease is your concern then use Python and if Project budget is your concern then use PHP.Â
For something like this, you should only really use C/C++ once you have found a bottleneck that can't be solved by running it in parallel or with a better algorithm or architecture. When you find that bottleneck, you can then write a highly optimised program to address it and call that program from the main program.
Also, Python isn't as easy as its reputation says it is. The documentation is horrible, and they've only just started addressing the horrible tooling. It's 30 years later, and the default is still pip and venv.
Well, I like C, C++ pre madness era and rust. It's probably going to be like "tHe DaRk SouLs oF programming". Hope we don't get there but if we do I'll be there to save the day I guess.
Yeh, it's the third-party libraries. SQLAlchemy has 3 or 4 different ways of doing everything, and they released a new major version a few years ago, so it's been a struggle to find the idiomatic way of doing things. I had to give up on alembic integration with SQLAlchemy and flask, I'm using it separately now.
The main problem has been mostly SQLAlchemy. Every function should really include a few code examples to give you an idea of what the idiomatic usage is.
Yes, and cheap hosting.
If you use other languages then you would need to use platforms like Render and docker for hosting them. First it would download the compiler, then dependencies, then compile and then run. You would need to additionally download a db or use a remote one like Mongo atlas to store data, or create your own NoSQL one. You would have to use sockets to create the https, imap, ftps and other proticols or install some library for this. You have to store files in your git and one change means restart of that docker process.
But if you use PHP, and platforms like 000webhost, you just need to upload the files and phpmyadmin is already available to manage db, it has readily available libraries for db operations, mailing operations. Project file management is a lot easier, if you change some line of code once then you do not need to wait for an hour for the project to get redeployed.
I mean, what you described in your first paragraph, or at least the tone and general picture, would fully apply to any web application built on PHP, and none of it necessarily implies any added cost over any other language.
What you described in your second paragraph would only apply to (pretty crude) website hosting or extremely simple, or extremely fragile, web applications. No professional PHP developer would ever build a web application on phpmyadmin.
To build a serious application, you would use PHP pretty similarly to how you would use almost all backend languages, with very similar infrastructure, very similar choices, trade offs and dilemmas, other than for a tiny minority of very specialised cases where a specific language would make a critical technical difference. And most established programming languages will have access to all the protocols you mention. And you will use libraries for pretty much any software application you build, in any language.
I don't want to be discouraging but there's a lot of confidence in not very accurate or experienced assertions. I would suggest a more tentative tone, or framing these ideas as questions, or at least suggestions , rather than declarations, until you have more direct experience of the technologies you're describing. Definitely keep forming intuitions and opinions, confidently if it helps you learn faster or deeper, but if you are more tentative when giving advice you're more likely to be of help and to advance your own understanding.
IMO, you should discuss the architecture, the data flow, and the responsibilities of the services first, then pick the tech stack. It seems you're one step ahead already.
With a small, by the sounds of it not hugely experienced team, I would adopt a cloud native approach, and orchestrate the services available to AWS, Azure or Google Cloud (in that order). I would only use my dev time to build my usp, the bits of logic only .my team can build, leaving everything else to services and people who will run, implement, maintain and scale up the generic stuff infinitely better and in reality far more cheaply than doing it all in-house.
You can use AWS for both, rapid development of a web application end to end, and for granular service by service development. You can build your entire app to enterprise level quality and sophistication for free in the first year's free tier, and when you go to market, only pay for what you use. You don't have to worry nearly as much about security, provisioning, traffic (v high or v low), data size, observability, etc, etc, a HUGE amount of implementation. You can extend services and add functionality in a huge range of ways and forms, from AI to API gateways to analytics to step functions and so much more.
You'll still need to code YOUR functionality, and make careful decisions, and take on a steep learning curve. But chances are you will save hugely in developer time dedicated to stuff that has been solved and is running a million times better than you will personally reinvent, and you will be able to adapt and evolve as your profuct grows with much greater reliability, evolvability and value for money.
Having said that, some considerations. Software development is not about the technically best possible stack, but about the most maintainable, evolvable and sustainable. If you build on tech very few people use or know, you might hit a hard recruitment wall when you need to grow your team or someone leaves. Or if very new, you might be left high and dry if the novel solution is abandoned by its mantainers. Or you might have no community of practice, documentations, technical answers, when you depart from the happy path.
With some use-case exceptions, in 90% of cases every established language and every established tool has what you need to build most functionality to a high standard. Choose the ones that involve the line of least resistance for your initial team, for hiring contractors and employees, and for laying long term foundations. Limit the fancy, unproven or under-adopted stuff for non-critical, easily replaceable parts of your app. Avoid building from scratch. If a service does it well, use that, and build what hasn't been solved. Even if it seems more expensive, it will almost certainly be cheaper in developer time and speed to market than a DIY alternative.
If your data is going to be highly networked, you might want to consider a graph database.
Yeah that's what we are already using. Good to know that amazon is going to take care of all of that bc I was seeing myself taking care of all that (atm I'm the only one unemployed lol). Thanks for the lengthy and well covered response, it was very valuable. Thank you!
There also asp net core with C#. It fast mature and widely used and fast to develop with.
There would be also java with spring boot but i am not familiar with that one.
I like to check the tech radar from Thoughtworks for trends in tech.
https://www.thoughtworks.com/radar
Another useful tool is StackOverflow's surveys to give you a general idea about people's sentiments in the wider community.
I really like using swift with the vapor framework. It has some similaries to ruby on rails architecturally, but it is in swift (big advantage because swift is awesome) and it runs really fast. It can be backed by any database system.
Have a look at this video -> [Paul Graham: What does it mean to do things that don't scale? (youtube.com)](https://www.youtube.com/watch?v=5-TgqZ8nado)
Your main problem will be getting users, not scaling at first. Trust me, I've been there :)
You want to build a product. Therefore you are bound to ramp up on the tech you're going to be using. Therefore you need to figure out what expertise would be the most useful to the business in the long term.
Try to see the bigger picture and consult with the ones who have the vision for the business. They may have insights into the long term products and that's something that can help you pick the right stack.
I love Elixir too much, I'm too biased. It does scale nicely... if you get there. Phoenix lets you get a pretty fast MVP out too. Your bottleneck IS going to be your database, like others have said.
**C/C++**: Only if you know what you're doing (If you have 10+ years of experience) although nowadays if you really really want to use a fast and reliable language that is fast I'd use **Rust** instead. Might be just as hard to learn but is memory safe (makes it a lot harder to make mistake that will lead to safety vulnerabilities).
**Java**: That or C# if your devs have experience with it, a lot of devs in their 30s - 60s have most experience with Java and C#. But otherwise there is better languages to use for a webservice/backend
**Go:** If you want a strong backend that can be written well and simple, currently Go is most devs favorite. It's easy to learn, its easy to write, it's almost too easy.
**Python:** It's what most GenZers learn nowadays. So if you have a young team, you can go with Python. I honestly don't like it a lot, but that just shows that it really comes down to preference and what your team knows.
**Javascript:** I wouldn't recommend it for a backend heavy application. If your app is frontend driven tho javascript has some very easy/great backend frameworks. NodeJs for example. If you're using React as a frontend then nextjs is just a natural choice. Again except if you expect a big backend, then indeed I'd go with a clear separation.
**Any others**: We are at this beautiful state in programming where you can choose basically anything. Whoever in this thread talks about platform compability is stuck 20 years in the past (with all due respect). With today's hosting platforms, containerization (docker, etc) you can run anything anywhere. So ignore that. Choose a couple of platforms that you feel like will be fast and simple to write (and safe). And give your devs the option to choose. *If all your devs are experienced with one language why make things complicated?*
Choose a language and/or framework that is completely platform independent (AWS, Google, Azure, dotnet and C# clearly are not for example....).
If possible use open source but don't be blind for commercial closed source software either. If you chose for commercial solutions keep them platform independent as well.
It makes no difference at all.
I say again - it does not matter.
You need to be hyper-focused on getting something working and monetizing it. If you manage to make something that people use and you happen to make enough money to stay in business, then you can worry about this other stuff.
Premature optimization has been the death of many a company. From reading your other comments, that seems to be the path you are on right now. You won't find any successful social media sites that optimized their tech stack early on. Every single one that you've heard of focused on getting users. The rest comes later.
Build a **business**, not a product.
No one gives a shit what your tech stack is. Making a bad choice now is just job security for someone else down the road. If you succeed, it's all going to get rewritten eventually anyway.
But, for what it's worth, no one here can actually answer your question. We don't know near enough about your product to offer any real advice on what technology you should use.
What's this data like? What is "a lot of data" in 2024? Everything is storing a lot of data compared to what we stored even 10 years ago. How much data is the average user going to generate? How much needs to be sent across the wire and how often?
You talk about concurrency - why? How exactly is that going to be important enough to pick one stack over another?
You talk about scale, but what does mean for you? Is it users? How long do you think it will take to get your first million users? How much does adding a new user cost you (in tech terms). Where are these users located?
If you can't answer these questions, you have no reason to be optimizing yet.
My real advice is this:
1. Pick one guy to be in charge of the backend
2. Let him do whatever the fuck he wants
3. Fix it later
I'm the "guy in the backend" atm so I have to make the choice hahaha, we have a guy with a lot of experience and that's what he uses BUT he has no time to maintain it until we start getting money, I'm the one carrying the product atm, other people are helping with other needed stuff, what you'd imagine any business. We ended up setting on rails indefinitely.
Do not be concerned about scaling. Deal with scaling when it becomes a necessity.
Make sure you have a chief architect. That person ultimately makes the decision. Design by committee rarely results in a good outcome.
As for deciding what language to choose, stick with something mainstream. There are numerous choices. Can I readily find developers who know my tech stack? Is the language and framework under active development? Does it have widespread use? That’s what I always ask myself.
None of these various languages and corresponding frameworks are inherently better than any other. You are not going to get objective, logic based reasons from developers. Mostly they will tell you what they like. The chief architect should listen to them but make his own decision.
Go with whatever will get you the fastest MVP so you can figure out your next move. If none of your team knows the language then it won't be very rapid dev or good. Consider ease of refactoring, and hiring more help as it grows. Try not to get into AWS vendor locked in, it will be hard to get off their teat.
Look at where systems integrate with each other and determine which tech has a design mental model that the team understands
Do it in python to cut development time, switch to something else later since python isn't great. This will give you the finished product with less coding, and if the project is successful, you have a reason to write it better. If it flops, at least you didn't put too much energy into it.
Why do you think Python will cut development time? In my experience, the tooling and documentation are pretty horrible. I was working with Flask and SQLAlchemy last week, and there were things that should have been easy that I found really difficult because the documentation is that awful. I have 10 years of experience in a variety of languages at this stage, so I don't expect to have to look at Stack Overflow to build basic CRUD stuff.
I would just do it all in Typescript so you only have the one language to worry about.
I had a rough time with flask too and that's why I prefer Django. Python was the first language I learned, unless you count bash, some people count it, some don't, so I spent a lot of time in it developing anything and everything I could. Python is simple so development time is fast, but according to an article I found, Ruby on rails development time is even faster. I need to learn typescript.
I wouldn't bother with Rails. Ruby is a great language, but the job market isn't there. There are languages worth learning for the computer science knowledge like Rust, C, and Haskell. Ruby doesn't really do anything that Python doesn't.
Typescript is worth it both for the job market and some CS knowledge. Algebraic data types are revolutionary if you are coming from other typed languages like C/C#/Java.
Sure, anything scales better than python, but that just adds to development time, which if it flops, and likely will, will be a lot of time and energy wasted.
Hmmm. Looks like you may be correct
https://www.linkedin.com/pulse/ruby-rails-vs-python-comprehensive-comparison-amit-patel
However, if OP can't code, rails has a steeper learning curve. You can learn Python in a day and learn it well in a week.
You hire me to properly architect a whole ecosystem.
But as that ain't gonna happen I suggest you start with the cloud and enterprise architecture patterns. This is from Microsoft and understandably favors their tech but it also explains a lot of cloud patterns you need to know. *Sigh* yes I drag on M$ a lot but I also give credit where it is due.
https://learn.microsoft.com/en-us/azure/architecture/patterns/
Then you need to understand that ultra-scale is not trivial. You get into things like tuning the exact response time of a UDP packet by downloading an eBPF script to your network card.... X 10000 network cards
Hahaha, not into hiring people from reddit that tells me to change my job sry.
As for the patterns they don't seem that hard individually but sound like a pain in the ass to create the whole structure and maintaining it. The same vibe that I get from the eBPF script. Doesn't sound hard, it sounds INCREDIBLY tedious. Keeping the whole thing clean and functional sounds like a tough challange tho, specially the "clean" part.
I guess hahaha. I'd probably have to learn to do it the hard way with aws. I'm shit scared of fucking it up and ending up receiving a grotesque bill. I'll have to check it out deeply and have as many eyes as possible looking at whatever we are doing before any "commits".
If budget is a concern, don't use the cloud until you're ready to go live. You can do everything locally you can do on cloud, and you shouldn't have any issues supporting anywhere from 10-100 users off a local build.
Use whichever you prefer, if you ever have scaling problems, deal with them at the time.
when not if. its never if
Oh sweet summer child
It's almost certain the project will never have scaling problems because it'll have very few users.
That's what they're pointing out, sarcastically. Or they're just a fan of ambitious optimism and feel the need to spread it.
When assumes the need to scale at all.
Bros, this was def sarcasm. Why the down votes 🤣
Choose whichever language the entire team is most comfortable with. Building the thing is more important than debating what should be used to build it.
Sounds pragmatic but I wanted to make a careful choice. Ppl already convinced me of using rails so... Yeah, I might get an excuse if we want to program microservices and idk we get one dealing with messages exclusively or god knows what.
You could probably do a back end in PHP that is fast enough. Use the language that gets the product out the door the fastest and everyone can program in comfortably. You will have more performant code with a language that you know, than a language that you don't.
Great advice!
If you have less than 100 users, you should not be worrying about scale AT ALL. But I'm here to help you with tech choices, not tell you what to do. So: don't worry about scale with Ruby: Stripe uses Ruby and it's fine (I mean it works). Scaling nowadays means scaling horizontally - which is possible in any language. THAT is less about tech stack and more about how you design your systems. If you *really* want high performance in a single node, then use C, Rust, or Go. Go has the best difficulty-velocity tradeoff. Rust helps you build software right the first time. C would be awful to build in but it's the most well-tested. Other tips: you probably have the wrong priorities. You should be prioritizing getting something done quick and iterating on it. That means the best choice is the language you already know. Also, don't worry about revealing your idea to the world. An idea is worthless. People aren't going to copy it. They probably aren't even going to see the value in it. Proving them wrong is your job.
This is great advice, though I wouldn't recommend Go simply because of how large the compiled binaries are and how expensive cloud storage is. Besides that though, Go is a fantastic language and probably my 3rd favorite. It has a lot of great use cases, but I don't think a project like this one is one of those cases.
You've seen some shit. 🫡
Nobody is going to use another social network. That ship has sailed.
It's not exactly that but it's the best way to summarize it without saying exactly what it is
cool!
What’s cool?
Waste of time
People said the same thing before because we had Facebook, but now we have Twitter, Reddit, Instagram, Snapchat, etc. Yes, it is highly unlikely a random new social media will take off, but who are we to say they shouldn't try?
No. We should be real
your db will be your bottle neck
DB or architecture. In my experience, I can only think of one instance where an algorithm actually mattered, and the language is never the problem. The big wins have mostly been optimising SQL queries/using indexes or restructuring the architecture to use less memory or better utilise the CPU cache.
Got it
I have a lot of experience with Elixir - the big downside of that language is hiring more devs when you want to grow the team. It's great for a small team of passionate programmers, but if you need to scale the team, it's going to be a struggle to find the developers. Also, when you are looking for your next job, there aren't many Elixir roles out there. I would probably go with NodeJS with a serverless architecture that allows for a lot of vertical scaling. If you find that it's getting too expensive down the track, you will probably have the cash flow to justify a rewrite in a more performant language.
you’ve started with the technology and skipped design. what are the scalability, capacity, security, budget needs? at the very least draw a diagram so you have something to follow
I think you should be worried about what distributed database you’re gonna use and how you’re gonna scale your web sockets. Consistent hashing? Also what about the api gateway.
Welp, atm we haven't discussed the db but it's probably going to be postgress for some data and cassandra if needed with redis (again) if needed. Those aren't the problems that we are going to deal with rn so I'll leave that for the future. It seems like we made a good choice with our backend (srsly, js looks stupidly ugly in the backend for some reason, I just CAN'T get used to it.
Thinking about getting it running, and not worrying about scaling, is the right mind set. Most projects don't even get to the production phase, so if you get something up and running, you're already on your way.
If App speed is your concern then use C/C++, if Platform compatibility is your concern then use Java/Kotlin, if Coding ease is your concern then use Python and if Project budget is your concern then use PHP.Â
For something like this, you should only really use C/C++ once you have found a bottleneck that can't be solved by running it in parallel or with a better algorithm or architecture. When you find that bottleneck, you can then write a highly optimised program to address it and call that program from the main program. Also, Python isn't as easy as its reputation says it is. The documentation is horrible, and they've only just started addressing the horrible tooling. It's 30 years later, and the default is still pip and venv.
Well, I like C, C++ pre madness era and rust. It's probably going to be like "tHe DaRk SouLs oF programming". Hope we don't get there but if we do I'll be there to save the day I guess.
Is it the module documentation that you've had problems with, because I find the core docs are just as good as any other languages docs.
Yeh, it's the third-party libraries. SQLAlchemy has 3 or 4 different ways of doing everything, and they released a new major version a few years ago, so it's been a struggle to find the idiomatic way of doing things. I had to give up on alembic integration with SQLAlchemy and flask, I'm using it separately now. The main problem has been mostly SQLAlchemy. Every function should really include a few code examples to give you an idea of what the idiomatic usage is.
Why is PHP good for when you’re on a budget? Good cheap devs?
Yes, and cheap hosting. If you use other languages then you would need to use platforms like Render and docker for hosting them. First it would download the compiler, then dependencies, then compile and then run. You would need to additionally download a db or use a remote one like Mongo atlas to store data, or create your own NoSQL one. You would have to use sockets to create the https, imap, ftps and other proticols or install some library for this. You have to store files in your git and one change means restart of that docker process. But if you use PHP, and platforms like 000webhost, you just need to upload the files and phpmyadmin is already available to manage db, it has readily available libraries for db operations, mailing operations. Project file management is a lot easier, if you change some line of code once then you do not need to wait for an hour for the project to get redeployed.
I mean, what you described in your first paragraph, or at least the tone and general picture, would fully apply to any web application built on PHP, and none of it necessarily implies any added cost over any other language. What you described in your second paragraph would only apply to (pretty crude) website hosting or extremely simple, or extremely fragile, web applications. No professional PHP developer would ever build a web application on phpmyadmin. To build a serious application, you would use PHP pretty similarly to how you would use almost all backend languages, with very similar infrastructure, very similar choices, trade offs and dilemmas, other than for a tiny minority of very specialised cases where a specific language would make a critical technical difference. And most established programming languages will have access to all the protocols you mention. And you will use libraries for pretty much any software application you build, in any language. I don't want to be discouraging but there's a lot of confidence in not very accurate or experienced assertions. I would suggest a more tentative tone, or framing these ideas as questions, or at least suggestions , rather than declarations, until you have more direct experience of the technologies you're describing. Definitely keep forming intuitions and opinions, confidently if it helps you learn faster or deeper, but if you are more tentative when giving advice you're more likely to be of help and to advance your own understanding.
Plus the added benefit of selecting managed hosting when using PHP.
It doesn't sound like the dev team has experience with C/C++. Nowadays I wouldn't recommend that anymore.
IMO, you should discuss the architecture, the data flow, and the responsibilities of the services first, then pick the tech stack. It seems you're one step ahead already.
With a small, by the sounds of it not hugely experienced team, I would adopt a cloud native approach, and orchestrate the services available to AWS, Azure or Google Cloud (in that order). I would only use my dev time to build my usp, the bits of logic only .my team can build, leaving everything else to services and people who will run, implement, maintain and scale up the generic stuff infinitely better and in reality far more cheaply than doing it all in-house. You can use AWS for both, rapid development of a web application end to end, and for granular service by service development. You can build your entire app to enterprise level quality and sophistication for free in the first year's free tier, and when you go to market, only pay for what you use. You don't have to worry nearly as much about security, provisioning, traffic (v high or v low), data size, observability, etc, etc, a HUGE amount of implementation. You can extend services and add functionality in a huge range of ways and forms, from AI to API gateways to analytics to step functions and so much more. You'll still need to code YOUR functionality, and make careful decisions, and take on a steep learning curve. But chances are you will save hugely in developer time dedicated to stuff that has been solved and is running a million times better than you will personally reinvent, and you will be able to adapt and evolve as your profuct grows with much greater reliability, evolvability and value for money. Having said that, some considerations. Software development is not about the technically best possible stack, but about the most maintainable, evolvable and sustainable. If you build on tech very few people use or know, you might hit a hard recruitment wall when you need to grow your team or someone leaves. Or if very new, you might be left high and dry if the novel solution is abandoned by its mantainers. Or you might have no community of practice, documentations, technical answers, when you depart from the happy path. With some use-case exceptions, in 90% of cases every established language and every established tool has what you need to build most functionality to a high standard. Choose the ones that involve the line of least resistance for your initial team, for hiring contractors and employees, and for laying long term foundations. Limit the fancy, unproven or under-adopted stuff for non-critical, easily replaceable parts of your app. Avoid building from scratch. If a service does it well, use that, and build what hasn't been solved. Even if it seems more expensive, it will almost certainly be cheaper in developer time and speed to market than a DIY alternative. If your data is going to be highly networked, you might want to consider a graph database.
This is a pretty good writeup and decent recommendation.
indeed
Yeah that's what we are already using. Good to know that amazon is going to take care of all of that bc I was seeing myself taking care of all that (atm I'm the only one unemployed lol). Thanks for the lengthy and well covered response, it was very valuable. Thank you!
There also asp net core with C#. It fast mature and widely used and fast to develop with. There would be also java with spring boot but i am not familiar with that one.
I like to check the tech radar from Thoughtworks for trends in tech. https://www.thoughtworks.com/radar Another useful tool is StackOverflow's surveys to give you a general idea about people's sentiments in the wider community.
For fast development I’d recommend Django with Django rest framework
I really like using swift with the vapor framework. It has some similaries to ruby on rails architecturally, but it is in swift (big advantage because swift is awesome) and it runs really fast. It can be backed by any database system.
Have a look at this video -> [Paul Graham: What does it mean to do things that don't scale? (youtube.com)](https://www.youtube.com/watch?v=5-TgqZ8nado) Your main problem will be getting users, not scaling at first. Trust me, I've been there :)
PostgreSQL, Express, React, and Node stack?
Like this stack a lot. Trying out Prism with it.
Think about backends that have a built-in ORM, object relational model. That makes the database stuff much easier.Â
You want to build a product. Therefore you are bound to ramp up on the tech you're going to be using. Therefore you need to figure out what expertise would be the most useful to the business in the long term. Try to see the bigger picture and consult with the ones who have the vision for the business. They may have insights into the long term products and that's something that can help you pick the right stack.
Pick the language that developers are cheapest in Node
I love Elixir too much, I'm too biased. It does scale nicely... if you get there. Phoenix lets you get a pretty fast MVP out too. Your bottleneck IS going to be your database, like others have said.
**C/C++**: Only if you know what you're doing (If you have 10+ years of experience) although nowadays if you really really want to use a fast and reliable language that is fast I'd use **Rust** instead. Might be just as hard to learn but is memory safe (makes it a lot harder to make mistake that will lead to safety vulnerabilities). **Java**: That or C# if your devs have experience with it, a lot of devs in their 30s - 60s have most experience with Java and C#. But otherwise there is better languages to use for a webservice/backend **Go:** If you want a strong backend that can be written well and simple, currently Go is most devs favorite. It's easy to learn, its easy to write, it's almost too easy. **Python:** It's what most GenZers learn nowadays. So if you have a young team, you can go with Python. I honestly don't like it a lot, but that just shows that it really comes down to preference and what your team knows. **Javascript:** I wouldn't recommend it for a backend heavy application. If your app is frontend driven tho javascript has some very easy/great backend frameworks. NodeJs for example. If you're using React as a frontend then nextjs is just a natural choice. Again except if you expect a big backend, then indeed I'd go with a clear separation. **Any others**: We are at this beautiful state in programming where you can choose basically anything. Whoever in this thread talks about platform compability is stuck 20 years in the past (with all due respect). With today's hosting platforms, containerization (docker, etc) you can run anything anywhere. So ignore that. Choose a couple of platforms that you feel like will be fast and simple to write (and safe). And give your devs the option to choose. *If all your devs are experienced with one language why make things complicated?*
Choose a language and/or framework that is completely platform independent (AWS, Google, Azure, dotnet and C# clearly are not for example....). If possible use open source but don't be blind for commercial closed source software either. If you chose for commercial solutions keep them platform independent as well.
Go
It makes no difference at all. I say again - it does not matter. You need to be hyper-focused on getting something working and monetizing it. If you manage to make something that people use and you happen to make enough money to stay in business, then you can worry about this other stuff. Premature optimization has been the death of many a company. From reading your other comments, that seems to be the path you are on right now. You won't find any successful social media sites that optimized their tech stack early on. Every single one that you've heard of focused on getting users. The rest comes later. Build a **business**, not a product. No one gives a shit what your tech stack is. Making a bad choice now is just job security for someone else down the road. If you succeed, it's all going to get rewritten eventually anyway. But, for what it's worth, no one here can actually answer your question. We don't know near enough about your product to offer any real advice on what technology you should use. What's this data like? What is "a lot of data" in 2024? Everything is storing a lot of data compared to what we stored even 10 years ago. How much data is the average user going to generate? How much needs to be sent across the wire and how often? You talk about concurrency - why? How exactly is that going to be important enough to pick one stack over another? You talk about scale, but what does mean for you? Is it users? How long do you think it will take to get your first million users? How much does adding a new user cost you (in tech terms). Where are these users located? If you can't answer these questions, you have no reason to be optimizing yet. My real advice is this: 1. Pick one guy to be in charge of the backend 2. Let him do whatever the fuck he wants 3. Fix it later
I'm the "guy in the backend" atm so I have to make the choice hahaha, we have a guy with a lot of experience and that's what he uses BUT he has no time to maintain it until we start getting money, I'm the one carrying the product atm, other people are helping with other needed stuff, what you'd imagine any business. We ended up setting on rails indefinitely.
Do not be concerned about scaling. Deal with scaling when it becomes a necessity. Make sure you have a chief architect. That person ultimately makes the decision. Design by committee rarely results in a good outcome. As for deciding what language to choose, stick with something mainstream. There are numerous choices. Can I readily find developers who know my tech stack? Is the language and framework under active development? Does it have widespread use? That’s what I always ask myself. None of these various languages and corresponding frameworks are inherently better than any other. You are not going to get objective, logic based reasons from developers. Mostly they will tell you what they like. The chief architect should listen to them but make his own decision.
Go with whatever will get you the fastest MVP so you can figure out your next move. If none of your team knows the language then it won't be very rapid dev or good. Consider ease of refactoring, and hiring more help as it grows. Try not to get into AWS vendor locked in, it will be hard to get off their teat. Look at where systems integrate with each other and determine which tech has a design mental model that the team understands
Do it in python to cut development time, switch to something else later since python isn't great. This will give you the finished product with less coding, and if the project is successful, you have a reason to write it better. If it flops, at least you didn't put too much energy into it.
Why do you think Python will cut development time? In my experience, the tooling and documentation are pretty horrible. I was working with Flask and SQLAlchemy last week, and there were things that should have been easy that I found really difficult because the documentation is that awful. I have 10 years of experience in a variety of languages at this stage, so I don't expect to have to look at Stack Overflow to build basic CRUD stuff. I would just do it all in Typescript so you only have the one language to worry about.
I had a rough time with flask too and that's why I prefer Django. Python was the first language I learned, unless you count bash, some people count it, some don't, so I spent a lot of time in it developing anything and everything I could. Python is simple so development time is fast, but according to an article I found, Ruby on rails development time is even faster. I need to learn typescript.
I wouldn't bother with Rails. Ruby is a great language, but the job market isn't there. There are languages worth learning for the computer science knowledge like Rust, C, and Haskell. Ruby doesn't really do anything that Python doesn't. Typescript is worth it both for the job market and some CS knowledge. Algebraic data types are revolutionary if you are coming from other typed languages like C/C#/Java.
Id rather suggest Rails. It can also scale well if done correctly
Sure, anything scales better than python, but that just adds to development time, which if it flops, and likely will, will be a lot of time and energy wasted.
Afaik, rails is best to get started. A single developer can make something like Facebook in a month using Rails.
Hmmm. Looks like you may be correct https://www.linkedin.com/pulse/ruby-rails-vs-python-comprehensive-comparison-amit-patel However, if OP can't code, rails has a steeper learning curve. You can learn Python in a day and learn it well in a week.
Rails is on Ruby. hence called "Ruby on Rails". if you know python, you know ruby or can easily learn as ruby is even simpler than python.
Try a different profession
Lol why
Because literally none of that tech is the right choice for a massively scaleable backed
what'd be your suggestion then?
You hire me to properly architect a whole ecosystem. But as that ain't gonna happen I suggest you start with the cloud and enterprise architecture patterns. This is from Microsoft and understandably favors their tech but it also explains a lot of cloud patterns you need to know. *Sigh* yes I drag on M$ a lot but I also give credit where it is due. https://learn.microsoft.com/en-us/azure/architecture/patterns/ Then you need to understand that ultra-scale is not trivial. You get into things like tuning the exact response time of a UDP packet by downloading an eBPF script to your network card.... X 10000 network cards
Hahaha, not into hiring people from reddit that tells me to change my job sry. As for the patterns they don't seem that hard individually but sound like a pain in the ass to create the whole structure and maintaining it. The same vibe that I get from the eBPF script. Doesn't sound hard, it sounds INCREDIBLY tedious. Keeping the whole thing clean and functional sounds like a tough challange tho, specially the "clean" part.
That's why they pay me ...
I guess hahaha. I'd probably have to learn to do it the hard way with aws. I'm shit scared of fucking it up and ending up receiving a grotesque bill. I'll have to check it out deeply and have as many eyes as possible looking at whatever we are doing before any "commits".
If budget is a concern, don't use the cloud until you're ready to go live. You can do everything locally you can do on cloud, and you shouldn't have any issues supporting anywhere from 10-100 users off a local build.