[mritchie712]

Two things I consider:

1. what languages does the team already know best?

2. are any languages dominant in the problem space?

for us, I've used Python over 10 years and Python is the leader in data science / analytics. Some things might be a little faster if we used Rust, but compute is cheap. Go with what you know.

[retcon]

>compute is cheap. Go with what you know.

sorry for picking on your comment in this generic fashion but I am critical of these memes not your observations:

Compute Is Cheap(where Gustafson Bariss is true)

https://en.m.wikipedia.org/wiki/Gustafson%27s_law

Going with what you already know is fine for knocking out the cobwebs and getting into a space. But most generally certainly in my experience I've never done anything to completion I knew at the beginning.

[015a]

My response to the "compute is cheap" argument is always: Discord powers millions of concurrent live-chat and real-time-voice users from literally single (huge) VMs, using Elixir and Rust. Their revenue (relatively) sucks; its a powerhouse in communication because their revenue sucks (zero barrier to entry); and because their revenue sucks, they were forced to actually think critically about the technologies they use. They can't just throw more computers at the problem; and that limitation produced a far better product than, say, Slack.

Ok, smaller scale. You look at the latest Show HN SaaS product and wonder: "Why is there no free tier?" Free tiers are a classic in SaaS; it gets customers in the door, using your product, and you can upsell to higher tiers. Its all the same backend no matter the cost; but if your infrastructure & engineering costs are high, you may not be able to afford a generous free tier.

The days of the SaaS unicorn are behind us. Also; the days of Moore's Law (server-side at least) are quickly dwindling. This idea of "just throw more compute at the problem" needs to die a painful death. This week I consulted with a startup with something like $500k in ARR, spending $80k/year in cloud infrastructure. No free tier, all enterprise contracts, the most basic CRUD app you can imagine. A hundred NodeJS containers, every security service AWS offers enabled and logging terabytes of useless shit to an S3 bucket, autoscaling their database up to 100s of gigabytes in memory because "we don't have time to optimize". Sure; you also don't have time to not to. You're banking on some large enterprise contract to come through and buy another year; which will also add a few tens of thousands of more users to the platform, so you'll tweak the scale numbers up again, and again, and just keep praying one day you can cost optimize. Every day that goes by makes that harder, so you're also praying that maybe you can find more talent to do it, maybe we can grab some people from these layoffs, except what if we don't have the money to pay for talent just like the company that laid them off?

Python, JS, Big Cloud, had their time and were valuable during it; but today, startups need to think about cost optimization from day 1, and every cycle a CPU spends doing something is a cost. I'm not prescribing technologies; I'm just asking for more critical thinking, and not always operating with the "throw money at it" mindset. Maybe python makes sense; how can we deliver it with extremely low costs? Lambda? DigitalOcean? Can we integrate a more performance-oriented view into reviews? This part of the app experiences 10x the traffic the rest does; can we break that out into something far more efficient?

[1] https://discord.com/category/engineering

[pizza234]

I agree that one doesn't necessarily need a fast language, but I think that the "hardware is cheap" idea is very misleading. Renting/owning 5x as much servers may be cheap, but maintaining them isn't.

[mritchie712]

check out https://cloud.google.com/run. I've never had issues 5x-ing compute on it.

All the other services that compute hits (e.g. Postgres) are a different story, but that doesn't really matter when picking a language.

[retcon]

1 may be better asked as what aspects of your team understanding of any considered language apply to your problem space. How well can you port that knowledge to another model of expression.

2 is fine. the more significant question is often do you want to work with that talent pool and does the pool tell you more about the costs structure of your sector against which information you may prefer to tack against the prevailing winds and even more patiently attempt to trade actual equity for deep abilities and stuff what language is chosen if your stock has value.

I don't understand how much attention individual languages receive. Plural understanding across your team and ability to transcribe the code into valid parseable docs against which APIs are easily written, is paramount in my mind. Corollary to my incredulity I have often thought that you emphasize the codebase language and dialects only to find you fuelled holy wars and dissipated your technical mission values. Which is disastrous for hiring the kind of colleagues we get up in the morning and forget about industry grief to share increasingly awful spaces with.