Comment by shubhamjain | Hacker News Reader

Comment by shubhamjain | Hacker News Reader

In my experience, programmers obsessed with unconventional programming languages are exactly the ones that prioritize (over) engineering over simply shipping things. If you think, writing your codebase in a funky functional language would bear fruits in the long turn, you're in for a surprise. The road is full of pitfalls. Here are a few I outlined in my essay[1]:

1. Hiring is harder: "When it comes to hiring people, it’s true that programmers versed with functional programming would be, on average, better than those who aren’t. However, the hiring pool itself would shrink massively. Learning a language is an investment, and not many people are using their spare time to learn a new one. As I have seen it happen, demanding functional experience soon becomes an unreasonable expectation."

2. Less resources: What's the point of choosing an esoteric langauge and having to build nearly everything from scratch. You're basically throwing away years of experience that a vibrant community provides.

3. Hackers use languages they know: I am nearing 30, and having seen rise and fall of many tech trends, I want to play my cards right. Why should I waste my energy on learning a new language, especially when it can fade into obscurity and the output is going to be the same anyway? MeteorJS[2] was supposed to revolutionize front-end programming, who is talking about it now?

Facebook was written in PHP. Mark used one language he knew and a $300B company was built on top of it. While a company I worked at that prided itself on being written in Clojure, slowly felt behind the competition and barely managed to get acquired (at a deep discount to what they raised funding at). Trust me, your time is better spent shipping, and learning internals of how things work.

[1]: https://shubhamjain.co/2018/12/01/why-paul-graham-wrong/

[2]: https://www.meteor.com/

I've had the opposite experience. Our competition used a "boring" Ruby on Rails architecture, so they were burning investment capital on cloud hosting every month, meaning they were forced to rush for milestones and cut corners so that they could grasp the next piece of funding before their runway ran out. Meanwhile our "esoteric" codebase meant we could run everything on a couple of servers we owned and spend our time building stuff there was an actual business need for. So we were the ones who got a big acquisition while they crashed and burned. I mean, if you're looking at Facebook then you should look at WhatsApp too.

I remember Ruby on Rails being a hipster technology for teens who code on MacBooks at Starbucks. Now it’s “boring”. How times have changed!

I'm sure counterexamples exist (and I'd be interested in hearing what kind of software this happened with specifically), but in the 99% case the cloud hosting costs for most startups is going to be tiny compared to, say, salaries.

Properly hosting in the cloud requires some additional salaries.

> Meanwhile our "esoteric" codebase meant we could run everything on a couple of servers we owned

A recent, not-boring technology that requires less resources than the old, boring one must be an exception.

Also I've found that teams that focus on easily understandable languages (Python I think is the best with its "executable pseudocode" syntax) are those that are placing value on teamwork rather than individual flexing.

FWIW I've had opposite experiences. :shrug: Each team is different, I guess :)

Teams that focus on hard to understand languages care about communication more?

I - er.. okay.

I’ve never seen hard to understand language, just hard to understand code. Without exception. Do you have any specific in your mind?

I have seen teams using languages traditionally considered "easy-to-understand" assuming that the language being readable is sufficient to replace communication and proper documentation.

I have also seen teams using languages traditionally considered "easy-to-understand" use various forms of meta-programming to customize the code and make it even more easy to understand... eventually reaching the point where nobody except the experts of this specific sublanguage could understand it.

I have seen teams using languages considered hard-to-understand being obsessed with documentation and communication – and others who don't care at all.

I've come to the conclusion that it's a teams thing, much more than a language thing.

> Facebook was written in PHP. Mark used one language he knew and a $300B company was built on top of it.

This example doesn't further your point at all seeing as they had to over time literally invent an entirely new language to make their PHP codebase scale. And on top of that FB went on to use a whole bunch of uncommon languages (Haskell, Erlang, D, probably a bunch of others I don't know about)

Well, as the counterfactual, you can't invent a buyer who will value your Clojure shop at the last funding round.

As a countercounterfactual, Zuckerberg spent $22 billion (original offer was less, but both due to growth in stock between offer and sale, and retention) for a company with only 35 engineers writing Erlang (Whatsapp).

> Why should I waste my energy on learning a new language, especially when it can fade into obscurity and the output is going to be the same anyway?

I used that reasoning to keep writing perl when python suddenly seemed everywhere and over-hyped.

To be honest, I probably should have just taken the time to learn python sooner. I haven't abandoned perl, and I doubt I ever will, but it would have saved me some time/trouble to have picked up python earlier since it wasn't the fad I assumed it was.

Today, I assume Rust is just a fad so I'm tempted to avoid the same mistake and pick that up too. Haven't bothered yet though.

Due to Rust's character and niche, it seems rather likely to stay. Wouldn't bet against it yet. There is so much potential for it to replace old and fragile things.

Reply on news.ycombinator.com