YC Software Startups: Value and Initial Programming Language Used
charliereese.caFascinating to see how heavily Ruby and Python feature. The things that surprised me by their absence and near absence were languages I love: JS and C#
That said, this is taking now well established startups that will have begun their lives 5+ years ago in general. If I was picking a back end stack then I'd probably hesitate before picking the .NET Framework. But these days I'd easily pick .NET Core.
Likewise, I'd want a statically typed back end and 5 years ago I'd probably have hesitated before using TypeScript and node together. Now I do it regularly.
Would be super interesting to see the same chart in 5 years with companies starting now.
I think this is because, in the 2000s, when a lot of these companies were founded, Ruby and Python hit an pretty much empty sweetspot for web application development in between quickly thrown together scripts and the super heavy enterprisey frameworks.
But since then, that space has gotten a lot more crowded from all sides. There is now a pretty big selection of mature technology to pick from depending on your needs.
In the case of Python, it got also a massive boost from its popularity in datascience. Couple of years ago I thought Python web development is dying out slowly, but seems to have swung back quite a bit.
I think most frameworks/languages swing in and out of the lime light. Using Ruby as an example, it was great then got really hot, then as you said Python got the data science boost and moved a lot of people there. I'm curious if Matz makes good on his promise to 3x Ruby that will result in Ruby getting some more data science libraries.
That said, last I checked regarding performance Rails and Django were pretty much neck and neck with a negligible difference with rails being very slightly faster (iirc).
I think also a big reason why Ruby is feature so heavily in this list is because of it's focus of developer productivity. It's a nice mesh of flexibility and convention. Generally all projects are setup and organized the same but you can still write a conditional if statement a dozen ways. Compared to my personal experience working with Django and Python are the woes of getting everything configured and setup for each project which is frankly a pita. Also, Python is fairly regimented on a lot of flexibility which has its perks too.
I'd caution people outside hyper-growth startups from drawing that much from this chart. People in that ecosystem have very different utility functions than most software engineers.
Comparatively, I'm sure a chart with database swapped out for language would show a huge over-representation of NoSQL products like Mongo and Couchbase. Yet for the overwhelming majority of projects the right answer is just use a solid SQL product like Postgres.
Again, for SV hyper-growth startups the calculus is different. Mongo has tons of downsides and pitfalls. But the one thing it has going for it is, you can get started fast without having to think about it. Just throw shit in a giant nested key-val map and pull it out later. You don't have to design schemas or provision ahead of time. Change the JSON on the fly, and if you hit performance issues, just throw more hardware at it. Move fast and break things.
For 99% of projects that kind of attitude comes back to bite you in the ass. For every hour that you save today, you'll end up spending ten hours in a year or so from now when you're eventually forced to detangle a crusty sloppy mess.
But for a unicorn-aspiring SV startup, that tradeoff works. Almost any startup would gladly spend a hundred man-hours in a year or two, to get back one man hour today. And that works, because the growth rates are astronomical. In a few years, you'll hopefully be a billion-dollar unicorn with tons of resources to throw at the minefield of quick and dirty technical decisions you made at the seed stage. (More realistically, you simply won't be around anymore, at which point the pitfalls in waiting also don't matter.)
The point is don't necessarily pay too much attention to the decisions made by YC startups. This is true even for regular startups with more prosaic aspirations. (Some of us are more than happy to own $10 million companies, and aren't aiming for billionaire or bust.) If your business model is rooted in 1000% hyper-growth rates, that encourages many tradeoffs that are otherwise deeply pathological.
I couldn’t imagine doing anything in MongoDB or understand why that is desirable.
We have used Postgres from day 1 in March and are now 1200 people. Managing growth with a JSON blob sounds absolutely insane.
You need _more_ guarantees, not fewer.
Have you evaluated MongoDB to see why it's desirable?
Ignorance of a technology is a poor excuse to crap on it. I've used many different technologies over my 15 year career. SQL Server, MySQL, Postgres, MongoDB, Firebase, etc. Each worked well enough, each had it's drawbacks. I'm not here to tell you MongoDB is a silver bullet for every specific use case, but from personal experience I haven't run into an instance where it was a hindrance.
Disclaimer: I currently work for MongoDB.
My big issue with MongoDB is similar to this Potts quote
“I have no problem with god - it's his fan club that scares me.”
MongoDB works fine in niche situations of trying to store large blobs of JSON with extremely different elements. But for the vast majority of cases, data is highly relational. So Mongo is just a crutch that companies like because of the lower skill ceiling. Most of these startups can't be bothered to pay high enough to recruit people who payed attention during their databases lecture. In the long run, it just creates a jumbled mess of db code.
Every project I've worked in, got rid of mongo once they grew to any reasonable size due to cost and maintenance overhead. It's not a hindrance for small projects, but becomes a pain at scale in my experience. Based on that I'd never use it again for anything I plan to scale, gutting it out later is a pain. Might as well build it right the first time.
Not saying you should use it but to reaffirm GP points, the most valued company in that list, Stripe, started with MongoDB: https://www.mongodb.com/blog/post/mongodb-powering-the-magic...
And this is a financial company.
The common misconception is that MongoDB stores JSON blobs. The JSON you see is converted seamlessly to BSON and is type encoded. This allows use to apply indexes at any level in the object and use complex query expressions at any level in the object.
> Managing growth with a JSON blob sounds absolutely insane.
There are cases where it's better when you're using a JSON blog inside SQL. Consider the common scenario where the pure SQL solution would be having 1 abstract model with 50 children that inherit from it, and are only each different by one or two fields.
Having one SQL model that gets queried in one way and in one place, but has 50 different JSON validators, is a lot easier to understand and work with than having 50 different SQL models that get queried in 50 different ways and places.
I use Python by choice and the more there is growing need for Natural Language Processing, Machine Learning, Data Mining, the more I can not leave Python.
I try Rust, Ruby and others on the side. But Python is just so heavily fortified now that I constantly suggest startups who are going to build non-trivial tech to select Python. Also the whole Linux, deployment, etc. space is filled with Python.
Biology, Physics, Math folks also use more Python than any other language.
.NET Core can deploy to Linux now.
https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy...
It's also faster than Node. Significantly faster. I was troubleshooting a connection issue to a db from a .NET Core API so I set up a NodeJS API hitting the same db to isolate it to the connection. After I was done fixing things, I compared the API response speeds for the same thing. .NET Core outperformed Node dramatically just like in benchmarks.
I've been running a website and API with .NET Core for over a year...deploying to Digital Ocean droplets that run Ubuntu. Using MySQL instead of PostGres, sorry HN. It all runs like a champ, and costs me $17.05 USD per month. I only have about 100 users, so I'll scale if/when needed. I built it all on a refurb $700 macbook air I bought in 2016.
...and I can concur on the performance. It's hilariously fast.
Hmm. If you believe in microservices then I think it's fine to use python for your ML pipelines and API's, and some other language for the rest of your application software.
what about R?
or Scala if you need bigger scale?
In my corner of the world, most professors in those disciplines do obscene things with Mathematica as their first choice rather than using a more traditional programming language.
After that there's a fairly healthy dose of C and Fortran from the performance-oriented crowd, quite a few people use Python (but its hard to express just how completely and totally alien their uses are from one another), and the closer you shift to biology or stats the more likely you are to see somebody using R. A few enthusiasts are extremely excited about Julia.
Yes let me just spin up my R web server.
Your web server isn't written in Python either, though.
I recall the bootcamp craze that happened a few years ago and most of them were Ruby (with Rails) based.
The result of that is that if I lookup basic concepts in web dev today I'll still find a lot of tutorials and courses aimed at total beginners for Ruby. Meaning that even today, Ruby would be a good choice for CS students in a program where they have no web dev course if they wanted to get a small website running.
Now Python is gaining adoption as an introductory language (MIT ditched Scheme for it!). My bet is that a lot of times python was chosen simply because everyone in the team knew it.
If I knew the scope of the project right when running git init I wouldn't pick these two, but my gut feeling is that a lot of these started as "let's get a demo working, we won't have more than 10 users ever anyways unless we get funding!"
I started learning Python some 7 months after starting to learn C (my first language). I didn't really grok logical program structure until the burden of mem management was behind me.
So, relieving that burden allowed me a playground to pseudocode a program and then translate that logic to a more optimized inplementation.
I still use that strategy in forming mental models.
But now it's a matter of placing weak joints on a pipeline and accepting bottlenecks where they arise.
Can I MVP in 2-6 weeks on those 10 (the startup) alpha users? Fine. Can I leverage my engineering strengths and understand replacement priorities? That's my goal and I run very far from startups that want to build panickedly with toothpicks and glue.
After building two companies with Python, and then one with Javascript, I can see a huge difference. With Python, you get a predictable development velocity. With Javascript, there's lots of unpredictability (this is rapidly improving) because of thrash in the ecosystem. It's hard to overstate the value of predictable timelines and predictable development velocity when building a business.
Curious where in javascript you saw a lot of unpredictability?
Maintaining JS is a treadmill on fast: takes a lot of work to stand in place, which is horrible if you are trying to get anywhere.
We have been ripping out node bc basic backend frameworks are too small and mercurial, so breaking API changes every year on simple things like making an HTTP request has meant a lot of time not spent on our users. The ROI is often ultimately miniscule perf, and ironically, CVE fixes from such a cowboy culture. (We are also ripping out node bc current inability to work with data ecosystem well + shitshow that is build times / maintaining them.)
Frontend has been getting better. Part of that is we have largely stopped adding any dependencies and been chiseling down to react + a few components, and between them + the webpack team, focusing on the few teams we trust to respect end user code more than they value whatever feature idea that month.
I spent years on making JS better and we have built stuff to make it sing, so bittersweet business decision driven more by the unmaintainable code culture than the language (npm/node are growing up, V8 is amazing, React achieved a lot of what early framework people marched for, ... ).
EDIT 1: Part of the technical problem may be around npm <> semvar and in turn, the dev culture around it. Dutifully updating semvars upon breaking changes may have given a false sense of being friendly for maintenance. Major upgrades are still necessary in practice due to peer dependency requirements triggered by CVEs etc. It's ~awesome to now see breaking changes in better modules. However, having to do via searching github stinks, and horrifying how many there are. This is still a far cry from not consistently breaking everywhere, gofmt, etc.
EDIT 2: I don't blame OSS devs for hobby projects unrelated to their work and with no claims of aiming for prod ready / corp use. But as soon as we get to core node infra teams and their VC sponsors causing a bait-and-switch on infra focus, or tech leads at unicorns & bigco's doing their here today / gone tomorrow thing, etc., I get heart pain around adding any dependencies around this broken tech<>social ecosystem.
In the JS world, this is why Ember is so awesome. People criticize it for including everything and the kitchen sink, but most frontend apps that go anywhere actually need all that. And Ember guarantees that it all works together, with a clear upgrade path.
An example of this from my experience: I was working on a side project and ended up doing 2 major version upgrades on a core JS library (maybe routing?) before I even completed the MVP. Definitely not what I wanted to spend my time on at that point.
I believe Deno links to dependencies directly so that you can still rely on old(er) versions, but not sure it would have helped in this case.
I use python because its just so much easier to develop. I think for startups iteration speed is magnitudes more important than running efficiency of code
Node will probably start showing up more, though I'd say its biggest weakness is that there's no full framework (that takes care of everything) that's truly dominant. Working in node, feels like working in Java, especially if you're using Typescript. Unlike Ruby and Python, Javascript / TS suffers from the paradox of choice https://en.wikipedia.org/wiki/The_Paradox_of_Choice
Javascript's ecosystem isn't just fragmented, it is downright capricious. In all my decades in tech, I've never seen an environment where dependencies rot out of maintainability faster.
+1 for choosing .NET Core. I'm right there with you. Extra points for F#.
Ruby on Rails in particular made it really easy to get up and going in a few hours or days. I think Python with Django and Flask has occupied that spot.
And for ML and AI-focussed startups, Python is a no-brainer.
The page doesn’t list the year the startups were founded. I wonder if you’d see a good correlation to the founding year.
More startups on the list use Ruby than any other language, and it accounts for over fifty percent of the valuation. It was very popular with startups ten, twelve years ago, but may since have slipped?
On the other hand among younger companions es one might expect to see more Go, Node and maybe Rust?
Still, an interesting analysis.
If you're talking about survivorship bias, I can well believe it.
Ruby is still popular with startups, and there's no falloff in Rails usage, if the gem download graph is anything to go by.
Rails download graph: https://www.ruby-toolbox.com/projects/rails
This is excellent, thanks for sharing. Anyone know if something similar exists for JS frameworks (React,Ember,Angular,Backbone, etc)? Would be great to see their popularity over time.
I’m guessing maybe not having a single central repository like Gems will prevent this data from being so easily accessible.
what spiked the graph in November 2012?
I'm not sure how they came with that projection at the end, despite the fall shown...
Assuming you're looking at the chart in the other comment, it's not a projection. The chart contains two separate graphs in overlay, and they are both of absolute numbers. Red dots are total all-time downloads, grey bars are a four-week histogram, and both show continued growth.
The author added a note under the main table about that, which goes in the direction of what you're saying:
> Note: Ruby and ruby on rails was a popular choice for YC startups around 2010 - 2012. Anecdotally, ~40% of YC startups used ruby during its peak popularity.
Yeah, Ruby and specifically Ruby-on-Rails was (and still) is very popular in SV startups. Only one mention of Elixir, I'd expect this to change in the future as Phoenix replaces Rails as the easiest framework to build MVPs.
I know that PagerDuty also uses Elixir for some of their backend services. See https://www.pagerduty.com/blog/elixir-at-pagerduty/
I'm curious about this too. I'm working on collecting that data for these companies. Hopefully that sheds more insight into this.
Yeah, I'm guessing that more recent startups will have much less Ruby usage.
This serves as an interesting counterpoint to Paul Graham's Beating the Averages[0] essay (which argues for using a powerful programming language as a secret weapon to allow a startup to outperform its competitors).
Reading this list, I'm struck by just how mainstream the languages are. I don't have anything against Python or Ruby, but it'd be hard to describe either as a secret weapon — indeed, about the only "secret weapon" languages on that list are Lisp and Elixir, each of which shows up only once.
He wrote that essay nearly 2 decades ago. It was a different world. At the time, the only language with a truly comprehensive open source ecosystem was perl, so, if you were going to work on anything else, there was a decent chance you'd end up writing almost everything yourself. That puts you in a spot where your secret weapon is the language itself.
Nowadays, I'd argue that the secret weapon is never the language itself. Ruby's popularity was never about Ruby itself, it was about Rails. Python is, IMO, an ugly hack of a language, but it's still the one I'm always pushing for at work, because its unbelievably lush open source ecosystem means that choosing Python means you'll end up having to do a lot fewer things yourself. Java's was originally about cross-platform deployment, but, now that it's been a decade or so since anyone was actually that worried about interpreted languages, I'd guess it's now more the fact that Java developers are cheap and easy to hire.
I'm also honestly not super impressed by Graham's comments on programming languages. Sure, Viaweb sold for a lot of money. But then it turned out that it was an unmaintainable mess that needed to be rewritten. Graham has done a good job of pitching the idea that this is because people can't understand the obvious genius of Lisp, and I'll admit, as a Lisper, that that story once beguiled me. But, now that I've been around the block a few times, I realize that code that can only be maintained by its own author is never good code, and that sale price is rarely a good proxy for quality (especially when the purchaser is Yahoo!), and that sheer dumb luck plays a much larger part in entrepeneurs' success than any business essayist cares to admit, least of all the ones writing autobiographical essays.
> Viaweb sold for a lot of money. But then it turned out that it was an unmaintainable mess that needed to be rewritten
I think that's because the code after the sale had to meet different requirements than the code before the sale.
Before the sale, the chief requirement, at least from what I gather from pg's essays, was fast implementation of new features. That was the secret weapon, and Lisp was a key enabler for it. The number of people touching the code was very small, so having the code be understandable by others was not a high priority.
After the sale, the chief requirement, I suspect, was maintainability while running at scale. The before-the-sale period had already sufficiently explored the feature space that fast implementation of new features was no longer a requirement, so the advantages of Lisp were no longer crucial. But having code that lots of people could understand and modify reliably was crucial.
So the code had to be rewritten after the sale. That doesn't mean the code before the sale was bad, just that it was tailored to different requirements.
That's one way of looking at it. I tend to prefer the mountaineer's ethos when thinking about goals for grinding out a new application: Getting to the top doesn't count if you can't get safely back down again.
It's a bit different with pre-sale/aquisition than mountaineering, with enough money and therefore ability to hire talent it's not impossible to refactor/split the project or even rewrite as needed once the business value is established. Reddit did it, going from lisp to Python, as did Twitter with microservices, Facebook rewriting a PHP VM, etc.
Startups in your analogy are more akin to: "get to the mountain top and succeed and have the cash to hire a helicopter out of there, or you die (the company)".
“Viaweb sold for a lot of money. It was bad code.”
I think the ultimate test of code is whether it generates money. That is the sole reason the world cares so much about code.
It’s an unpopular definition, and I don’t like it, but it seems correct.
Code should be obvious the the point that anyone taking a glance can say: "I can take it from here". It happened to me once. I was let go from a gig because the code was so darn easy to maintain (Django plugins), that I coded myself out the job.
There's a tendency to optimize for development speed in startups these days, which usually means gluing together lots of dependencies rather than writing things yourself. That pushes developers towards languages with well-established ecosystems.
When he wrote that, he considered Python and especially Ruby as outside of the mainstream and a bit more powerful, too. The mainstream he was comparing against was Java.
I'd say the ecosystem has move considerably in the direction he advocated. Even Java has moved considerably from 2001 Java.
the language isn't the secret weapon - it's the person wielding it. It's just that if the wielder is using a less common language, it makes the news.
Also there's a large selection bias: people using less common or more esoteric/demanding languages tend to be better engineers who have invested the time in learning something off the beaten path. That absolutely does not mean it's the right decision since most employees will statistically be average and you want to have a stack that appeals to a large enough talent pool.
Top-50 billion dollar unicorns are hardly _mainstream_. We might be witnessing the fact that these non-mainstream languages help beating the odds.
Archive link: https://web.archive.org/web/20200826060913/https://charliere...
Looks like HN brought it down.
Clearly they should have used a higher performance programming language. :-)
Nah, getting their MVP up quickly let them validate. Now they know it's worth the effort to scale ;)
Hahaha clearly!
Just depends entirely on what you are doing. If you are ecommerce you can basically stick to really slow languages forever as the request volume is so small it should be a small fraction of your application. For consumer scale you end up scaling with caching and eventually migrate or severely optimize - like writing your own language runtime like FB. None of this accounts for all the analytics they are doing which is mostly written in Java and C++.
Even outside of e-commerce -- I would say anything on the web.
Run something like Ruby/Python for the majority of your web services, and deploy Elixir/Go/Kotlin/C++/Swift whenever you hit a data-munching need that Ruby/Python can't handle.
This doesn't fly if you're doing games, or augmented reality (AR), or mobile apps, or embedded stuff... but the web is still a pretty big place to build.
Pretty much. Solve the problem first, then measure where the bottlenecks are and focus on those.
The premature optimization adage has been touted around since forever but it can be widely applied.
Seems like age is a factor: ruby had its day and companies of that vintage have been around long enough for some of them to be worth bucks. Python is more perennial (over the lifetime of YC itself).
In my annecdotal experience (could be completely wrong) Python and Django are much more common for the same vintage of startups in Europe as when Ruby and Rails were popular in the USA, I don't exactly know what drove it's adoption here.
Maybe related: One of Django's creators, Simon Willison is British. I think he worked at Guardian.
He's on HN too.
The creator of Ruby on Rails is Danish[0].
[0]: https://en.m.wikipedia.org/wiki/David_Heinemeier_Hansson
I know. And DHH worked on Basecamp and they are US based.
Even though it says "initial back-end language(s)" it looks like the information is often pulled from the startup's current career pages. Mixpanel is listed as using Go as one of their initial back-end languages, even though Mixpanel was founded in June 2009, several months before the first version of Go was released.
Thank you for pointing this out! Fixed and updated the article.
This is a really good time to remember correlation does not equal causation. :)
I'm curious what's going on with the languages that seem to harm a company's value. Adding PHP or Java to your stack appears, from these data, to be a poison pill for company valuation.
It could just be a statistical fluke, given this sample size and all the selection effects at play, but I still have to wonder.
The only thing that stands out for me, not a single one of these startups use Microsoft tech, even though DOT NET apparently is quite good to work with, from what I hear.
I think that this article[1] is still relevant. In short, if you go Microsoft, you know you're locking yourself into an expensive ecosystem, one with no viable open-source escape hatch.
Moreover, you need to find developers that want to work on the .NET platform. Most of those people work in banking or in large organizations, and are unlikely to want to jump ship to a startup.
An article from 2014? You should know things have changed since then, with .NET Core and the open-sourcing of most .NET tech (Roselyn, OmniSharp and the .NET Core tooling).
No more lock-in with Windows Server, no more SQL Server. Bring your favourite Linux distro and open-source RDBMS.
I left .NET for Ruby in 2013, and in the last two years, I've come sprinting back to .NET Core. Microsoft is definitely hot again.
I use .NET Core with F# on Linux because you get a reasonably good functional language with access to a vast ecosystem and first class support on all clouds. Thanks to Fable and Feliz, you can use it to write React applications as well.
Microsoft Research certainly does a lot of interesting stuff, but I think the bigger point is inertia -- Microsoft doesn't have any in the startup space.
Ruby, and to a large extent Python, started from zero, and gained a ton of traction during the whole Web 2.0 rumble.
Microsoft is starting from a negative perception amongst a lot of engineers, and unless they can provide some sort of killer reason to use .NET technologies -- one that doesn't lock you into their ecosystem -- then I don't see them unseating the established players.
Swift and its descendants will be around as long as Apple is, same story for Java and Android. Ruby/Python/Node will continue on in the Web space, with Go/Rust/C++ duking it out for backend services.
This game changes should Microsoft blow a new market open, though, like Apple and Google did with smartphones.
> Microsoft is starting from a negative perception amongst a lot of engineers, and unless they can provide some sort of killer reason to use .NET technologies
Yeah, as stated above, I used to build on .NET back when WinForms was king. ASP MVC wasn't fun to write, Rails was a blast.
If you haven't got C# experience, I can understand the apprehension.
History repeats itself and almost definitely MS will get it wrong again for .NET, but right now, the money is good and the tech is interesting if you're into web tech and C#.
> Winforms was king. MVC wasn't fun to write with
Having worked with both, I have exactly opposite feelings about the two platforms. Except speed of development, I have absolutely nothing positive to say about Webforms.
Ah no! While a standard thing to do for the web, WinForms let you do the strangest stuff like mimicking OS X for a piece of Windows-only software.
My excuse is I was seventeen at the time... Back then, I was afraid of both hard graft and human interface guidelines.
> History repeats itself
I would go with "History doesn't repeat itself, but it often rhymes". :)
> definitely MS will get it wrong again
Oh, definitely. And I agree -- Microsoft is doing some interesting stuff right now. VSCode has made a big splash, they bought GitHub, etc.
But I'm sure you can recognise that .NET has a lot of err, negative inertia; it is becoming a more viable solution, but it's not there yet.
I did end up in a project a little while ago where they picked .net and azure as their technology of choice. Not sure what factors were in play there.
I was thinking the same but then almost none used Java either. And having been both a C# and Java dev, they're mostly comparable. I'd give C# the edge just because it's newer, it managed to add a few bells and whistles and improve a few quirks, but honestly you'd be hard pressed how similar they are. You won't need more than a week as an experienced dev in one to be comfortable in the other.
Stack Exchange is notable for using .NET/Windows [0]
[0] https://nickcraver.com/blog/2016/02/17/stack-overflow-the-ar...
There's a correlation but I don't think it's the one drawn from the article (programming language). I think that you have to consider the background of the person who would typically opt for these languages to start a new business/project. This might inform you of their thinking and perhaps a language like Java, where the developer is likely an Enterprise developer, leads to more brittle thought and execution. "Move fast and break" vs "thoughtful OOP and architecture" -- It's possible to do that in both languages but you'd rarely encounter a "move fast" Java developer while you'd probably quickly encounter "move fast" Ruby developers.
That's perhaps down to experience having the effect of hardening oneself. You've made the mistakes, you don't want to make them again, so you create solutions that are more robust and by definition "better code" and "better designed". Unfortunately, this can cause you take longer to get to market and if you do have to pivot, can be a harder effort pivoting off of a larger, purpose-built codebase.
I bet there's at least one company on this list who says they use a flash programming language because they're too embarrassed to tell the world they're running autohotkey scripts over an excel spreadsheet.
no way, is that actually possible?
Excel is extremely well optimized and can easily handle GB size CSVs
At a company I used to work for there were tales of an early admin guy handling all of payroll, employee directory, and tonnes of admin task data for multiple hundreds of employees in Excel. Guy was an Excel god.
It worked perfectly fine until it was move into a proper database with in house built portals to handle the tasks.
We used to have a prophecy that when the IT apocalypse hits, we'll be pushing our shopping carts around like in Cormac McCarthy's The Road; moving from company to company to fix the VLookups in their Excel spreadmarts
Reddit was Lisp for a rather short time before being rewritten in Python. Isn't the story that HN was written in Arc as a response to Reddit's Python rewrite?
HN was written in Arc because Paul liked Lisp and made Arc and wanted a real project to try it. It really had nothing to do with reddit's switch to Python (which as you correctly point out was in it's second year).
HN was more a response to PG wanting more moderation control over the content.
I think it still definitely counts. Reddit 1.0 was Lisp, and deployed as a Lisp service. It wasn’t as if it was some hokey prototype then finally converted for showtime.
test
Ruby certainly seems to have advantage in terms of spinning up a basic working product, which matters more than developing a well engineered solution.
Why does using Ruby or Python preclude having a well-engineered solution?
Well, that's the best part; in a very wide gamut of cases, they don't, and since both play nice with compiled languages a scaling up can benefit from both worlds.
I would argue that "engineering" and "scale" are different concerns.
Engineering is about building and maintaining things fit for their purpose.
A bridge that only needs to last for one year is designed very differently than a bridge intended to be used for twenty years.
In the case of software, that means (a) building what your users and business need; (b) designing software that is easy to change; and (c) delivering enough scale to meet your expected needs for the current business cycle.
For a new startup, you can probably get by with a Rails app on a single Digital Ocean droplet, with plans to scale horizontally. For an established business, you might have a large data warehousing operation running custom C++ code across multiple datacenters, of which the web frontend is a tiny (but important) part.
Good software engineering makes the steps between "New Startup" and "Established Business" as painless as possible, with a minimum of additional overhead.
> A bridge that only needs to last for one year is designed very differently than a bridge intended to be used for twenty years.
Yes, but in software, the usual case ends up that the 1 year bridge actually has to become an interstellar spaceship and has to last basically forever.
This happens in other disciplines as well but I have not seen it as extreme as many software projects I saw.
No. They seem to have web frameworks with which own can develop a working product quickly
Lack of type safety and design with no regards to performance.
Ruby as a language doesn't. It's more about the ecosystem and the popularity of Ruby comes from the popularity of Ruby on Rails, that is what makes Ruby have an advantage of getting started quickly.
I'd be more interested in failed startups vs programming language.
Exactly.
Successful startups are analogous to surprising research results in academia, in the sense that we have much more information on them and therefore we can draw better conclusions about these entrepreneurial/academic successes.
Today, every good scientist is aware that having plentiful information on unsurprising research is almost as equally important, for many obvious and non-obvious reasons. This has resulted in journals created exclusively for publishing unsurprising research. [1]
If the most rigorous among us w/r to taking care of our collective body of knowledge are only starting to do it seriously, we can have hope that the industry might ramp up its capacities in this regard at some point - I wouldn't hold my breath that's it's going to happen soon though.
Start up year likely correlates. But also it would be nice to know how many startups failed and what languages they used?
Did using Node.JS or Typescript correlate with business failure or is it just more recent?
I'm also particularly interested if trying to use Kubernetes correlates with failure. Kubernetes, for all its good, is a rats nest of complexity.
So the use of C# dooms my startup? I feel really out of touch having never used python or ruby.
I don't think language has got anything to do with it. It's more about the instincts. I'm purely talking in terms of probabilities but the odds of a C# programmer coming with an enterprise background are high. As such they bring certain instincts with them which are very useful in enterprise but not useful at all in startups. At worst, those instincts might do more damage than good.
So it's more of background/instincts things than language. C# technically has nothing which makes it a bad choice for startups.
> So the use of C# dooms my startup? I feel really out of touch having never used python or ruby.
No. It may even be an advantage for some verticals such as finance, and some business/deployment models like on-prem enterprise software, especially if being able to fit seamlessly into a customer's existing Microsoft setup would be a major selling point.
That said, if you find yourself contemplating how to scale your Active Directory and SQL Server deployment[0] to accommodate your growing user base of personalized emoji GIF makers, consider that your prior experience with your chosen platform may have led you astray somewhere.
[0] Apologies if the metaphor lacks punch, my experience with the MS stack is a decade or two out of date at this point.
Not at all. Keep in mind that YC startups are birthed from a very narrow slice of the tech world. .NET Core is very, very good tech and unless you need something super niche, there's no reason to doubt your choice. Press on.
Also keep in mind, just because .NET does not show up in the top 50 YC Tech startup list, does not mean there aren't many startups using it. I am working on one such YC company. The entire server side stack is .NET based with F# and C# being the dominant language.
Nah .net core & c# are nice; you do not have to pick the hippest stuff always. And (very) good .net devs are easy to find and also cheap.
Some of these are wrong: Rappi used PHP exclusively for it's first year, for instance
If you can send me a source for that (on Twitter @charlieinthe6), I'm happy to make that change!
Can we also submit it via HN? If so, my understanding is that Pagerduty is running and long-term invested in Elixir (https://www.pagerduty.com/blog/elixir-at-pagerduty/) and Podium has migrated from Ruby to Elixir as the main stack (https://medium.com/podium-engineering/two-years-of-elixir-at...). Thanks!
Edit: oops, I see now it is the initial language. Indeed PagerDuty started using Elixir only later on. Although one could argue Elixir was part of Podium in its initial growth.
Exactly - trying to capture what language they started with.
It was by no means a perfect science - was a lot of digging around on the internet for the oldest reference I could find!
You have Go listed for Twitch, but justin.tv launched in 2007 and Go didn't exist until 2009.
Great point! Will make the change now.
This is a lagging indicator. If you did this in 2010, the top companies would all be PHP.
The biggest example of this I can think of is Facebook
I know a little about Coinbase. The CEO did the initial MVC with ruby on rails. He was somewhat technical so it was a natural choice.
Then they moved forward with ruby for the whole platform, maybe as that's what he understood and what was the alternative back in the day.
However for any of these businesses the language of choice if starting today for me would be rust.
I really feel you get a much more maintainable codebase than a ruby project,
> I really feel you get a much more maintainable codebase than a ruby project,
As I'm sure you're aware, this is entirely subjective. I really feel the opposite.
Language comparison is not subjective if the person has experience using both. Otherwise it is guessing.
It is still subjective. There is no objective way to use each language to build a product.
Rust is a great language, but how do you scale a Rust team? It’s a hard language to learn without a ton of developers out there. I suppose you could hire C/C++ devs, but if you’re just making a fairly standard SAAS Web app, it might be hard to pull those people over. Rust feels like overkill for your typical Web service to me.
There's a tradeoff, a high inital cognitive load for people learning the language vs the long term pay off of less bugs in production.
There are plenty of people who have spent time learning rust but haven't had a chance to use it on a production project. I would start looking there.
> vs the long term pay off of less bugs in production.
It has not been proved large, long-lived Rust projects have fewer bugs than large, long-lived Python/Ruby projects.
There's a tradeoff, a high inital cognitive load for people learning the language vs the long term pay off of less bugs in production.
That's not how startups work.
Yeah I would just find a motivated junior Node.js dev, and commit to training them up for a month or so.
i've always wondered why the Whatsapp acquisition didn't spawn a bunch of startups using Elixir, since a lot of noise was made about how Elixir helped Whatsapp scale with so few people. isnt that how tech cargo culting starts?
WhatsApp used Erlang, not Elixir. There was an uptick in popularity (at least here on HN) after the acquisition. Elixir wasn't as popular in 2014 as it is today, but it was starting to grow.
Erlang VM was a great fit whatsapp, doesn't mean is well suited for everything. Even with Elixir, I argue its use case is still niche.
Interesting that all of them which have "Y" for category "LowLv" incorporated one or more of c++, go, or rust[0]. Many which have "Y" for "DataSci" similarly use strongly typed/compiled languages (including Java). However, for general ecommerce / service-oriented offerings, there can be no dispute, given this list, whether ruby or python by themselves are up to the task.
[0] Dropbox is listed as python only, but it is well known (and documented) they have re-written key elements of their back end in rust. https://dropbox.tech/infrastructure/rewriting-the-heart-of-o...
The title seems to insinuate there’s a correlation between a startup’s value and dev language. While I think our “inner geek“ all likes to think so - is that really the case?
There is an attitude some programmers have that business outcomes are not their department/problem and they should focus on the tech.
They will (for instance) avoid certain tech stacks, regardless of how useful the software being written is (eg “I wouldn't work for Wikipedia, they use PHP”).
I suspect any tech stack that they refuse to work with is at a systematic advantage when it comes to producing useful work, because engineers who don’t want to think about fiscal outcomes can readily lead you to ruin.
Absolutely not. You will find winners and losers for every language.
There is no correlation. Success is 100% business connections. Even if the CTO was terrible, it wouldn't matter because the most talented devs would be applying to work for this hot new startup and would be able to work around all of the CTO's silly constraints. I have seen this over and over in my career.
The CTO imposes pointless arbitrary rules, tools and languages and then talented developers figure out a way to deliver value within those arbitrary constraints. Developers will use whatever language their boss tells them, then later when the project succeeds, they will praise that language, those tools and their bosses.
People will always praise the leaders of a successful company, no matter how incompetent they are.
People who succeed always think that it was because of good decision making across the board. They don't admit to themselves that the only decisions that actually matter are who the CEO is and who their friends are. Our system is crony-capitalism, no doubt about it. Nothing to do with value creation; the evidence is everywhere.
Any good developer who analyzes cryptocurrency projects, for example, will realize that there is no correlation between quality (or scalability) of the technology and ranking/market cap of the project. The top, most valuable project is Bitcoin and consumes the same amount of electricity as the nation of Ireland to process a measly 4 transactions per second. Anyone who thinks that Bitcoin is the most valuable project due to technical merit is an idiot. It's 100% network effects.
I can say from experience across different tech industries that the current market selection process works the same way across the entire tech sector, not just cryptocurrency.
Every time a project succeeds, the people who built it will try to claim credit for that success. The people who are actually responsible for that success (through their personal connections) will happily let the technical people claim the credit because it diverts attention away from the much more cynical and unjust reality.
Any attempt to insinuate that success has anything to do with choice of tech is either misguided or deeply corrupt as the dogma harms real people (who will be forced to use tools they don't like) and causes real loss in productivity.
No correlation is a bold claim. It seems obvious that a web based startup built using Rails is far more likely to succeed than one using bash scripts, if all else is roughly equal.
The table very clearly shows the correlation.
Nope. Sample size too small to draw correlation.
yep absolutely and there is also the fact that its a list of VC backed (successful)startups we would need to see the failed ones at least. I would say sound development practices (code review, platform design, testing etc) is orders of magnitude more important.
Facebook started out using PHP and it was so bad they had to almost rewrite the language from scratch. PHP is now pretty decent and Facebook is doing pretty OK.
Is there a list of what they have changed their programming language to? Like... Reddit indeed used to have their initial implementation in Lisp, but it is now Python.
The fact that JS barely makes the list indicates to me that YC companies tend to have entirely separate frontend and backend codebases. That either indicates separate teams of frontend and backend developers, which I think is unlikely in a young company, or that there's an expectation that developers in early YC companies are expected to use (at least) two languages. Something to think about if you're starting out as a dev and thinking of looking for a role in a YC startup.
Two devs, each frontend and backend will work out pretty well even in a super-small startup I guess?
Depends entirely on the dynamic of the two people since backend and frontend has to work well together. When you're in a early startup, you want everyone to be on the same page, so you want people to collaborate closely. If they are people who like to work in silos without talking with each other, you'll have bunch of impedance mismatches at that stage. So you'll want a close team early on and if you can find someone who is good with both frontend and backend and could build it as one person, that'll be better for the early stages. Or two people who can collaborate closely.
test
This would be more interesting if YC didn't have a strong inherent bias toward these particular languages. In other words: these are the results because this is what YC picks and filters for, not because of any inherent meaningfulness about choosing these languages, or qualities of the languages.
It's true that investors filter for easy to see signals, so therefore it is also likely true that 130 IQ startups get funded but 140 IQ startups are not recognized (or even outright ostracized), but this is the same for customers, executives, and humans generally. So it's not clear that this could be any other way. In this way humanity is a tragedy. Look around. Everything is mush.