Live data from Hacker News

YC Software Startups: Value and Initial Programming Language Used

charliereese.ca

131–140 of 156 posts

Re: YC Software Startups: Value and Initial Programming Language Used

#131

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 "secre…

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 i…

“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.

Re: YC Software Startups: Value and Initial Programming Language Used

#132
post #128

Earlier quoted context omitted.

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…

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.

Re: YC Software Startups: Value and Initial Programming Language Used

#133
post #38

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.

Stack Exchange is notable for using .NET/Windows [0]

[0] https://nickcraver.com/blog/2016/02/17/stack-overflow-the-ar...

Re: YC Software Startups: Value and Initial Programming Language Used

#134
post #120

Earlier quoted context omitted.

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 SQ…

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.

Re: YC Software Startups: Value and Initial Programming Language Used

#135
post #120

Earlier quoted context omitted.

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 SQ…

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.

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.

Re: YC Software Startups: Value and Initial Programming Language Used

#136
post #134
post #120

Earlier quoted context omitted.

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 wh…

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.

Re: YC Software Startups: Value and Initial Programming Language Used

#137
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.

Re: YC Software Startups: Value and Initial Programming Language Used

#138
post #127

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?

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.

Re: YC Software Startups: Value and Initial Programming Language Used

#139

Earlier quoted context omitted.

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.

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.

Re: YC Software Startups: Value and Initial Programming Language Used

#140

Earlier quoted context omitted.

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…

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.
Post reply on HN